1st International Workshop on Interpreted Languages
It's open for proposals and such. Quoth the organizer: the workshop is now officially announced and the Call for Papers has started http://www.sebastian-bergmann.de/InterpretedLanguages2004/ Look 'em up and put in a paper. Should be fun. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: The Sort Problem: a definitive ruling
Luke Palmer writes:
Uri Guttman writes:
DC == Damian Conway [EMAIL PROTECTED] writes:
DC @sorted = sort {-M}={$^b cmp $^a} @unsorted;
but there is no comma before @unsorted. is that correct?
Yes. Commas may be ommitted on either side of a block when used as an
argument.
That's what I thought too. But Damian gave exactly the opposite answer
to Uri's question, claiming he'd made a typo and a comma would be
required.
So which is it -- is Luke right in saying that Damian was right in the
first place? Or is Damian right in saying that his example was wrong?
Smylers
Re: The Sort Problem: a definitive ruling
Smylers writes:
Luke Palmer writes:
Uri Guttman writes:
DC == Damian Conway [EMAIL PROTECTED] writes:
DC @sorted = sort {-M}={$^b cmp $^a} @unsorted;
but there is no comma before @unsorted. is that correct?
Yes. Commas may be ommitted on either side of a block when used as an
argument.
That's what I thought too. But Damian gave exactly the opposite answer
to Uri's question, claiming he'd made a typo and a comma would be
required.
So which is it -- is Luke right in saying that Damian was right in the
first place? Or is Damian right in saying that his example was wrong?
I was wrong in saying that he was right. Those aren't simple blocks, as
Damian said, so you need the comma.
Luke
Smylers
Re: The Sort Problem: a definitive ruling
Joe Gottman writes:
sort {$_.key} (1= 'a', 10 = 'b', 2 ='c');
There is nothing in the signature of the key-extractor to suggest that
all the keys are numbers, but as it turns out they all are.
Are they? I'd been presuming that pair keys would always be strings (as
for hashes in Perl 5), and that the C = operator would
automatically quote a preceding word, stringifying it (as in Perl 5).
So the keys above are strings, albeit ones composed only of digits.
Of course that doesn't actually help with your question, since there are
other data structures of which the same could be asked.
Smylers
Re: The Sort Problem: a definitive ruling
Smylers writes:
Joe Gottman writes:
sort {$_.key} (1= 'a', 10 = 'b', 2 ='c');
There is nothing in the signature of the key-extractor to suggest that
all the keys are numbers, but as it turns out they all are.
Are they? I'd been presuming that pair keys would always be strings (as
for hashes in Perl 5), and that the C = operator would
automatically quote a preceding word, stringifying it (as in Perl 5).
So the keys above are strings, albeit ones composed only of digits.
Of course that doesn't actually help with your question, since there are
other data structures of which the same could be asked.
I think you're forgetting what language you're talking about. Those are
numbers. After this statement:
$x = '345';
C$x is a number. I should hope it would be treated as one during
multimethod dispatch.
However, I'm not saying this with authority. I'm just extrapolating.
If it's not correct, I'd appreciate that someone who knows correct me.
Luke
Re: The Sort Problem: a definitive ruling
Luke Palmer writes: After this statement: $x = '345'; C$x is a number. Oh. I'd been assuming that quote marks indicated strings, and that, while a string containing only digits could obviously be treated as a number (as in Perl 5), it wouldn't be one without being provoked. I should hope it would be treated as one during multimethod dispatch. What about: $x = '0345'; Is that a number? And if so which of these is the same as? $x = 345; $x = 0345; What about if the variable contains a line read from user input? As a programmer I'd expect that to be a string -- and if a user happens to type only digits then it'd be surprising to find the variable is considered to be of a different type. User input comes with a trailing line-break character, which would make it not a number. But would it suddenly become a number after Cchomping it? Or if the input stream was auto-chomping? Smylers
Re: The Sort Problem: a definitive ruling
At 2:49 PM -0700 2/20/04, Luke Palmer wrote: After this statement: $x = '345'; C$x is a number. No, it isn't. It's a string. Or, rather, it's a PerlScalar. I should hope it would be treated as one during multimethod dispatch. I should certainly hope *not*. If so, it's a bug. We ought to go add some tests to the test suite once we expose this bit of the engine. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: The Sort Problem: a definitive ruling
Smylers writes: Luke Palmer writes: After this statement: $x = '345'; C$x is a number. Oh. I'd been assuming that quote marks indicated strings, and that, while a string containing only digits could obviously be treated as a number (as in Perl 5), it wouldn't be one without being provoked. I should hope it would be treated as one during multimethod dispatch. What about: $x = '0345'; Is that a number? And if so which of these is the same as? $x = 345; $x = 0345; Well, since those are the same number, I imagine the, um, first? Don't forget that octal numbers look like 0o345. What about if the variable contains a line read from user input? As a programmer I'd expect that to be a string -- and if a user happens to type only digits then it'd be surprising to find the variable is considered to be of a different type. Yeah, that's a tough question. I'd want it to be a number if it were only digits, unless I wanted it to be a string. Since numbers and strings are polymorphic with one another, maybe it's wrong to think that we can differentiate. But Csort has to know when to use C = . Maybe you're right. In the presence of multimethod dispatch, it might be simpler just to tag something with either a num or str marker (I'm completely neglecting Parrot's implementation for this discussion), and treat it as its tag. That wouldn't change the behavior of adding two strings together, or concatenating two numbers, of course. Luke
Re: The Sort Problem: a definitive ruling
Uri wondered: DC No. C infix:= is the name of the binary C = operator. so how is that allowed there without a block? A Code object in a scalar context yields a Code reference. Damian
Re: The Sort Problem: a definitive ruling
Smylers wrote:
sort {$_.key} (1= 'a', 10 = 'b', 2 ='c');
There is nothing in the signature of the key-extractor to suggest that
all the keys are numbers, but as it turns out they all are.
Are they? I'd been presuming that pair keys would always be strings
Nope.
and that the C = operator would
automatically quote a preceding word, stringifying it (as in Perl 5).
Yes. But numbers aren't words. C = will continue to autostringify
*identifiers*, as in Perl 6, and those keys aren't identifiers.
Of course, if you used the pairs to populate a hash, the *hash* will convert
the non-stringific pair keys to stringific hash keys (unless the hash is
defined to take non-string keys).
Damian
Re: The Sort Problem: a definitive ruling
Luke wrote: I think you're forgetting what language you're talking about. Those are numbers. After this statement: $x = '345'; C$x is a number. I don't think so. C$x is, of course, a variable. And what it contains after that statement will depend on whether the variable is explicitly typed or not. If C$x is explicitly typed, the rvalue will have been converted to that type (if possible). If C$x is not explicitly typed (i.e. implicitly typed to CAny), then it will contain a string, since that's what the rvalue inherently is. I should hope it would be treated as one during multimethod dispatch. I would expect that the multiple dispatch mechanism would allow the CStr in C$x to be coerced to a CNum, if that's the parameter type it was seeking to match. And I would expect that the distance of that coercion would be 1. However, I'm not saying this with authority. I'm just extrapolating. If it's not correct, I'd appreciate that someone who knows correct me. Ditto. ;-) Damian
Re: The Sort Problem: a definitive ruling
Smylers wrote: Oh. I'd been assuming that quote marks indicated strings, and that, while a string containing only digits could obviously be treated as a number (as in Perl 5), it wouldn't be one without being provoked. Correct. What about: $x = '0345'; Is that a number? Nope. A string (unless C$X is otherwised typed). What about if the variable contains a line read from user input? As a programmer I'd expect that to be a string You'd be right (unless, of course, the variable's storage type forced a coercion during the assignment). Damian
