Re: Synopsis 2 draft 1 -- each and every

tion API should therefore be a via a name that does not care whether its underlying object is being consumed or not (the Callous Iterator). The syntactic <> should behave exactly this way. Then, for those occasions you do care about how the sequence is being processed, you can call either $seq.pop or $seq.next (or whatever names) for the specific DS/ND behavior you need. -Dov Wasserman

Re: Yadda yadda yadda some more

"Larry Wall" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > : does that mean that this use of yada yada yada is already decided on and allowed? > > Yes, with the proviso that it only works that way where a term is > expected. (As a postfix operator it's short for C<..Inf>.) So, C<.

Re: Named parameters vs. slurpy hash syntax: brittle call syntax!

"Aldo Calpini" <[EMAIL PROTECTED] > wrote in message ... > > if you decide to reimplement logError to be just: > sub logError {# implicit ([EMAIL PROTECTED]) > # ... > } > using a Pair, you still have someting (a Pair object) that you ca

Re: Named parameters vs. slurpy hash syntax: brittle call syntax!

"Aldo Calpini" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > On Thu, 2004-05-06 at 02:36, Dov Wasserman wrote: > > > > After the New And Improved logError() routine is rolled out, it seems to me > > that this log statement should generate a co

Re: A12: Required Named Parameters Strike Back!

PROTECTED]>... > Looking at this, all I can think is "I hope there's a long-form of all this punctuation notation for those of us old and feeble folks". Without a clear assumption one way or the other, I imagine that Dan's suggestion is best: spell-it-out. Especially when the "requiredness" of the parameter is specifically removed by the named-only marker, I just feel that '+' is not the best choice. -Dov Wasserman

Named parameters vs. slurpy hash syntax: brittle call syntax!

a about this method call in my method body, but I don't really know what most of it means or can be used for). I can see how this might be needed in generic object construction code, but if there's not much use for it in general user-level code, perhaps the slurpy hash is a feature in search of a purpose. It should certainly be allowed, but not without more explicit and verbose syntax, given the low Huffman need. Unless of course I am totally off here. Feel free to let me know where I may have gone wrong. I'm sure that someone will if I have ;-) -Dov Wasserman [EMAIL PROTECTED]

Re: A12: Required Named Parameters Strike Back!

ve which still addresses the main points. ;-) Version 4 basically throw its hands up and decides that the semantics we want are too complex to denote in a single character. It is simple, but verbose. Probably the various '~/?/+' markers translate into similar 'named/optional/re

RE: A12: subtypes that lack methods or roles

r, less tightly coupled and in line with the MVC pattern, an HListModel class and a HListWidget class that composes an HListModel within it. -Dov Wasserman -Original Message- From: Jonathan Lang [mailto:[EMAIL PROTECTED] Sent: Saturday, April 24, 2004 12:44 AM To: [EMAIL PROTECTED] Subject: Re