Re: "You can't make a hot fudge sundae with mashed potatoes instead of ice cream, either."
[EMAIL PROTECTED] wrote: > ...just made them a convenience for identifying type errors... I.e. type-safe macros. -- John Porter
Re: "You can't make a hot fudge sundae with mashed potatoes instead of ice cream, either."
> > I haven't been tricked into reading MJD's article yet, but might your > > third option be multiple functions with parameter-type-based dispatch? > > We can do that with perl 5, but it isn't automatic. > > The problem with polymorphic functions is you have to rewrite the > function N times (where N == the number of different types you want to > handle). Its certainly a possiblity, it just seems rather inelegant. > Rather. Why write the same function multiple times with nothing but the type specifier changed, when you could just write it once with a type placeholder? This is all that a template is. Templates have a bad rep, and fair enough too because their implementation has been pretty iffy. But think about the reasons there have been problems: - Inconsistent implementation in compilers (still no compiler supports all ANSI template features) - Frivolous 'variable name too long' warnings because of implementation SNAFUs - Frivolous 'template depth' errors and warnings - Over-enthusiastic use of generative programming (e.g. expression templates); leads to slow compilation and unearths subtle compiler bugs. Nothing here is fundamental to the concept of templates. If we stayed away from trying to use them for compile-time computation (ie generative programming) and just made them a convenience for identifying type errors, I think it could work. The next paragraph is a wild and wacky idea--feel free to ignore it as being highly eccentric... The idea of a type hierarchy is not mutually exclusive with templates, BTW. In fact, it's not hard to envisage a template syntax that allows type placeholders to indicate allowed types (or probably actually interfaces). The problem in C++ (that doesn't do this) is that the compiler won't stop you from instantiating a templated class with a type that is not supported by the class (by 'not supported' I mean that the type doesn't have an overloaded operator required by the class, resulting in an error). Imagine something like (imixed up in a strange Perl/C++ blender): my list $iList(1,2,3); my list $rList = reverse($iList.begin(), $iList.end()); *** compile error: function 'reverse' requires type supporting 'bidirectional iterator' interface -- Jeremy Howard [EMAIL PROTECTED]
Re: "You can't make a hot fudge sundae with mashed potatoes instead of ice cream, either."
On Mon, Jul 09, 2001 at 10:37:47PM -0500, David L. Nicol wrote: > Jeremy Howard wrote: > \ > > Perl 5 didn't need templates, because there wasn't compile-time typing. But > > with Perl 6 I want to send my compact array of integers to the same fast > > sum() function as my compact array of floats, and not have to wait while > > perl treats them both as old generic scalars. > > I haven't been tricked into reading MJD's article yet, but might your > third option be multiple functions with parameter-type-based dispatch? > We can do that with perl 5, but it isn't automatic. The problem with polymorphic functions is you have to rewrite the function N times (where N == the number of different types you want to handle). Its certainly a possiblity, it just seems rather inelegant. -- Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/ Perl6 Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One I have this god-awful need to aquire useless crap!!!
Re: "You can't make a hot fudge sundae with mashed potatoes instead of ice cream, either."
Jeremy Howard wrote: \ > Perl 5 didn't need templates, because there wasn't compile-time typing. But > with Perl 6 I want to send my compact array of integers to the same fast > sum() function as my compact array of floats, and not have to wait while > perl treats them both as old generic scalars. That means that my sum() > function needs a typed parameter list. There seems to be at least two > potential solutions: > - Provide a type placeholder in the parameter list (a la C++ function > templates) > - Provide a type hierarchy for all types (a la Haskell) > - (And that 3rd option that I haven't thought of yet...) I haven't been tricked into reading MJD's article yet, but might your third option be multiple functions with parameter-type-based dispatch? We can do that with perl 5, but it isn't automatic. > I don't remember seeing either of these suggestions in the RFCs, but I might > have forgotten since I occassionally fail all 361 of them in my head. A > hierarchy of types is briefly referred to in RFC 4 but not really developed > to deal with this issue: > http://dev.perl.org/rfc/4.html Stuff about polymorphism and multiple dispatch was supposed to touch on these issues, bog only knows if it did or not. -- David Nicol 816.235.1187 Series EE bonds can be exchanged for Series HH savings bonds.
Re: "You can't make a hot fudge sundae with mashed potatoes instead of ice cream, either."
> Well, my hope is somehow we can get types to be a bit more implicit > than the usual mess most people are used to. I have grave concerns about 'implicit' typing. In my experience DWIM-style typing can lead to serious hair pulling and long debug sessions over simple errors. Now, if you can give me implicitness without unintended post-compile behavior... > > Because templates provide much-needed flexibility in algorithm and class > > development, C++ programmers don't have to use many of the workarounds that > > mjd identified. > > Yes, they have lots of different work arounds. ;) Regardless, a lot of mjd's examples seem dated. He seems to have a clear point to make. I just wish his examples related to any programming I've done in recent memory. I think that OO (and generic programming specifically) reduce his argument. But then again, maybe I'm too entrenched in the C++ mindset. Wouldn't be the first time. > > - Provide a type placeholder in the parameter list (a la C++ function > > templates) > > - Provide a type hierarchy for all types (a la Haskell) Let's not forget Java, a less obscure example. > I think a type hierarchy makes much more sense than unleashing the hell > of templates on Perl. Perl was born in downtown Hell! Bring it on... - Matt
Re: "You can't make a hot fudge sundae with mashed potatoes instead of ice cream, either."
On Mon, Jul 09, 2001 at 04:43:28PM +1000, Jeremy Howard wrote: > One of mjd's points about mashed potatoes is that Perl isn't ML, and ML's > typing approach doesn't fit on top of Perl very well (i.e. at all). Well, my hope is somehow we can get types to be a bit more implicit than the usual mess most people are used to. > Stroustrup noticed the same thing (about typing, not mashed potatoes) when > looking at this issue for C++. His solution was the introduction of > 'templates': YeeeAHHH!! Don't say that word!! I'll have nightmares now. > Because templates provide much-needed flexibility in algorithm and class > development, C++ programmers don't have to use many of the workarounds that > mjd identified. Yes, they have lots of different work arounds. ;) > Perl 5 didn't need templates, because there wasn't compile-time typing. But > with Perl 6 I want to send my compact array of integers to the same fast > sum() function as my compact array of floats, and not have to wait while > perl treats them both as old generic scalars. That means that my sum() > function needs a typed parameter list. There seems to be at least two > potential solutions: > - Provide a type placeholder in the parameter list (a la C++ function > templates) > - Provide a type hierarchy for all types (a la Haskell) I think a type hierarchy makes much more sense than unleashing the hell of templates on Perl. -- Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/ Perl6 Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One Maybe they hooked you up with one of those ass-making magazines. -- brian d. foy as misheard by Michael G Schwern
Re: "You can't make a hot fudge sundae with mashed potatoes instead of ice cream, either."
Michael Schwern wrote: > mjd tricked me into reading his "Strong Typing Doesn't Have To Suck" > talk, and now I'm looking at the typing proposals for Perl 6 and > thinking... boy, its going to be almost as bad as C. That sucks. > > Is there hope? I dunno, but read the talk. > http://perl.plover.com/yak/typing/ > Schwern tricked me into reading mjd's "Strong Typing Doesn't Have To Suck" which turned out to be a really well written exposition of how modern functional languages (mjd used ML as his example) use type checking to flag program errors without losing algorithm flexibility. One of mjd's points about mashed potatoes is that Perl isn't ML, and ML's typing approach doesn't fit on top of Perl very well (i.e. at all). His other point about mashed potato is that it is a poor vector for hot fudge, IIRC... Stroustrup noticed the same thing (about typing, not mashed potatoes) when looking at this issue for C++. His solution was the introduction of 'templates': http://babbage.cs.qc.edu/STL_Docs/templates.htm which are now used widely by C++ programmers when they access libraries such as the STL (which is part of the Standard Library) and the very cool POOMA: http://www.acl.lanl.gov/pooma/ Because templates provide much-needed flexibility in algorithm and class development, C++ programmers don't have to use many of the workarounds that mjd identified. Therefore, far more compiler warnings represent real problems, which means that programmers are less likely to ignore them. Perl 5 didn't need templates, because there wasn't compile-time typing. But with Perl 6 I want to send my compact array of integers to the same fast sum() function as my compact array of floats, and not have to wait while perl treats them both as old generic scalars. That means that my sum() function needs a typed parameter list. There seems to be at least two potential solutions: - Provide a type placeholder in the parameter list (a la C++ function templates) - Provide a type hierarchy for all types (a la Haskell) - (And that 3rd option that I haven't thought of yet...) I don't remember seeing either of these suggestions in the RFCs, but I might have forgotten since I occassionally fail all 361 of them in my head. A hierarchy of types is briefly referred to in RFC 4 but not really developed to deal with this issue: http://dev.perl.org/rfc/4.html
"You can't make a hot fudge sundae with mashed potatoes instead of ice cream, either."
mjd tricked me into reading his "Strong Typing Doesn't Have To Suck" talk, and now I'm looking at the typing proposals for Perl 6 and thinking... boy, its going to be almost as bad as C. That sucks. Is there hope? I dunno, but read the talk. http://perl.plover.com/yak/typing/ -- Michael G Schwern <[EMAIL PROTECTED]> http://www.pobox.com/~schwern/ Perl6 Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One
