Semantics of vector operations
A thought occurred to me. What should this return: [1,2,3] Â+Â [4,5,6] At first glance, one might say [5,7,9]. But is that really the best way to go? I'm beginning to think that it should be the same as whatever [1,2,3]+[4,5,6] is, hopefully an error. Here's my reasoning. Substitute $a = [1,2,3] and $b = [4,5,6]. Those are list I, after all. So now it becomes: $a Â+Â $b That might just be okay, since they're both listrefs, and you shouldn't expect a vector on two scalars to do much besides dereference its arguments. But now, instead of $a, use the real list (1,2,3): (1,2,3) Â+Â $b That looks extremely different from before. That looks like it's adding $b to each of (1,2,3). Not only that, but say you have: $x Â+Â $y $x is a number, and $y is a listref. Extrapolating from before, you'd think that this should add $x to each of $y's elements. But this is starting to feel like run-time DWIMmery, which is almost always a Bad Idea (favoring syntactic DWIMmery). So I'm going to argue that: [1,2,3] Â+Â [4,5,6] either give an error because you can't add listrefs, or give a "useless use of vector operation on two scalars" error. And if you want what we originally thought, use: (1,2,3) Â+Â (4,5,6) @$a Â+Â @$b $x Â+Â @$y Luke Ã
This week's summary
The Perl 6 Summary for the week ending 20040118 I hope you'll forgive the lack of banter before we start in on perl6-internals. Threads. Again. Still more proposals about threads this week. Jeff Clites offered some notes based on the Java Virtual Machine's threading model. Surprisingly, this was the week's only threads thread. Next week: Dan starts to outline the design that's going to be implemented. http://tinyurl.com/2fk4f Questions about abstract PMCs Stéphane Payrard had some questions about abstract PMCs and whether they were needed in core_pmcs.h and pmctypes.pasm to make PMC type checking work in IMCC. Leo Tötsch answered questions, but didn't think they were actually needed in those files. Discussion ensued. http://tinyurl.com/3bqxg Docs and releases Tim Bunce wondered whether a date had been set for the next release. He also pointedly wondered if the docs were up to date with best practises and whether having them up to date would be a goal for the next release. Dan answered: "No", "no" and "yes, bordering on a requirement and not just a goal". Discussion ensued again. For some reason this thread flushed out a few 'shy lurkers' so let's extend a big hello to Paul Cochrane, Herbert Snorrason, Matt Diephouse, Robin Redeker, Richard Holden and Mark Solinski. http://tinyurl.com/yucb2 Making continuations work properly The work of getting continuations to close over the various bits and pieces the should close over continues; it seems there's rather more to doing the Right Thing than meets the eye. http://tinyurl.com/2bvpj "new_noinit" and "init" ops Luke Palmer was trying to implement a loop using a continuation. He wanted to be able to defer initialization of a continuation so he implemented two stage instantiation & initialization; wrapped it up in two new ops, "new_noinit" and "init", and posted the resulting patch to the list. Michal Wallace thought it best to just use a lexical. Then he perpetrated a spectacularly extended metaphor about Parrot entitled *Mr Parrot's Neighborhood*, which probably works best if you don't automatically correct the spelling of neighbourhood. http://tinyurl.com/24myr http://tinyurl.com/3xrus -- Mr Parrot's neighborhood Namespace stuff Jeff Clites revisited a thread from a while back about namespaces. His discussion centred on whether the namespace part of a name should be, logically a string "Global::Namespace::Hierarchy" or list of strings "["Global", "Namespace", "Hierarchy"]". He argued that it made sense to just use a simple thing and asked what we actually gained from having a hierarchy. Dan wants a hierarchy because it makes cross language sharing of namespaces easier. Larry wants a hierarchy 'cos it makes all sorts of things easier. Tim Bunce offered another proposal which received qualified approval from both Dan & Leo. http://tinyurl.com/2j8gb http://tinyurl.com/3fecc -- Tim's proposal Parrot string docs Robert Eaglestone had a bunch of questions about Parrot's String documentation. Answers were forthcoming. http://tinyurl.com/ysz54 IMCC v1 feature freeze Melvin Smith announced a feature freeze for IMCC version 1 and called for bug reports for it. He plans to get imcc1 working as correctly as possible and frozen within a couple of weeks before starting the really major work (and deprecation of features) on IMCC 2. There was a certain amount of wrangling about CVS issues, but it was generally thought to be a good idea. http://tinyurl.com/2ooy5 Managed and unmanaged structs Dan had some thoughts about accessing and generally monkeying around with C structs and added a couple of related tasks to the todo list. Leo pointed out that quite a bit of it was done, and pointed out where further work was needed. http://tinyurl.com/2a4jl Loading bytecode at runtime Dan did some more design work on how runtime loading of bytecode should be handled. http://tinyurl.com/22rst The todo list Dan was reminded that we have a full, working, RT installation so he's started creating tickets for each todo. This should make for better tracking and ownership of tasks. Hurrah. He asked for a volunteer or two to manage the todo queue. Dave Pippenger and Stephane Peiry stepped up to the plate with heartening alacrity. Go guys. http://tinyurl.com/2wxou http://bugs6.perl.org/ Numeric formatting More design from Dan. This time he was thinking about numeric formatting. His initial plan was to lift the formatting rules from SQL, but I'm not sure if that plan survived contact with Michael Scott who pointed out that ICU (the Unicode library that's already included in the Parrot tree) has its own number formatting API. After some discussion in
Re: Semantics of vector operations
On Tue, Jan 20, 2004 at 01:54:33AM -0700, Luke Palmer wrote: : A thought occurred to me. What should this return: : : [1,2,3] »+« [4,5,6] : : At first glance, one might say [5,7,9]. But is that really the best : way to go? I'm beginning to think that it should be the same as : whatever [1,2,3]+[4,5,6] is, hopefully an error. Doing what you expect at first glance is also called "not violating the principle of least surprise". : Here's my reasoning. Substitute $a = [1,2,3] and $b = [4,5,6]. Those : are list I, after all. So now it becomes: : : $a »+« $b : : That might just be okay, since they're both listrefs, and you shouldn't : expect a vector on two scalars to do much besides dereference its : arguments. But now, instead of $a, use the real list (1,2,3): : : (1,2,3) »+« $b : : That looks extremely different from before. That looks like it's adding : $b to each of (1,2,3). But the programmer probably knows whether $b contains a list ref or a scalar. This is primarily a problem to the reader of the code. And what if the programmer wants it to do the Right Thing regardless of whether $b is a scalar or a list? I suspect that there are mathematical operations that should generalize down to 0 dimensions, not just 1 dimension... : Not only that, but say you have: : : $x »+« $y : : $x is a number, and $y is a listref. Extrapolating from before, you'd : think that this should add $x to each of $y's elements. But this is : starting to feel like run-time DWIMmery, which is almost always a Bad : Idea (favoring syntactic DWIMmery). Well, you can say that, but the whole notion of method dispatch is based on the idea that run-time dwimmery is better than syntactic dwimmery. But see below for a syntactic proposal. : So I'm going to argue that: : : [1,2,3] »+« [4,5,6] : : either give an error because you can't add listrefs, or give a "useless : use of vector operation on two scalars" error. And if you want what : we originally thought, use: : : (1,2,3) »+« (4,5,6) : @$a »+« @$b : $x »+« @$y On the other hand, it's possible that we should extend the visual metaphor of »« and apply it asymmetrically when one of the arguments is expected to be scalar. That would mean that your last three lines would be written: (1,2,3) »+« (4,5,6) $a »+« $b $x +« $y What's more, a unary vector op would then just be -« @bar This also lets us use an array in its scalar sense for its length: @foo »+ @bar So to add the length of an array to each of its elements, you'd be able to say: @foo »+= @foo; It might take some getting used to, but I kind of like this idea, especially if you pronounce » and « as "each". (Doubtless some joker will propose that we pronounce them "leach" and "reach"...) So @foo »= 0; unambiguously means "@foo each equals 0". You can still say @foo »=« 0; but then you're relying on the dwimmery to realize that the thing on the right is a scalar value. So the difference between @foo »= $bar and @foo »=« $bar is that the second one has to look at $bar at runtime to see if it "does" the list thing, and if not, listify it. Note that if we do take this approach, we'll have to require the space after = in @list = «a b c d e»; Larry
Comma Operator
About a month ago, a thread here suggested that we change the meaning of
the comma operator. Currently, in scalar context the expression
foo(), bar()
means "evaluate foo(), discard the result, then return the value of bar()".
It was suggested that this be changed to return the 2-element array (foo(),
bar()). Has Larry ruled on this yet?
By the way, even if we do make this change, I think that in void context
the expression
foo(), bar()
should still simply evaluate its parameters in order for their side-effects.
This would allow comma expressions to remain as-is in loop statements
(formerly for statements), which is where most of them are found anyway.
For instance
loop (my ($x = 0, $y = 10); $x < $y; ++$x, --$y) {...}
Joe Gottman
Re: Semantics of vector operations
Larry Wall wrote: > Note that if we do take this approach, we'll have to require the space > after = in > > @list = «a b c d e»; Perl 6 has already set the precedent of the presence or absence of whitespace being syntactically important (as opposed to Python, where the amount and type of whitespace is syntactically important). As such, I'd have no problem with this. = Jonathan "Dataweaver" Lang __ Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus
RE: Semantics of vector operations
> -Original Message- > From: Larry Wall [mailto:[EMAIL PROTECTED] > On the other hand, it's possible that we should extend the visual metaphor > of »« and apply it asymmetrically when one of the arguments is expected to > be scalar. That would mean that your last three lines would be written: > > (1,2,3) »+« (4,5,6) > $a »+« $b > $x +« $y > > What's more, a unary vector op would then just be > > -« @bar > > This also lets us use an array in its scalar sense for its length: > > @foo »+ @bar If only from a syntax-highlighting point of view, this is a horrible proposal. Make it die. =Austin
Re: Comma Operator
Joe Gottman wrote: >About a month ago, a thread here suggested that we change the meaning > of the comma operator. Currently, in scalar context the expression > foo(), bar() > means "evaluate foo(), discard the result, then return the value of > bar()". > It was suggested that this be changed to return the 2-element array > (foo(), bar()). Has Larry ruled on this yet? Not that I'm aware of. For the most part, the previous discussion was focusing on what to replace the comma with in the case of "discard all but the last result", and my impression was that any ruling on the change would likely be contingent on the presence or absence of a suitable replacement. That said, > By the way, even if we do make this change, I think that in void > context the expression > foo(), bar() > should still simply evaluate its parameters in order for their side- > effects. This would allow comma expressions to remain as-is in loop > statements (formerly for statements), which is where most of them are > found anyway. I do like this suggestion. In the majority of cases where I've used the comma operator, I've either enclosed the whole thing in parentheses to turn it into a list, or I've treated it as a sequence of operators where even the last result got discarded. I've rarely been interested in just the last result, and I wouldn't mind that functionality being provided by means of a C function which evaluates the list parameters for their side effects and returns the value of the last list parameter. = Jonathan "Dataweaver" Lang __ Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus
RE: Semantics of vector operations
Austin Hastings wrote:
> Larry Wall wrote:
> > On the other hand, it's possible that we should extend the visual
> > metaphor of »« and apply it asymmetrically when one of the arguments
> > is expected to be scalar. That would mean that your last three lines
> > would be written:
> >
> > (1,2,3) »+« (4,5,6)
> > $a »+« $b
> > $x +« $y
> >
> > What's more, a unary vector op would then just be
> >
> > -« @bar
> >
> > This also lets us use an array in its scalar sense for its length:
> >
> > @foo »+ @bar
>
> If only from a syntax-highlighting point of view, this is a horrible
> proposal. Make it die.
How is this any worse than syntax-highlighting a full »« construct?
Incidently, it might make matters easier if you forbid whitespace between
the »« operator modifier and its operator. Indeed, you might want to look
into including a trait for operator declarations which allows you to
modify the importance of whitespace - something like:
sub circumfix:»« (&o is infix) is whitespace(forbidden) {...}
sub prefix:» (&o is postfix|infix) is whitespace(forbidden) {...}
sub postfix:« (&o is prefix|infix) is whitespace(forbidden) {...}
=
Jonathan "Dataweaver" Lang
__
Do you Yahoo!?
Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes
http://hotjobs.sweepstakes.yahoo.com/signingbonus
Re: A modest question (Damian, see last para please?)
Austin Hastings wrote:
role Dog {must bark();}
role Tree {must bark();}
class crossPerson {
method bark() {speak_sharply;}
}
class Trog does Tree does Dog {
method bark() {bark_like_a_trog;}
}
multi sub purchase(Dog $mansBestFriend) {...}
multi sub purchase(Tree $shrubbery) {...}
multi sub purchase($noisemaker must bark()) {...}
my crossPerson $jack;
purchase $jack;
my Trog $spot;
purchase $spot;
Which, if any, of the subs should be called in each case? Or should the
compiler complain of duplicate definitions?
$jack is a crossPerson, which absolutely does NOT have the Dog or Trog or
Tree classes in its C chain. If Dog and Tree are both "inferred" or
"inferrable" classes, then the two multi declarations (Dog and Tree
arguments) are identical.
Thus, there's probably a warning or an error about conflict of inference for
any call that's not passed an explicitly typed object.
I would say that in the above examples, the calls to C must throw a
run-time exception, since in both calls, all three of the variants are equally
"close" to their argument lists in parameter space.
An exhaustive analysis of the variants could of course detect that the three
signatures of the variants are all equivalent at compile-time, but I'm not
sure Perl 6 will have (or indeed ought to have) such a robust static type
inference mechanism on signatures. Mainly because that kind of inference
easily becomes combinatoric in complexity as roles/classes become larger and
as the number of parameters to each variant increases.
Damian
