Re: Split PMCs
Dan Sugalski <[EMAIL PROTECTED]> writes: >At 07:39 PM 4/19/2001 +, [EMAIL PROTECTED] wrote: >>Depends what they are. The scheme effectively makes the part "mandatory" >>as we will have allocated space whether used or not. > >Well, we were talking about all PMCs having an int, float, and pointer >part, so it's not like we'd be adding anything. Segregating them out might >make things faster for those cases where we don't actually care about the >data. OTOH that might be a trivially small percentage of the times the >PMC's accessed, so... What is the plan for arrays these days? - if the float parts of the N*100 entries in a perl5-oid AV were collected you might get "packed" arrays by the back door. > >>So it depends if access pattern means that the part is seldom used, >>or used in a different way. >>As you say works well for GC of PMCs - and also possibly for compile-time >>or debug parts of ops but is not obviously useful otherwise. > >That's what I was thinking, but my intuition's rather dodgy at this level. >The cache win might outweigh other losses. > >> >I'm thinking that passing around an >> >arena address and offset and going in as a set of arrays is probably >> >suboptimal in general, >> >>You don't, you pass PMC * and have offset embedded within the PMC >>then arena base is (pmc - pmc->offset) iff you need it. > >I was trying to avoid embedding the offset in the PMC itself. Since it was >calculatable, it seemed a waste of space. But passing extra args around is fairly expensive when they are seldom going to be used. Passing an extra arg through N-levels is going to consume instructions and N * 32 bits of memory or so. > >If we made sure the arenas were on some power-of-two boundary we could just >mask the low bits off the pointer for the base arena address. Evil, but >potentially worth it at this low a level. That would work ;-) -- Nick Ing-Simmons <[EMAIL PROTECTED]> Via, but not speaking for: Texas Instruments Ltd.
Re: Tying & Overloading
Filipe Brandenburger <[EMAIL PROTECTED]> writes: > >The big problem with || and && is that they don't evaluate their second >argument until it's needed, that's what allows us to do something like >`$xxx || die'. That is still a run-time thing though - so no real barrier to overloading it. >I remember reading one possible use of it to do a seamless >Perl to SQL query engine, like writing > >select($name eq 'FILIPE' && $salary > 10); > >would do a SQL query. (It wasn't actually like this, but it was something >like it). I haven't seen any use other than this for overloading && and ||, >please tell me if there is one. I have an app which uses overload to cause perl to build a parse tree (of perl objects). Not being able to overload && and || is an irritant in this area as VHDL and Verilog that parse is going to translate to both have equivalent constructs. > >Now, this kind of thing above, this would actually be done much better by a >pluggable parser (or better, a pluggable code generator, that takes the >abstract syntax tree of the parsed perl code), that instead of generating >perl bytecode (or whatever bytecode), generates a SQL query. The aim of my scheme above is to use the perl parser - as a parser for a language the user is familier with - and build the alien parse tree from it. > >As I foresee it, dealing with the late evaluation needed for && and || >wouldn't be worth the little win of being able of defining the Perl<->SQL >translator with overload. Dealing the the late eval is easy just let the overload code do it same as for any other overload. > >Please tell me if there really is an use for overloading && and || that >would not be better done with source filtering, then I will (maybe) >reconsider my opinion. > >- Branden -- Nick Ing-Simmons <[EMAIL PROTECTED]> Via, but not speaking for: Texas Instruments Ltd.
Re: Tying & Overloading
Larry Wall <[EMAIL PROTECTED]> writes:
>: At 06:20 PM 4/20/2001 -0300, Filipe Brandenburger wrote:
>: >Please tell me if there really is an use for overloading && and || that
>: >would not be better done with source filtering, then I will (maybe)
>: >reconsider my opinion.
>
>I think it's a category error to talk about overloading && and ||,
>which are not really operators so much as they are control flow
>constructs.
I want to be able to "overload" those as well ;-)
>You really have to talk about overloading boolean context
>in general.
Only if you are going to execute the result in the normal perl realm.
Consider using the perl parser to build a parse tree - e.g. one to
read perl5 and write perl 6. This works for all expressions except
&&, || and ?: because perl5 cannot overload those - so
$c = ($a && &b) ? $d : $e;
calls the bool-ness of $a and in the defered execution mode of a translator
it wants to return not true/false but "it depends on what $a is at run-time".
It cannot do that and is not passed $b so cannot return
new Operator::->('&&',$a,$b)
--
Nick Ing-Simmons <[EMAIL PROTECTED]>
Via, but not speaking for: Texas Instruments Ltd.
Postfix "!"
If postfix "!" was up for grabs - which it probably isn't - what would
you do with it?
One interesting suggestion was to have it as a shorthand for assertion:
sub foo {
(@_ > 0)!;
...
}
(Or even have ! be a valid statement terminator, so "(@_>0)!" would work.)
Or you could have it doing something to variables: $a = $b! + $c;
(But what?)
Fun, eh?
--
The use of COBOL cripples the mind; its teaching should, therefore, be
regarded as a criminal offence.
-- Edsger W. Dijkstra, SIGPLAN Notices, Volume 17, Number 5
Re: Tying & Overloading
On Mon, 23 Apr 2001 13:19:24 +0100, Graham Barr <[EMAIL PROTECTED]> wrote: > > $a = $b ~ $c; # Mmm! > > > > I like that last one a lot, because it doesn't disturb anything. > > You'd have to alter ~'s precedence so that binary ~ is higher > > than named unary operators. (It's print($a~$b), not print $a (~b).) > > I am not sure I do like the use of ~ here. It does not screan concatenate > to me (but then again neither did . when I started perl) > > I am thinking that maybe it should be a 2 character operator with at > least one of then being + as + is common in many other languages > for doing concatenation. like ++ ? we have ** already for exponents -- H.Merijn BrandAmsterdam Perl Mongers (http://www.amsterdam.pm.org/) using perl-5.6.1, 5.7.1 & 623 on HP-UX 10.20 & 11.00, AIX 4.2, AIX 4.3, WinNT 4, Win2K pro & WinCE 2.11 often with Tk800.022 &/| DBD-Unify ftp://ftp.funet.fi/pub/languages/perl/CPAN/authors/id/H/HM/HMBRAND/
Re: Tying & Overloading
On Mon, Apr 23, 2001 at 02:31:55PM +0200, H.Merijn Brand wrote: > On Mon, 23 Apr 2001 13:19:24 +0100, Graham Barr <[EMAIL PROTECTED]> wrote: > > > $a = $b ~ $c; # Mmm! > > > > > > I like that last one a lot, because it doesn't disturb anything. > > > You'd have to alter ~'s precedence so that binary ~ is higher > > > than named unary operators. (It's print($a~$b), not print $a (~b).) > > > > I am not sure I do like the use of ~ here. It does not screan concatenate > > to me (but then again neither did . when I started perl) > > > > I am thinking that maybe it should be a 2 character operator with at > > least one of then being + as + is common in many other languages > > for doing concatenation. > > like ++ ? I don't think that would be a good choice. Try translating these statements $c = $a.++$b; $d = $a++.$b; Graham.
Re: Tying & Overloading
Hmm.
Larry Wall wrote: [to [EMAIL PROTECTED]]
> This is much like a method:
>
> my Cat &chases (Dog $spot) : = { ... };
>
> In either case, Cat is the type of the return value, and really has
> little to do with the implementation of the function (or hash) itself.
> $spot.chases is a Dog method, not a Cat method. In the same way,
> %chases is a Catalog method, not a Cat method.
This wouldn't mean that anyone is thinking of getting us object
dot-syntax, now
would it? After giving it a thought, it seems that it can _mostly_ be
disambiguated from the concatenation operator. Whatever mostly means.
# given
$cat = bless [], 'Cat';
$purr = 'fish';
# we could have
$cat.purr(); # easy: $cat->purr()
$cat.$purr;# easy: "Catfish"
Cat.purr();# easy: Cat->purr()
Cat.$purr(); # hmmm: Cat() . "fish" (or Cat->$purr?)
# and
$cat = 'Cat';
$cat.purr; # Cat->purr() (or "Cat" . purr()?)
If $cat has method purr() and one has defined function purr(), all of
the above become ambiguous... So? A cut with the disambiguation-razor
would fix that, no?
This would make my life complete, especially if we get to do stuctish
things as well.
It seems that John Porter said something about this back in September
(http://ml.perl.org/archive.develooper.com/perl6-language_perl.org/msg04864.html),
and it has come up some ten times, but never had any final discussion.
There may be a good reason for that :(
Thanks for your<:plural> attention && now back to lurking,
d.
--
davíð helgason[EMAIL PROTECTED]
Re: Tying & Overloading
On Mon, Apr 23, 2001 at 01:49:36PM +0200, Dav?? Helgason wrote: > This wouldn't mean that anyone is thinking of getting us object > dot-syntax, now would it? > After giving it a thought, it seems that it can _mostly_ be > disambiguated from the concatenation operator. Whatever mostly means. Or we change the concatenation operator. $a = $b & $c; # Do people really use Perl for bit fiddling? $a = $b # $c; /* Urgh */ $a = $b ~ $c; # Mmm! I like that last one a lot, because it doesn't disturb anything. You'd have to alter ~'s precedence so that binary ~ is higher than named unary operators. (It's print($a~$b), not print $a (~b).) -- There is no distinction between any AI program and some existent game.
Re: Tying & Overloading
On Mon, Apr 23, 2001 at 01:02:50PM +0100, Simon Cozens wrote: > $a = $b ~ $c; # Mmm! Oops. I really can't claim the credit for that one; I seem to have been subconsciously influenced by one of Larry's previous musings. -- Pretty, smart, sane:Pick two. - Ron Echeverri
Re: Tying & Overloading
On Mon, Apr 23, 2001 at 01:02:50PM +0100, Simon Cozens wrote: > > Or we change the concatenation operator. > > $a = $b & $c; # Do people really use Perl for bit fiddling? Yes, all the time. > $a = $b # $c; /* Urgh */ > > $a = $b ~ $c; # Mmm! > > I like that last one a lot, because it doesn't disturb anything. > You'd have to alter ~'s precedence so that binary ~ is higher > than named unary operators. (It's print($a~$b), not print $a (~b).) I am not sure I do like the use of ~ here. It does not screan concatenate to me (but then again neither did . when I started perl) I am thinking that maybe it should be a 2 character operator with at least one of then being + as + is common in many other languages for doing concatenation. Graham.
Re: Tying & Overloading
At 05:32 PM 20/04/2001 -0400, Dan Sugalski wrote: >At 06:20 PM 4/20/2001 -0300, Filipe Brandenburger wrote: >>Please tell me if there really is an use for overloading && and || that >>would not be better done with source filtering, then I will (maybe) >>reconsider my opinion. > >@foo = @bar && @baz; > > Dan Well, Ok, that's an use for &&, but that's not the same use for && that there is in $foo = $bar && $baz; That's because in the former (@foo), there's no pre-assigned behaviour to && with arrays in list context now, as there is with the latter, with $foo, where there is a pre-assigned behaviour for && which only evaluates $baz depending on the boolean context of $bar. Also, on @foo = @bar && @baz, the && would depend on @bar (would be the method in @bar's vtabler), right? The questions are: If I issue @xyzzy = @bar, and I do @foo = @xyzzy && @baz, the `overloaded' && of @bar is copied to @xyzzy ? In this case, this goes the same place as FETCH/STORE/... for tying an array. But then, If I issue @xyzzy = (1, @bar), it wouldn't have how to copy the `overloaded' behaviour of @bar, then I see some inconsistence here. Well, the main point here is: It's probably worthless to discuss what goes or doesn't go into vtables without knowing for sure how the language will be and what will be its behaviour. That's why, in my first attempt to explaining tying and overloading with vtables, I tried to be the most conservative possible, considering only Perl 5 as a base for it. Since Perl 6 will be built as an evolution of Perl 5, the vtables model used on Perl 6 (the final one) will be possibly derived as an extension of this model, if it's shown that it gives Perl 6 the extensibility features that are desired. - Branden
Re: Postfix "!"
On Mon, 23 Apr 2001 13:22:54 +0100, Simon Cozens <[EMAIL PROTECTED]> wrote:
> If postfix "!" was up for grabs - which it probably isn't - what would
> you do with it?
>
> One interesting suggestion was to have it as a shorthand for assertion:
>
> sub foo {
> (@_ > 0)!;
> ...
> }
>
> (Or even have ! be a valid statement terminator, so "(@_>0)!" would work.)
>
> Or you could have it doing something to variables: $a = $b! + $c;
> (But what?)
>
> Fun, eh?
DWIM would be "faculty"
--
H.Merijn BrandAmsterdam Perl Mongers (http://www.amsterdam.pm.org/)
using perl-5.6.1, 5.7.1 & 623 on HP-UX 10.20 & 11.00, AIX 4.2, AIX 4.3,
WinNT 4, Win2K pro & WinCE 2.11 often with Tk800.022 &/| DBD-Unify
ftp://ftp.funet.fi/pub/languages/perl/CPAN/authors/id/H/HM/HMBRAND/
Re: Tying & Overloading
"H.Merijn Brand" wrote:
>
> > > $a = $b ~ $c; # Mmm!
> > >
> > > I like that last one a lot, because it doesn't disturb anything.
> > > You'd have to alter ~'s precedence so that binary ~ is higher
> > > than named unary operators. (It's print($a~$b), not print $a (~b).)
> >
> > I am not sure I do like the use of ~ here. It does not screan concatenate
> > to me (but then again neither did . when I started perl)
> >
> > I am thinking that maybe it should be a 2 character operator with at
> > least one of then being + as + is common in many other languages
> > for doing concatenation.
>
> like ++ ?
>
> we have ** already for exponents
I _really_ think dot-syntax would make perl prettier as well as make it
more acceptable to the world of javacsharpbasic droids. Which is some
kind of goal, no?
I suspect that we will never agree on anything here though.
Which of qw[~ ++ +~ + &] do we dislike the least? Using + would be
nice, but introduce no end of problems with number/sting behaviour. '&'
is too much like a certain unpopular language. And there was no end to
the quabbling :(
If we can make the concatenation into something else, we free the dot to
do "string".length() and innumerable other niceties.
Suggestions?
ps. What do you think about the following sentence: "we should steal
more from ruby"? a) disgusting, b) uninteresting, c) clever, d)
wonderful.
pps. if ($_ === qw(b c d)) {
"=== 'is in' operator",
"dot operator remapped to mean",
"objectspace array/iterator as in ruby, giving access to all existing
data (but of course more complete than rubys rather flaky
implementation",
}
--
davíð helgason[EMAIL PROTECTED]
Re: Tying & Overloading
On Mon, 23 Apr 2001 13:02:50 +0100, Simon Cozens <[EMAIL PROTECTED]> wrote: > On Mon, Apr 23, 2001 at 01:49:36PM +0200, Dav?? Helgason wrote: > > This wouldn't mean that anyone is thinking of getting us object > > dot-syntax, now would it? > > > > > After giving it a thought, it seems that it can _mostly_ be > > disambiguated from the concatenation operator. Whatever mostly means. > > Or we change the concatenation operator. > > $a = $b & $c; # Do people really use Perl for bit fiddling? ABSOLUTELY! Ever done vec? It's even well documented what stringwise & should do. (Though I have to admit it's not DWIM) > $a = $b # $c; /* Urgh */ > > $a = $b ~ $c; # Mmm! > > I like that last one a lot, because it doesn't disturb anything. > You'd have to alter ~'s precedence so that binary ~ is higher > than named unary operators. (It's print($a~$b), not print $a (~b).) -- H.Merijn BrandAmsterdam Perl Mongers (http://www.amsterdam.pm.org/) using perl-5.6.1, 5.7.1 & 623 on HP-UX 10.20 & 11.00, AIX 4.2, AIX 4.3, WinNT 4, Win2K pro & WinCE 2.11 often with Tk800.022 &/| DBD-Unify ftp://ftp.funet.fi/pub/languages/perl/CPAN/authors/id/H/HM/HMBRAND/
RE: Tying & Overloading
At 05:58 PM 20/04/2001 -0400, Dan Sugalski wrote: >At 06:49 PM 4/20/2001 -0300, Filipe Brandenburger wrote: >>What would happen when $a = $b? Semantically, according to the tying and >>overloadings, the bignumber on $b should be written to the file $a is >>tied to, and when fetching the value of $a, it should return a bignumber, >>with all the overloaded operations that make the bignumber make sense. >> >>But if I have all in one vtable (both the tying and overloading methods), >>I wouldn't have how to set the vtable of $a according to the vtable of $b. > >What happens with the types of data during an assignment is a matter for >language design, not for internals. It can (and should) go either way >depending on how the parser spits out bytecode. > >Both ways are perfectly correct. The only question is which way it should >go. (Or, knowing Larry, which data type is tighter binding or something of >the sort) > > Dan Yes, both are probably possible, the question is that copying the tying behaviour of a variable to another one is not an assignment, but more like an aliasing, in my point of view. If two variables are tied to the same object, they essentially are the same. Of course this operation is useful, that's why there were typeglobs in Perl 5, but assignment is as important, if not more. And, as I see it, it's not possible to support assignment (keeping current correct overloading and tying behaviour), without keeping separate vtables for variables and values. - Branden
Re: Tying & Overloading
On Mon, Apr 23, 2001 at 10:48:53AM -0400, John Porter wrote: > Perl: Snobol with embedded gravel. > $a = $b $c; *snort* Actually, I'd rather like that to be equivalent to $a = $c->$b; -- Complete the following sentence: People *ought* to weigh bricks, cats and cinnamon in the same units because... - Ian Johnston
Re: Postfix "!"
On Mon, Apr 23, 2001 at 10:47:26AM -0400, John Porter wrote: > If it wasn't the factorial operator, our math caucus would > be rather unhappy... Good, good. :) $$y = \pi + 4 x $$, "Just another Perl and \TeX\ hacker"; -- Momomoto, Famous Japanese, can swallow his nose.
Re: Tying & Overloading
Simon Cozens wrote: > John Porter wrote: > > $a = $b $c; > > Actually, I'd rather like that to be equivalent to > $a = $c->$b; Oops, sorry, I forgot the smiley. Oh, but thinking seriously about it: do we really want to keep the "indirect object" syntax? It is said to be a major source of ambiguity in perl. -- John Porter
Re: Postfix "!"
On Mon, 23 Apr 2001 14:57:50 +0200, Davíð Helgason <[EMAIL PROTECTED]> wrote:
> "H.Merijn Brand" wrote:
> >
> > On Mon, 23 Apr 2001 13:22:54 +0100, Simon Cozens <[EMAIL PROTECTED]> wrote:
> > > If postfix "!" was up for grabs - which it probably isn't - what would
> > > you do with it?
> > >
> > > One interesting suggestion was to have it as a shorthand for assertion:
> > >
> > > sub foo {
> > > (@_ > 0)!;
> > > ...
> > > }
> > >
> > > (Or even have ! be a valid statement terminator, so "(@_>0)!" would work.)
> > >
> > > Or you could have it doing something to variables: $a = $b! + $c;
> > > (But what?)
> > >
> > > Fun, eh?
> >
> > DWIM would be "faculty"
>
> yeah, but kinda useless unless when teaching (with) perl.
>
> What about assert (and having just written that, I notice that is
> exactly what Cozens suggested So it must be a good idea)?
>
>
> I like it.
>
> When do we get to use unicode operators? (inverse question and
> exclamation marks!!!)
I'd personally like to see the plusminus, both as operator and as leading
parameter mark ;-P
if ($a ± $b) { ±c = 1; }
meaning if $a is near to $b (almost the same being defined by $±)
--
H.Merijn BrandAmsterdam Perl Mongers (http://www.amsterdam.pm.org/)
using perl-5.6.1, 5.7.1 & 623 on HP-UX 10.20 & 11.00, AIX 4.2, AIX 4.3,
WinNT 4, Win2K pro & WinCE 2.11 often with Tk800.022 &/| DBD-Unify
ftp://ftp.funet.fi/pub/languages/perl/CPAN/authors/id/H/HM/HMBRAND/
Re: Tying & Overloading
> Or we change the concatenation operator. > > $a = $b & $c; # Do people really use Perl for bit fiddling? Oy! You keep your greedy fingers off my bitvectors. (Incidentally I hope that in Perl 6 there's a way to shift the bitvector aspect of $s: currently $s << and $s >> to shift the numeric aspect of the $s. Currently there's no way to shift bitvectors.) > $a = $b # $c; /* Urgh */ > > $a = $b ~ $c; # Mmm! > > I like that last one a lot, because it doesn't disturb anything. > You'd have to alter ~'s precedence so that binary ~ is higher > than named unary operators. (It's print($a~$b), not print $a (~b).) Which reminds me: guess what $s=~0 parses as now? Not as the equivalent of $s = 0xfff..fff -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
Re: Postfix "!"
Simon Cozens wrote: > If postfix "!" was up for grabs - which it probably isn't - what would > you do with it? If it wasn't the factorial operator, our math caucus would be rather unhappy... -- John Porter
Re: Tying & Overloading
Simon Cozens wrote: > Or we change the concatenation operator. Perl: Snobol with embedded gravel. $a = $b $c; -- John Porter
Re: Tying & Overloading
Nick Ing-Simmons writes: : >You really have to talk about overloading boolean context : >in general. : : Only if you are going to execute the result in the normal perl realm. : Consider using the perl parser to build a parse tree - e.g. one to : read perl5 and write perl 6. This works for all expressions except : &&, || and ?: because perl5 cannot overload those - so : : $c = ($a && &b) ? $d : $e; : : calls the bool-ness of $a and in the defered execution mode of a translator : it wants to return not true/false but "it depends on what $a is at run-time". : It cannot do that and is not passed $b so cannot return I think using overloading to write a parser is going to be a relic of Perl 5's limitations, not Perl 6's. Larry
Re: Tying & Overloading
At 05:21 PM 20/04/2001 -0400, Dan Sugalski wrote: >At 06:08 PM 4/20/2001 -0300, Filipe Brandenburger wrote: >>I'd rather be flexible on the low-level and have `default' or `catch-all' >>functions that call the cmp-style function than have to `trick' the >>language by modifying the parser to do what we want. But that's really >>not my choice. I only think implementing backwards-compatible `use >>overload' without these entries would be nasty... > >You're thinking at both too high and too low a level, I think. (I've been >working through what you've written, but there's rather a lot of it) Please be more specific... I really am not understanding with what you mean by ``too high level'' and ``too low level''. I feel you mean something important but I'm not getting it yet... >It might be best if everyone thought of the interpreter as essentially >language-neutral. Some stuff is appropriate for the interpreter (basically >the vtable stuff) while other things like the perl-source-visible bits of >overloading are more the province of the parser. Source visible bits of overloading??? I though overloading was about changing the behaviour of an operation without having to change the source code... I thought it was about writing $a + $b when what actually happens is $a->PLUS($b) or something like this... If you mean the parser should do the translation of ``$a + $b'' to something like ``$a->PLUS($b)'' (or better the call on the vtable entry of $a that etc. etc.), well, Ok, but if you mean the parser should do it only to what is overloaded, well, the parser has no way to know what is and what is not overloaded... Or you mean the perl-source-visible bits of *defining* overloaded behaviour? I think these should be easy once we have the underlying model to support overloading... - Branden
Re: Tying & Overloading
[This started out just as a response, but I've been wading through the
original post at the same time so it sort of drifts]
At 02:47 PM 4/23/2001 -0300, Filipe Brandenburger wrote:
>At 05:21 PM 20/04/2001 -0400, Dan Sugalski wrote:
>>At 06:08 PM 4/20/2001 -0300, Filipe Brandenburger wrote:
>>>I'd rather be flexible on the low-level and have `default' or
>>>`catch-all' functions that call the cmp-style function than have to
>>>`trick' the language by modifying the parser to do what we want. But
>>>that's really not my choice. I only think implementing
>>>backwards-compatible `use overload' without these entries would be nasty...
>>
>>You're thinking at both too high and too low a level, I think. (I've been
>>working through what you've written, but there's rather a lot of it)
>
>Please be more specific... I really am not understanding with what you
>mean by ``too high level'' and ``too low level''. I feel you mean
>something important but I'm not getting it yet...
Well, as an example, the add opcode calls the add vtable function of the
left-hand PMC. That's it. What goes in that vtable and how it gets there
(overloading, tying, type methods, Arcturan mind control rays...) is
irrelevant, really. Talking about tying, overloading, or whatever doesn't
really matter--the only difference there is which vtable methods get
provided by perl and which the module provides. Talking about perl-level
overloading interfaces and whatnot obscures the underlying mechanisms.
Also there's the matter of whether:
$a = $b;
assigns just the value of $b, or the type as well. I'll get to that further on.
>>It might be best if everyone thought of the interpreter as essentially
>>language-neutral. Some stuff is appropriate for the interpreter
>>(basically the vtable stuff) while other things like the
>>perl-source-visible bits of overloading are more the province of the parser.
>
>Source visible bits of overloading???
Yes. The overloading interface provided to perl source. The fact that a
module has to do a "use override" and provide a PLUS method isn't really
relevant at the interpreter level. That's all parser stuff.
>I though overloading was about changing the behaviour of an operation
>without having to change the source code... I thought it was about writing
>$a + $b when what actually happens is $a->PLUS($b) or something like this...
That's essentially what is *always* going to happen. You do a:
my Foo $bar;
and the vtable for package Foo gets slammed into $bar's vtable slot. Same
thing as when you do:
tie $bar, 'Foo';
To be honest, I don't see any reason for a technical distinction between
overloading and tying in perl 6. (I can see keeping them separate at the
level presented to perl programmers for conceptual clarity reasons) There
won't even really be a difference in initial parameters, since these two:
my Foo $bar : file("login.com");
tie $bar, 'Foo', "login.com";
could potentially do the same thing at the interpreter level. (Though the
named parameters/attributes are arguably clearer)
>If you mean the parser should do the translation of ``$a + $b'' to
>something like ``$a->PLUS($b)'' (or better the call on the vtable entry of
>$a that etc. etc.), well, Ok, but if you mean the parser should do it only
>to what is overloaded, well, the parser has no way to know what is and
>what is not overloaded...
No, the parser does it regardless. The whole PLUS sub thing's a bit of a
confusing red herring. When the parser sees it (or any other "magic
function") it'll have to build up a vtable. We should, arguably,
unconditionally build up a vtable for each package and just fill it in with
default functions unless we see otherwise.
As to whether the value or value and type of a variable is copied in an
assignment, that's the province of the parser, not the interpreter. More
specifically, either or neither, if we care to alias instead) is
potentially correct. The statement:
$a = $b;
might generate the opcode stream:
destroy a;
clone a, b;
to copy both the value and type, or:
get_type temp_type_1, b;
set_value a, b, temp_type_1;
to copy the value only. Or even:
ifcustom b, 10$;
get_type temp_type_1, b;
set_value a, b, temp_type_1;
jump end;
10$:
destroy a;
clone a, b;
end:
to conditionally copy the value in the case where $b is a
non-custom-datatype, or value and type if it is. (Or do it in the case of
$a, or both, or whatever)
Heck, Larry might even mandate a weighting system where the type and value
is copied if the destination variable's type's weight is less than the
weight of the source type.
The choice of which opcode stream to spit out depends on the language
definition, which puts it in the realm of the parser, and it might be
dependent on the language source. We might, for example, copy the value if
a variable was given a type with my, and copy the value and type if it wasn't.
FWIW, I'm also th
Re: Split PMCs
At 09:55 AM 4/23/2001 +0100, Nick Ing-Simmons wrote: >Dan Sugalski <[EMAIL PROTECTED]> writes: > >At 07:39 PM 4/19/2001 +, [EMAIL PROTECTED] wrote: > >>Depends what they are. The scheme effectively makes the part "mandatory" > >>as we will have allocated space whether used or not. > > > >Well, we were talking about all PMCs having an int, float, and pointer > >part, so it's not like we'd be adding anything. Segregating them out might > >make things faster for those cases where we don't actually care about the > >data. OTOH that might be a trivially small percentage of the times the > >PMC's accessed, so... > >What is the plan for arrays these days? - if the float parts >of the N*100 entries in a perl5-oid AV were collected you might >get "packed" arrays by the back door. Unless Larry says otherwise, this: my num @foo; will have the data portion of the @foo PMC point off to a block of memory with floats jammed end-to-end in it. > >I was trying to avoid embedding the offset in the PMC itself. Since it was > >calculatable, it seemed a waste of space. > >But passing extra args around is fairly expensive when they are >seldom going to be used. Passing an extra arg through N-levels is >going to consume instructions and N * 32 bits of memory or so. Yeah, you're right. I think the better thing to do is force the alignment of the PMC arena pieces and mask off the low bits for the base address, or the high bits for the current array index. I'm going to go update the GC PDD in a bit with this. (So long variable arena sizes, but that's probably for the best all things considered) Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Tying & Overloading
At 07:11 PM 4/20/2001 -0500, Jarkko Hietaniemi wrote: >On Fri, Apr 20, 2001 at 05:02:21PM -0700, Larry Wall wrote: > > Jarkko Hietaniemi writes: > > : What is someone wants to define matrices and have both cross product > > : and dot product? > > > > At some point, there aren't enough operators, and new ones have to > >I thought we adopted Unicode for this very reason :-) $foo = $bar [SILEY_FACE] 0; instead of $foo = $bar ?? 0; huh? (We could use the bullseye character for the 'take a memory pointer instead of a reference' operation, on the assumption that if you do this you're likely to shoot yourself... :) > > I think it's a mistake to think of the vtable format as fixed. We need > > ways to install sets of methods such that they'll dispatch just as fast > > as any built-in. This probably involves setting up some kind of a > > registry for mapping of names to vtable offsets at compile time, for > > those method names we know about at compile time. > >This answers my worry about the extensibility and size of the vtables: >committing overly much to Perl 5 and trying to implement all of that >at low levels is to be avoided. With my multilevel idea I was trying >to shrink the size of the table and limit the extent of possible >change, but if we have APIs to runtime rewire (and in compile time >prewire) the vtables I'm happy. Resizing the vtable at runtime is a really dodgy thing. There are some rather huge threading implications here--changing their size (as opposed to using up a limited number of "uncommitted" spots we leave at the end) means potentially having to move all the vtables around, which means updating the vtable pointers already stuck into variables. This, one could assume, falls firmly in the "yuck" category. Adding to the opcode table, OTOH, is much less of a big deal. Or, rather, while it's still a big deal, its much easier to make threadsafe, as we can protect the critical sections with less overhead. (As there won't likely be nearly the sort of coordination required for this) Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Just in case you were wondering if alignment matters...
As a general rule of thumb, if you sort your structs into decreasing size, it usually comes out right. That is, put all your 64-bit items first, then all your 32-bit items, then 16-bit, then 8-bit. Then there are no "holes" except the one at the end, which most compilers are pretty good at keeping track of. But yes, you could still certainly misalign the whole struct if it's embedded in a stream of something with smaller alignment constraints. Larry
Re: Tying & Overloading
[EMAIL PROTECTED] writes: : Okay, then: : : @foo = @( @a + @b );# @(), $(), and %() set context. : : Easier to identify the operators, and little or no question about the : context... Well, sure, though it was already in list context from the assignment... I do expect that @() and $() will be used for interpolating list and scalar expressions into strings, and it is probably the case the $() would be a synonym for scalar(). @() would then be a synonym for the mythical list() operator. Which probably, in Perl 6, turns out to be equivalent to [...] when used in a scalar context, and a no-op in list context. That is, $() and @() would essentially be typecasts. Larry
Re: Tying & Overloading
On Mon, Apr 23, 2001 at 11:40:50AM -0700, Larry Wall wrote: > I do expect that @() and $() will be used for interpolating list and > scalar expressions into strings, and it is probably the case the $() > would be a synonym for scalar(). @() would then be a synonym for > the mythical list() operator. Which probably, in Perl 6, turns out > to be equivalent to [...] when used in a scalar context, and a no-op > in list context. That is, $() and @() would essentially be typecasts. Hm, I would expect @() in a scalar context to give the same result as @tmp = @(...); $x = @tmp; That is, yeild the number of elements in the list. What would be the benefit of it being the same as [...] ? It would be one more character. Graham.
Re: Tying & Overloading
At 10:10 AM 4/23/2001 -0700, Larry Wall wrote: >=?iso-8859-1?Q?Dav=ED=F0?= Helgason writes: >: I _really_ think dot-syntax would make perl prettier as well as make it >: more acceptable to the world of javacsharpbasic droids. Which is some >: kind of goal, no? > >Consider it a given that we'll be using . for dereferencing. (Possibly >with -> as a synonym, just for Dan. :-) Heh. Don't worry about me--if the parser isn't put together well enough for a non-parser guy like me to get use Dan; to work, then it means we're not done with the parser. ;) Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: s/./~/g
Larry Wall wrote: > Surely it's not the . itself, but the requirement that you fit everything > into that one syntactic mold. Perl's not going to do that. I'm not opposed to the change, but I want to make one point: certain characters (like dot) are special in regexes, so when you want to search for them, you have to escape them, whether in vi, or with grep, or perl, or whatever. String concats with dot are uncommon enough; but member access is quite common. -- John Porter It's a sky-blue sky The satellites are out tonight let x = x
Re: Tying & Overloading
Glenn Linderman writes: : Why not : :@foo = @( a + b ); # element by element add of @a and @b I expect that's be written: @foo := @a + @b; where the := says to treat the left side as a prototype, and a bare array in a prototype is going to put scalar context on the right side, and a + in scalar context is going to do the right thing with arrays in scalar context. It's possible that a bare = could be made to work too, but it implies copying a list, where := only implies copying a pointer. Larry
Re: Tying & Overloading
Simon Cozens writes: : On Mon, Apr 23, 2001 at 11:48:35AM -0700, Larry Wall wrote: : > :@foo = @( a + b ); # element by element add of @a and @b : > I expect that's be written: : > : > @foo := @a + @b; : : Two different assignment operators? I can understand the intent, but this kind : of difficult-to-remember special-casery is the sort of thing that *already* : gives Perl a bad press. It's not special casery. It's a fundamentally different kind of assignment, such as you find in Ruby, and the rules applied to the left side of such an assignment will be identical to the rules applied to a function prototype/signature. The := will assume it's assigning scalar objects unless it's explicitly instructed otherwise. : Think about the question "Does this vastly increase or vastly decrease the : program-breaking potential of a mistake made by a novice Perl 6 programmer?" I have thought about it a lot, actually. Why do you think this is taking so long? :-) : >From a trainer's point of view, having two operators which look very similar, : are used for the same thing in various different languages, and do *almost* : the same thing but not quite, is completely *asking* for confusion. So teach 'em :=, and outlaw = with some kind of stricture. That'll save a heap of newbie confusion with == too. The = would only be there for compatibility anyway, when you want an old-fashioned Perl assignment that attempts to dwim the list/scalar context. But it's redundant, in the sense that function signatures will have sufficient power to write the equivalent to = using := notation. And I don't care if it looks like Pascal, so don't try that argument. :-) Larry
Re: Tying & Overloading
On Mon, Apr 23, 2001 at 11:48:35AM -0700, Larry Wall wrote: > :@foo = @( a + b ); # element by element add of @a and @b > I expect that's be written: > > @foo := @a + @b; Two different assignment operators? I can understand the intent, but this kind of difficult-to-remember special-casery is the sort of thing that *already* gives Perl a bad press. Think about the question "Does this vastly increase or vastly decrease the program-breaking potential of a mistake made by a novice Perl 6 programmer?" >From a trainer's point of view, having two operators which look very similar, are used for the same thing in various different languages, and do *almost* the same thing but not quite, is completely *asking* for confusion. -- i've dreamed in Perl many time, last night i dreamed in Make, and that just sucks.
Re: Tying & Overloading
On Mon, Apr 23, 2001 at 09:05:22PM +0200, Bart Lateur wrote: > Or, in analogy to "cmp", "gt" etc: > $a = $b plus $c; > or > $a = $b cat $c; while left_angle_right_angle: if dollar_underscore[0] =eq= "#": continue_next; } print dollar_underscore; } Oh, no, that's a different language. -- "(Because if life's not shit, then you're not doing it right.)" - Rebecca Luckraft
Re: Tying & Overloading
Bart Lateur writes: : Or, in analogy to "cmp", "gt" etc: : : $a = $b plus $c; : or : $a = $b cat $c; It would probably have been C if it had come to that. Larry
Re: Tying & Overloading
Lightning flashed, thunder crashed and Larry Wall <[EMAIL PROTECTED]> whispered: | I'm thinking concat will be ~. Furthermore, I'm thinking unary ~ will | be stringify, and unary ^ will be bit complement, on the theory that | bit complement is like xoring with 0x. And unary + will be a | numify, not a no-op. How difficult would it be to co-opt , for concat? Currently it doesn't do much of value in a strictly scalar context. It is also already fairly synonymous in a string context: print "a", $x, "$b"; Hmmm... this could be a real problem in list context though. I suppose it is conceivable that someone might want to do something like: @a = ( $a . $b , $c ); Maybe not a good idea. But maybe something to think about. -spp
Re: Tying & Overloading
At 04:46 PM 4/23/2001 -0400, John Porter wrote: >Larry Wall wrote: > > Except we're not having highlander variables. $foo and @foo remain > > distinct entities. > >I know. Sad. > >(Of course, what I meant by highlander was no prefix chars. >Highlanderishness is just a consequence of that.) It wouldn't be all that tough to change this if you were so inclined--it'd certainly be a simpler parser modification than some others that have been proposed. (The requirement to predeclare all variables would come into play) You'd lose easy interpolation of variables into strings, though) Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Tying & Overloading
Okay, then: @foo = @( @a + @b );# @(), $(), and %() set context. Easier to identify the operators, and little or no question about the context... --- Larry Wall <[EMAIL PROTECTED]> wrote: > Stephen P. Potter writes: > : Maybe this is a crazy (or stupid) idea, but why couldn't we use the > $, @, > : and % characters? > : > : @foo = @a @+ @b;# element by element add > > Because it's difficult to tell the operators from the terms visually. > > Larry = Austin Hastings Global Services Consultant Continuus Software Corporation [EMAIL PROTECTED] __ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/
Re: Tying & Overloading
Okay, then: @foo = @( @a + @b );# @(), $(), and %() set context. Easier to identify the operators, and little or no question about the context... --- Larry Wall <[EMAIL PROTECTED]> wrote: > Stephen P. Potter writes: > : Maybe this is a crazy (or stupid) idea, but why couldn't we use the > $, @, > : and % characters? > : > : @foo = @a @+ @b;# element by element add > > Because it's difficult to tell the operators from the terms visually. > > Larry = Austin Hastings Global Services Consultant Continuus Software Corporation [EMAIL PROTECTED] __ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/
Re: Tying & Overloading
=?iso-8859-1?Q?Dav=ED=F0?= Helgason writes:
: I _really_ think dot-syntax would make perl prettier as well as make it
: more acceptable to the world of javacsharpbasic droids. Which is some
: kind of goal, no?
Consider it a given that we'll be using . for dereferencing. (Possibly
with -> as a synonym, just for Dan. :-)
: I suspect that we will never agree on anything here though.
I suspect we will. :-)
: Which of qw[~ ++ +~ + &] do we dislike the least? Using + would be
: nice, but introduce no end of problems with number/sting behaviour. '&'
: is too much like a certain unpopular language. And there was no end to
: the quabbling :(
++ is out becuase you can't have the same operator as both postfix and infix.
& is out because it'll stay bit-fiddly.
+ is out because it will add numbers.
+~ is out because I'd really like to have a single character for something
as common as concatenation.
(And juxtaposition is out because we're not going to destroy indirect
object syntax
I'm thinking concat will be ~. Furthermore, I'm thinking unary ~ will
be stringify, and unary ^ will be bit complement, on the theory that
bit complement is like xoring with 0x. And unary + will be a
numify, not a no-op.
: If we can make the concatenation into something else, we free the dot to
: do "string".length() and innumerable other niceties.
Indeed. Though of course that's not related to the syntax of . vs ->, which
could be taught to do the same thing.
: ps. What do you think about the following sentence: "we should steal
: more from ruby"? a) disgusting, b) uninteresting, c) clever, d)
: wonderful.
Well, whatever you think, we would have to steal it from the 1/3 of
Ruby that wasn't stolen from Perl. :-)
: pps. if ($_ === qw(b c d)) {
: "=== 'is in' operator",
: "dot operator remapped to mean",
: "objectspace array/iterator as in ruby, giving access to all existing
:data (but of course more complete than rubys rather flaky
: implementation",
: }
If we don't install such features directly, we at least want to make it
easy to install them. For instance, we'll definitely have easy ways
of writing code blocks that can function as iterators. And it would
be relatively easy to install a universal .each method that calls such
a code block, so you could, if you like, do a Rubyesque thing like
@dogs.each { $^.bark };
Depending on how HOF rules end up interacting with method prototypes,
we might even get:
@dogs.each $^.bark;
But it's probably clearer with the curlies. On the other hand, it's
possible that if @dogs (as an array) doesn't have a bark method, but
each Dog scalar does, then
@dogs.bark;
might do the right thing. I dunno about that yet. We can't just
assume the method is distributed over the array, or we won't be able to
get to methods resembling length(@dogs).
Larry
s/./~/g
I'm starting to be a bit worried with what I'm reading... 1) Use $obj.method instead of $obj->method : The big question is: why fix what is not broken? Why introduce Javaisms and VBisms to our pretty C/C++-oid Perl? Why brake compatibility with Perl 5 code (and Perl 5 programmers) for a zero net gain? 2) Use $a~$b instead of $a.$b : The same argument, only stronger now. This one still poses another problem: for $a = $a ~ $b, the syntax would be $a ~= $b. Now read these two quickly and tell me what's the difference $a~=$b; $a=~$b; It's not only hard to teach the =~ operator, imagine teaching that there are two of them... Imagine if a programmer writes the wrong one, how long you'll have to wade through that code until find the bug! 3) Introduce := and deprecate = : Ok, nobody told = would be deprecated, but I've actually read that := would do everything = does, so that = could be forgotten. Now, why not extend =, instead of adding this Pascal-ism to Perl? I agree that Perl should get ideas from the maximum of languages, including, of course, Java, VB, Pascal. I just don't see why introduce syntatical elements of those languages, since the ideas could be done with Plain Old Perl Syntax, that one inspired in the language for real programmers, C, as it has always been through time. What I mean is, when I first say Ruby, I thought: That looks like a cool language, it has most features of Perl, and supports some neat things Perl doesn't... But when I saw it's Java-like syntax, I thought: Forget about it! Perl syntax rules! The bottom line is: please don't change the syntax, unless it's unavoidable. It will cost many time of reading code until finding bugs because of operators that used to work and don't work anymore... - Branden
Strings vs Numbers (Re: Tying & Overloading)
Larry Wall wrote:
>
> The . is just syntax. Do you mean something semantic by ".-based"?
No, but I think "just syntax" is a little misleading. I do agree that we
"well, Perl 5 did it this way" is not a sufficient design decision at
this point. However, if you changed Perl's syntax too radically you
would almost certainly lose programmers. You drop the $'s, change -> to
., do this/that/etc and pretty soon it looks like Java, which people
like myself really dislike. One of the reasons I program in Perl as my
primary language is *because of* the syntax.
> I don't care about commutative either, but what you are proposing is to
> throw away a particularly useful feature of Perl, which is its
> autoconversion between numbers and strings. That we're not going
> to lose. This implies that string operators must stay distinct
> from numeric operators.
I don't think that this is necessarily true (more below).
> Doesn't ~ look like a piece of string to you? :-)
>
> I think it kind of looks like a stitch.
It looks like a bitwise op to me, personally. I've never seen it used
anywhere as a string concat. Again, that's not to say it can't be in
Perl 6, but it would be a real oddity.
> Then how do you concatenate a number?
Here's something I was thinking about at lunch:
$concated_number = "$number" + "$other_number";
$numerical_add = $number + $other_number;
Why not require "" in the case when you want to forcible concat a number
as a string? Most people write:
$string = "$number$other_number";
Already anyways. You would only have to disambiguate if one of the args
was not a string. So here would be some equivalents:
Perl 5Perl 6
-
"This" . "that" "This" + "that"
$this . "that"$this + "that"
$maybe_a_num . $that "$maybe_a_num" + $that
$i++ $i++
$i + 1$i + 1
I know this isn't the first time something like this has been suggested.
And the problem isn't necessarily with the above, but with stuff like
this:
die "Nope" unless ($i == 0);# eq 0 ??
But I'd argue all you have to do is use "":
die "Nope" unless ($i == "0"); # str eq
die "Nope" unless ("$i" == 0); # same
die "Nope" unless ($i == 0); # num ==
Unlike Java and other languages, Perl has an advantage with $'s: You can
use quotes to disambiguate, since "$var" will still expand $var (unlike
"var"). This opens up a whole bunch of interesting alternatives.
> Me either. But then you propose to break one of the most endearing
> features of Perl 5.
No, not by any means. Sorry if I wasn't clear.
> There are many people who would prefer . to ->, if for no other reason
> than it's cleaner looking and is one less character to type. The fact
> that it's become the industry standard for method call syntax is also
> a point in its favor.
I do agree with that, but by this logic then we should look seriously
into using "+" for string concat. Otherwise, all we're doing is trading
one oddity for another. Sure, "." now means object deref, but why (says
the JavaDrone) do I use "~" for string concat? That's weird.
Plus, you're now requiring all the Perl hackers to relearn two major
tenets of Perl: "->" and ".".
Again, if this is going to be done, IMO it needs to be done wholesale
otherwise it will be detrimental to language.
> : I know we're just brainstorming still,
>
> Well, maybe we are, at that. But I feel as though I've been in design
> mode for a while now. That is, any brainstorming I'm doing at this
> point is merely to feel my way into the ramifications of making some of
> the hard-nosed decisions that have to be made.
All I meant was that just because an email comes out that says "I think
we should rename @foo to ^bar" doesn't mean it's set in stone...yet.
> I think Perl is still suboptimal as C glue, and we can improve it. If
> it becomes better VM glue at the same time, all the better. But I fail
> to see how . notation can be much of a political issue, unless people
> choose to turn it into one.
No, I don't think it's a political issue at all. But syntax is a big
part of a language. You could argue that this code:
using System;
void public static Main () {
Console.Print("Hello, World!\n");
}
Is "just syntax" too, but that doesn't mean it's easy or fun. Perl is
both, and syntax is a huge chunk of that.
> : The latter space is already populated w/ Java and C#,
> : and Sun and MS have a little bit of marketing cash.
>
> And because they have better marketing we should therefore concede in
> the technical sphere? I don't follow.
No, but if Perl looks 95% like Java or C#, my prediction would be it
will lose. If you throw out everything from the tens of previous years
of Perl, then you cause a whole bunch of JAPH's to relearn lots. And
then, these people might be prompted to say "Hey, if I have to relearn
all this, let me check
Re: Tying & Overloading
John Porter writes: : Larry Wall wrote: : > I do expect that @() and $() will be used for interpolating list and : > scalar expressions into strings, and it is probably the case the $() : > would be a synonym for scalar(). @() would then be a synonym for : > the mythical list() operator. Which probably, in Perl 6, turns out : > to be equivalent to [...] when used in a scalar context, and a no-op : > in list context. That is, $() and @() would essentially be typecasts. : : Yay! Then we're nine tenths of the way to highlander variables! Except we're not having highlander variables. $foo and @foo remain distinct entities. Larry
Re: Strings vs Numbers (Re: Tying & Overloading)
On 4/23/01 3:59 PM, Nathan Wiger wrote: >> Then how do you concatenate a number? > > Here's something I was thinking about at lunch: > > $concated_number = "$number" + "$other_number"; > $numerical_add = $number + $other_number; > > Why not require "" in the case when you want to forcible concat a number > as a string? Most people write: > > $string = "$number$other_number"; > > Already anyways. You would only have to disambiguate if one of the args > was not a string. So here would be some equivalents: > [snip] Using + for concat: no! My vote is to use . and require space before and after. $this.$is.$ugly.$anyway ;) -John
Re: Tying & Overloading
[EMAIL PROTECTED] writes: : On 4/23/01 3:25 PM, Larry Wall wrote: : > : >From a trainer's point of view, having two operators which look very : > similar, : are used for the same thing in various different languages, and do : > *almost* : the same thing but not quite, is completely *asking* for confusion. : > : > So teach 'em :=, and outlaw = with some kind of stricture. That'll : > save a heap of newbie confusion with == too. The = would only be there : > for compatibility anyway, when you want an old-fashioned Perl : > assignment that attempts to dwim the list/scalar context. : : Then why not use = to do what you want := to do, and make := do what the : Perl 5 = does? Poor, confused Perl 5 programmers, I know. But if the ":= : functionality" is the common case for Perl 6, why make everyone type := all : over the place when they could be typing = ? Don't think I'm not tempted. But I'm not sure if people will take to @foo = @bar; no longer implying list context by default. : > And I don't care if it looks like Pascal, so don't try that argument. :-) : : I'm just trying to save a (chorded!) keystroke in every assignment... :) Now that's a good argument. :-) Larry
Re: Strings vs Numbers (Re: Tying & Overloading)
At 12:59 PM 23/04/2001 -0700, Nathan Wiger wrote:
>Larry Wall wrote:
> > The . is just syntax. Do you mean something semantic by ".-based"?
>
>No, but I think "just syntax" is a little misleading. I do agree that we
>"well, Perl 5 did it this way" is not a sufficient design decision at
>this point. However, if you changed Perl's syntax too radically you
>would almost certainly lose programmers. You drop the $'s, change -> to
>., do this/that/etc and pretty soon it looks like Java, which people
>like myself really dislike. One of the reasons I program in Perl as my
>primary language is *because of* the syntax.
Totally agreed. I also program in Perl as my primary language because of
the syntax.
> > Doesn't ~ look like a piece of string to you? :-)
>It looks like a bitwise op to me, personally.
I wouldn't fix what is working well.
> > Then how do you concatenate a number?
>
>Here's something I was thinking about at lunch:
>
>$concated_number = "$number" + "$other_number";
>$numerical_add = $number + $other_number;
Sorry, but this is Java. No thanks!!! (Tell me what "This is: " + $x + 1;
IMO, if $x is 1, this could be both "This is: 2" or "This is: 11"; there's
no way to DWIM when I'm not sure of WIM).
>Perl 5Perl 6
>-
>"This" . "that" "This" + "that"
>$this . "that"$this + "that"
>$maybe_a_num . $that "$maybe_a_num" + $that
>$i++ $i++
>$i + 1$i + 1
The big need of ".", or concat, is when one of the arguments is a sub or
method call. How would it be done?
>die "Nope" unless ($i == "0"); # str eq
>die "Nope" unless ("$i" == 0); # same
>die "Nope" unless ($i == 0); # num ==
This is tcl or bash? No thanks!!! Enough of having $var and "$var"
expanding different (try it in bash when there is an asterisk in the value
of the variable... sometimes, backticks can get really nasty!)
> > There are many people who would prefer . to ->, if for no other reason
> > than it's cleaner looking and is one less character to type.
There are many people who prefer -> to .
> > The fact
> > that it's become the industry standard for method call syntax is also
> > a point in its favor.
C and C++ don't use "." as a standard for method call syntax. Also, I think
Perl shouldn't be designed based on "industry standard" (Java is and Java
sucks).
>Plus, you're now requiring all the Perl hackers to relearn two major
>tenets of Perl: "->" and ".".
Agreed. Perl hackers should be the primary target audience of Perl 6.
>No, but if Perl looks 95% like Java or C#, my prediction would be it
>will lose. If you throw out everything from the tens of previous years
>of Perl, then you cause a whole bunch of JAPH's to relearn lots. And
>then, these people might be prompted to say "Hey, if I have to relearn
>all this, let me check out some alternatives." At which point you lose
>people to Java or C# or other similar languages.
Well, that's silly. One doesn't look for alternatives because they're
similar, but rather because they're completely different. The argument that
Perl syntax should not change because it would look like other languages
and drive Perl programmers to other languages is silly. Perl syntax should
not change because it is pretty good the way it is!
>This is something to watch out for, not something that should decide
>Perl 6's design for paranoia's sake. I know that I am not the only one
>that loves Perl first and foremost for its syntax.
I am another one that loves Perl first and foremost for its syntax.
>Change too much and
>you're bound to drive some people away. Especially if these changes are
>inconsistent with other languages.
IMO, consistence with other languages doesn't matter.
>My conclusion: I say we do ". and +" or neither.
My conclusion: Let's not fix what is not broken.
- Branden
Re: Tying & Overloading
Larry Wall wrote: > I do expect that @() and $() will be used for interpolating list and > scalar expressions into strings, and it is probably the case the $() > would be a synonym for scalar(). @() would then be a synonym for > the mythical list() operator. Which probably, in Perl 6, turns out > to be equivalent to [...] when used in a scalar context, and a no-op > in list context. That is, $() and @() would essentially be typecasts. Yay! Then we're nine tenths of the way to highlander variables! -- John Porter
Re: Strings vs Numbers (Re: Tying & Overloading)
Nathan Wiger wrote: > I *really* don't want this to turn into a religious argument, Neither do I. > coming from a sh/C background. I understand. I think I was able to learn Perl as quickly as I did because of certain syntactic similarities. But it's not why I program in Perl now, and it's certainly now why I *like* to program in Perl now. > ...closer to other languages with -> vs ., then adding "~" works against > that goal. This is made worse by the fact that *everyone* - Perl hackers > and Java programmers alike - will perceive this as different from all > other languages. It runs directly counter to the original goal: Making > Perl syntax more consistent with other languages. The more I read about this issue, the more I think the string concat operator ought to /[a-z]+/, like the other string ops. -- John Porter
Re: s/./~/g
Branden writes: : I'm starting to be a bit worried with what I'm reading... : : 1) Use $obj.method instead of $obj->method : : : The big question is: why fix what is not broken? Why introduce Javaisms and : VBisms to our pretty C/C++-oid Perl? Why brake compatibility with Perl 5 : code (and Perl 5 programmers) for a zero net gain? It's not zero net gain, and I'm going to ignore the next person who says it. : 2) Use $a~$b instead of $a.$b : : : The same argument, only stronger now. This one still poses another problem: : for $a = $a ~ $b, the syntax would be $a ~= $b. Now read these two quickly : and tell me what's the difference : : $a~=$b; : $a=~$b; : : It's not only hard to teach the =~ operator, imagine teaching that there : are two of them... Imagine if a programmer writes the wrong one, how long : you'll have to wade through that code until find the bug! We have lots of operators you wouldn't want to reverse by accident. : 3) Introduce := and deprecate = : : : Ok, nobody told = would be deprecated, but I've actually read that := would : do everything = does, so that = could be forgotten. Now, why not extend =, : instead of adding this Pascal-ism to Perl? That's still a possiblility. : I agree that Perl should get ideas from the maximum of languages, : including, of course, Java, VB, Pascal. I just don't see why introduce : syntatical elements of those languages, since the ideas could be done with : Plain Old Perl Syntax, that one inspired in the language for real : programmers, C, as it has always been through time. : : What I mean is, when I first say Ruby, I thought: That looks like a cool : language, it has most features of Perl, and supports some neat things Perl : doesn't... But when I saw it's Java-like syntax, I thought: Forget about : it! Perl syntax rules! What is it about . that seems to inspire allergic reactions in people? Surely it's not the . itself, but the requirement that you fit everything into that one syntactic mold. Perl's not going to do that. : The bottom line is: please don't change the syntax, unless it's : unavoidable. It will cost many time of reading code until finding bugs : because of operators that used to work and don't work anymore... That is a consideration, but there's no such thing as absolutes here. All change is avoidable at some price. I don't intend to pay that price. Larry
Re: Strings vs Numbers (Re: Tying & Overloading)
At 04:14 PM 23/04/2001 -0400, John Siracusa wrote: >On 4/23/01 3:59 PM, Nathan Wiger wrote: > >> Then how do you concatenate a number? > >Using + for concat: no! > >My vote is to use . and require space before and after. >$this.$is.$ugly.$anyway ;) People who use one-liners know the value of $ugly.$and.$nasty.$things. Anyway, any behaviour that would break my script if I add/remove whitespace of is nasty. - Branden "Let's not fix what isn't broken."
Re: s/./~/g
On Mon, Apr 23, 2001 at 01:16:57PM -0700, Larry Wall wrote: > Branden writes: > : I'm starting to be a bit worried with what I'm reading... > : > : 1) Use $obj.method instead of $obj->method : > : > : The big question is: why fix what is not broken? Why introduce Javaisms and > : VBisms to our pretty C/C++-oid Perl? Why brake compatibility with Perl 5 > : code (and Perl 5 programmers) for a zero net gain? > > It's not zero net gain, and I'm going to ignore the next person who says it. I agree it is not a zero net gain. But perhaps it needs to be spelled out for those who don't see the gain. Graham.
Re: Strings vs Numbers (Re: Tying & Overloading)
On Mon, 23 Apr 2001 16:14:50 -0400, John Siracusa wrote:
>Using + for concat: no!
>
>My vote is to use . and require space before and after.
>$this.$is.$ugly.$anyway ;)
My vote is to ditch the concat operator altogether. Hey, we have
interpolation!
"$this$is$just$as$ugly$but$it$works"
Which reminds me... one problem I have with it is that it's too hard to
separate a variable name from the rest of the string, if it also
consists of word characters:
my $bar = "BAR";
print "foo${bar}baz"; -> fooBARbaz
Since $bar is a lexical variable, this syntax doesn't make much sense
anyway: it reeks of symbolic references and those don't work for
lexicals.
I think I'd like something incorporating a backslash would be nicer:
print "foo$bar\Ebaz";
It works, but it may have unwanted side effects -- in case the "\E"
actually serves a purpose.
But, you may completely forget about it. I just had to say this one day.
--
Bart.
Re: Strings vs Numbers (Re: Tying & Overloading)
At 04:40 PM 23/04/2001 -0400, John Porter wrote: >Nathan Wiger wrote: > > if you changed Perl's syntax too radically you > > would almost certainly lose programmers. > >I disagree. Changing the semantics of Perl to make it more >powerful is something every perl programmer would be happy >about. Consequent changes to the syntax is something we >would live with. I don't see the semantic change to make it more powerful that is behind changing -> to . and . to ~. > > One of the reasons I program in Perl as my > > primary language is *because of* the syntax. > >With all due respect, I don't believe that's why you, >or anyone else, likes to program in Perl. >It's a powerful, high-level language. I don't care >so much about the details of the syntax, as long as >it supports the semantics (and has brackets that let >me bounce on the % key in vi, of course). IMHO, Ruby or Python is almost as powerful as Perl, but I never learnt them because of their messy syntax. > > syntax is a big part of a language. > >Not as big as you seem to think. >We could y/$@%/@%$/ and all we'd really lose is a little >mnemonic value. Probably Perl wouldn't be as successful as it is in spite of y/$@%/@%$/. >The only thing we really want from the syntax is that it be >brief. And mildly mnemonic. Apart from that, there are no >rules. Considering this is to be the successor of Perl 5, not steep changes would be appreciated. >Besides that, I think most Perl programmers would be willing >to trade a tiny bit of typing ease for a big gain in power. >I know I would. If Perl became so much more powerful, that >you could do in one line of Perl6 what it takes 10 lines of >Perl5, who cares if you have to write $a ~ $b instead of >$a . $b ? Or $a.b instead of $a->b ? I still haven't seen the power gain in s/->/./ and s/./~/ (not in this order :-). There's a typing gain, and maybe a clarity gain for calling methods (which isn't true for concatenating strings). > > If you throw out everything from the tens of previous years > > of Perl, > >Sorry, changing -> to . or . to ~ is not throwing out ten years >of Perl. But what is it winning, in semantic terms? > > then you cause a whole bunch of JAPH's to relearn lots. And > > then, these people might be prompted to say "Hey, if I have to relearn > > all this, let me check out some alternatives." > >Well they certainly won't run to Java. >They might look at Pythong -- but there they'll find syntactic >peculiarities that make Perl6 look like Ada. s/Perl6/Perl5/;s/Ada/Befunge/;$_.=' ;-)'; - Branden
Re: s/./~/g
On 4/23/01 4:16 PM, Larry Wall wrote: > What is it about . that seems to inspire allergic reactions in people? > Surely it's not the . itself, but the requirement that you fit everything > into that one syntactic mold. Perl's not going to do that. I don't mind it, but I always imagined: $obj->method(); $obj.attribute; or something vaguely C-ish like that. And I think most Perl folks like the -> for class/object methods. It's a cute little arrow :) You'll have to make it very clear why . is a better fit for Perl 6 than -> Otherwise people will probably mourn the missing Mr. Pointy ;) -John
Re: Strings vs Numbers (Re: Tying & Overloading)
Nathan Wiger wrote: > if you changed Perl's syntax too radically you > would almost certainly lose programmers. I disagree. Changing the semantics of Perl to make it more powerful is something every perl programmer would be happy about. Consequent changes to the syntax is something we would live with. > pretty soon it looks like Java, which people > like myself really dislike. No, there are far more important reasons for not liking to program in java. > One of the reasons I program in Perl as my > primary language is *because of* the syntax. With all due respect, I don't believe that's why you, or anyone else, likes to program in Perl. It's a powerful, high-level language. I don't care so much about the details of the syntax, as long as it supports the semantics (and has brackets that let me bounce on the % key in vi, of course). > I've never seen [~] used anywhere as a string concat. Based on what you said above, I would think you shouldn't care what it was used for in other languages. > Again, that's not to say it can't be in > Perl 6, but it would be a real oddity. Guess we can't have Perl containing any syntax oddities, eh? Hypothesis: Eliminating syntactic oddities from Perl would result in a language that "looks like" Java. > syntax is a big part of a language. Not as big as you seem to think. We could y/$@%/@%$/ and all we'd really lose is a little mnemonic value. > You could argue that . . . > Is "just syntax" too, but that doesn't mean it's easy or fun. I think such an argument would be wasting everyone's time. The only thing we really want from the syntax is that it be brief. And mildly mnemonic. Apart from that, there are no rules. Besides that, I think most Perl programmers would be willing to trade a tiny bit of typing ease for a big gain in power. I know I would. If Perl became so much more powerful, that you could do in one line of Perl6 what it takes 10 lines of Perl5, who cares if you have to write $a ~ $b instead of $a . $b ? Or $a.b instead of $a->b ? > No, but if Perl looks 95% like Java or C#, my prediction would be it > will lose. No. When you say "what it looks like", you're only talking about syntactic features. As long as Perl can do in one "intuitive" statement what takes 10 lines of Java or 100 lines of C, it will win. > If you throw out everything from the tens of previous years > of Perl, Sorry, changing -> to . or . to ~ is not throwing out ten years of Perl. > then you cause a whole bunch of JAPH's to relearn lots. And > then, these people might be prompted to say "Hey, if I have to relearn > all this, let me check out some alternatives." Well they certainly won't run to Java. They might look at Pythong -- but there they'll find syntactic peculiarities that make Perl6 look like Ada. -- John Porter It's a sky-blue sky The satellites are out tonight let x = x
Re: Tying & Overloading
Larry Wall wrote: > Except we're not having highlander variables. $foo and @foo remain > distinct entities. I know. Sad. (Of course, what I meant by highlander was no prefix chars. Highlanderishness is just a consequence of that.) -- John Porter
Re: Tying & Overloading
On 4/23/01 3:25 PM, Larry Wall wrote: > : >From a trainer's point of view, having two operators which look very > similar, : are used for the same thing in various different languages, and do > *almost* : the same thing but not quite, is completely *asking* for confusion. > > So teach 'em :=, and outlaw = with some kind of stricture. That'll > save a heap of newbie confusion with == too. The = would only be there > for compatibility anyway, when you want an old-fashioned Perl > assignment that attempts to dwim the list/scalar context. Then why not use = to do what you want := to do, and make := do what the Perl 5 = does? Poor, confused Perl 5 programmers, I know. But if the ":= functionality" is the common case for Perl 6, why make everyone type := all over the place when they could be typing = ? > And I don't care if it looks like Pascal, so don't try that argument. :-) I'm just trying to save a (chorded!) keystroke in every assignment... :) -John
Re: Tying & Overloading
Lightning flashed, thunder crashed and Graham Barr <[EMAIL PROTECTED]> whispered: | > What's wrong with something like: | > | >$foo = $a :+ $b; | | I was thinking along those lines too. Maybe this is a crazy (or stupid) idea, but why couldn't we use the $, @, and % characters? @foo = @a @+ @b;# element by element add -spp
Re: Tying & Overloading
At 02:52 PM 4/23/2001 +0200, Davíð Helgason wrote: >"H.Merijn Brand" wrote: > > > > > > $a = $b ~ $c; # Mmm! > > > > > > > > I like that last one a lot, because it doesn't disturb anything. > > > > You'd have to alter ~'s precedence so that binary ~ is higher > > > > than named unary operators. (It's print($a~$b), not print $a (~b).) > > > > > > I am not sure I do like the use of ~ here. It does not screan concatenate > > > to me (but then again neither did . when I started perl) > > > > > > I am thinking that maybe it should be a 2 character operator with at > > > least one of then being + as + is common in many other languages > > > for doing concatenation. > >Which of qw[~ ++ +~ + &] do we dislike the least? Using + would be >nice, but introduce no end of problems with number/sting behaviour. '&' >is too much like a certain unpopular language. And there was no end to >the quabbling :( What's wrong with something like: $foo = $a :+ $b; Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Tying & Overloading
Larry Wall wrote: > > : I _really_ think dot-syntax would make perl prettier as well as make it > : more acceptable to the world of javacsharpbasic droids. Which is some > : kind of goal, no? > > Consider it a given that we'll be using . for dereferencing. (Possibly > with -> as a synonym, just for Dan. :-) > + is out because it will add numbers. FWIW, if we're going to go "all the way" and make Perl's objects .-based (which I personally dread, but oh well), then we should adopt the "+" for string concat as well. Yes, I know that string concat isn't commutative and all the other stuff, but who cares? Sometimes taking what other languages do just because it's widely used is worthwhile. I personally don't know of any other language that uses "~" for string concat. Does anyone else? Besides, if everything's an object and you have a vtable/whatever PLUS method, then why shouldn't: print "The next loop will be " + $i + 1 + "\n"; DWIM? As a segue for a second, we should keep in mind which types of people we're trying to satisfy. I personally don't care at all if Perl 6 is more popular with Java and C# people than Perl 5. But I definitely don't want it to be less popular with Perl folks (like me). With the proposed changes in this thread so far, you've got: P5 P6 --- --- -> . . ~ For no net gain. I know we're just brainstorming still, but -> is not an oddity to Perl. There are other languages (like C) that use this. And personally I think Perl is far more effective as a C-sh/cgi glue than a Java-.Net glue. The latter space is already populated w/ Java and C#, and Sun and MS have a little bit of marketing cash. Just my own personal feelings. I don't want Perl 6 to be a complete disregard for Perl 5, but rather an improvement over it (RFC 28, you know...). -Nate
Re: Tying & Overloading
At 11:02 AM 4/23/2001 -0400, John Porter wrote: >Simon Cozens wrote: > > John Porter wrote: > > > $a = $b $c; > > > > Actually, I'd rather like that to be equivalent to > > $a = $c->$b; > >Oops, sorry, I forgot the smiley. > >Oh, but thinking seriously about it: >do we really want to keep the "indirect object" syntax? >It is said to be a major source of ambiguity in perl. I'd like to. I find it more visually appealing and easier to read than either the arrow or (gack) the dot. Though I'll freely grant I've a thing against the object.method notation at the moment--I've had to wade through a bunch of code that does it and I just can't stand it. (For no good reason, as it's not like the code I'm reading is particularly bad) Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Tying & Overloading
Larry Wall writes: > wanted, you still get the length. If you're worried about the delayed > operation, you can force numeric context with $x = +@tmp;, just as you > can force string context with a unary ~. How often are you likely to do this? Speaking as a reader of code, I've always hated unary + in that crocky "this could be a block or an expression" sense. I'd prefer a word operator: $x = numeric @tmp; Of course, beginners might think it was like defined(): if (numeric $x) # "is $x a number" We know the return value of that meaning of numeric() would always be true. Everything in Perl can be a number if you want it to be. :-) Then they'd want: $x = string @tmp; and we'd have to tell them that "string" is spelled "". Then we could go off on Abbott and Costello crosstalk: 'there isn't one?' 'there is, and it's spelled ""' 'you did it again!' 'did what again?' 'left the operator out' 'it is right there!' etc. I feel like I'm in one of those sitcom situations where nervous over-thoughtful boy and girl meet, and one says something like "you shouldn't sit beside me". The other asks why, to be told "we'd hold hands, and there'd be kissing, more holding, more kissing, and we'd date for a while, get married as we start college, I'd get pregnant, drop out to take care of the baby, you'd have to work three jobs to feed us all, your studies would be left behind, I'd grow increasingly frustrated with the endless pregnancies, turn to drink, spend the glorious years of our lives in a drunken haze, beat our children, beat you, go to jail, come out divorced and with an abused kidney that would require hospitalization for my slow death. Ken, I don't like hospital food!" Nat
Re: Tying & Overloading
On Mon, Apr 23, 2001 at 01:23:43PM -0600, Nathan Torkington wrote: > Larry Wall writes: > > wanted, you still get the length. If you're worried about the delayed > > operation, you can force numeric context with $x = +@tmp;, just as you > > can force string context with a unary ~. > > How often are you likely to do this? Speaking as a reader of code, > I've always hated unary + in that crocky "this could be a block or an > expression" sense. I'd prefer a word operator: > > $x = numeric @tmp; Ig you are going to put a word there, then why not $x = length @tmp or $x = @tmp.length Graham.
Re: Strings vs Numbers (Re: Tying & Overloading)
John Porter wrote: > > > One of the reasons I program in Perl as my > > primary language is *because of* the syntax. > > With all due respect, I don't believe that's why you, > or anyone else, likes to program in Perl. I *really* don't want this to turn into a religious argument, which it's fast becoming. I will tell you that my statement above is completely truthful, coming from a sh/C background. If you don't believe me, well, I don't know what to say. Here is all I'm saying: The argument for changing -> to . is because it gains us compatibility with other languages that are HLL, like Java, Python, C#, C++, etc, etc. THIS IS GOOD. I agree. However, if we are to do this, then I say we "go the whole 9 nine yards" and figure out how to make + do correct string concat. That is, make sure we maintain the auto-conversion from strings <-> numbers. Here, we're be one-upping Java and other clones. We already (via overloading) have "$var" != $var, so let's look into using this. Now, please don't quasi-flame me and claim that I'm saying we can't have "~" mean string concat because it's odd. But, if we're trying to get closer to other languages with -> vs ., then adding "~" works against that goal. This is made worse by the fact that *everyone* - Perl hackers and Java programmers alike - will perceive this as different from all other languages. It runs directly counter to the original goal: Making Perl syntax more consistent with other languages. Anyways, I'm really not on either side of the fence - please don't misunderstand me. All I'm saying is that we should figure out the goal and try to achieve that. Think of how cool it could be if we could *extend* the Java . and + operators with better DWIMmery! -Nate
Re: Strings vs Numbers (Re: Tying & Overloading)
Branden wrote: > > Changing the semantics of Perl to make it more > > powerful is something every perl programmer would be happy > > about. Consequent changes to the syntax is something we > > would live with. > > I don't see the semantic change to make it more powerful that is behind > changing -> to . and . to ~. > . . . I still haven't seen the power gain in s/->/./ and s/./~/ You miss my point. I'm trying to show the difference between what's really important in perl -- its spectacularly powerful semantics -- and what's not important, its syntax. > IMHO, Ruby or Python is almost as powerful as Perl, but I never > learnt them because of their messy syntax. I don't know them well enough to say, but I'm pretty confident that they both lack useful, interesting powerful semantic features of Perl. Again, the syntax only plays a supporting role. And I'm certainly not arguing in favor of STUPID syntax, like Pythong's whitespace madness. -- John Porter It's a sky-blue sky The satellites are out tonight let x = x
Thinking about scalars
I have lurked for several months now, and find that I can hold my tongue no longer. The 'discussion' of overloading '+', to include concatenation, suffers from a general degeneration into implementation details, where linguistic sentiment should reign. The contention that '+' should be overloaded is based in machine details, expressed in other languages through 'types'. In this model of the world, a 'string' is fundamentally different from a 'number', and as such each defines a specific context in which the operator exists: (string) + (string) or (number) + (number), or some horrid abberation thereof, which aught not to be. The traditional perl vision, however, holds these divergent things to be both one and the same. But in this, a scalar is really neither a number nor a string. From the point of view of the C++ programmer, there is only a single context which applies, the scalar context: (scalar) + (scalar). Perl's clever solution to how to interpret what a scalar 'means' is to define vocabulary which provides the context. The manner in which the symbol 123 is interpreted depends on the operator, and not the other way round as is the case in C, C++, Java, Ruby. Perl is beautiful because you are manipulating a symbol and not just a series of bits. I'm sorry, and I apologize for this rant, but I feel that the arguments on both side of what to do with '.' and '+' have bogged themselves down in a discussion based on how one represents a symbol on the machine's level, forgetting about the human one. The correct choice is a matter of 'human' intuition and not 'computer programmer' intuition, we have bent our minds too far to accomodate the machines. (BTW: I read Chip Salzenberg's perl code all day at work, so go easy on me :) -- david j. goehrigbit twiddlerwww.valinux.com "There was nothing creative, charming, admirable or innovative in Pokémon except that it parted small children from their money with brutal efficiency. It inexplicably featured the dramatic story of cockfighting monsters who lived in your pants..." - John Tynes
Re: s/./~/g
John Siracusa <[EMAIL PROTECTED]> writes: > On 4/23/01 4:16 PM, Larry Wall wrote: > > What is it about . that seems to inspire allergic reactions in people? > > Surely it's not the . itself, but the requirement that you fit everything > > into that one syntactic mold. Perl's not going to do that. > > I don't mind it, but I always imagined: > > $obj->method(); > $obj.attribute; Principle of uniform access says you really don't want to distinguish those two if you can possibly help it.. > > or something vaguely C-ish like that. And I think most Perl folks like the > -> for class/object methods. It's a cute little arrow :) You'll have to > make it very clear why . is a better fit for Perl 6 than -> Otherwise > people will probably mourn the missing Mr. Pointy ;) -- Piers Cawley www.iterative-software.com
Re: Tying & Overloading
On Mon, Apr 23, 2001 at 12:36:47PM -0400, Dan Sugalski wrote: > What's wrong with something like: >$foo = $a :+ $b; Well, at least it's colon rule compliant. -- You want to read that stuff, fine. You want to create a network for such things, fine. You want to explore the theoretical boundaries of free speech, fine. But when it starts impacting *people* trying to *communicate*, then that is where I draw the line. - Russ Allbery, http://www.slacker.com/rant.html
Re: Larry's Apocalypse 1 \}
Dan Sugalski wrote: > I'm not a parser guy by any means (unfortunately) but we have > the distinct possibility of completely replacing all of the > parser rules after token X appears, whatever that token might > be. (Heck, we may have the possibility of replacing the entire > parser) There's no guarantee the non-perl-6 section will have a > nice end-delimiter for us to find. Granted that won't be the > case all the time, but it's certainly quite feasable. We might > not even be able to rely on perl's definition of a token. (Or > whitespace for that matter--Whitespace isn't just whitespace in > python mode) sounds a lot like an "exec" system call: there are some things which remain in effect (open file handles, current directory, environment) but there are many others which do not. Maybe switching parsers is best an absolute kind of thing rather than a stacked kind of thing, with the later parser responsible for switching back. -- David Nicol 816.235.1187 [EMAIL PROTECTED] "Described as awesome by users"
Re: s/./~/g
John Porter writes: : Larry Wall wrote: : > Surely it's not the . itself, but the requirement that you fit everything : > into that one syntactic mold. Perl's not going to do that. : : I'm not opposed to the change, but I want to make one point: : certain characters (like dot) are special in regexes, so : when you want to search for them, you have to escape them, : whether in vi, or with grep, or perl, or whatever. : String concats with dot are uncommon enough; but member : access is quite common. Okay, but it's just as many characters to say -> as it is \., y'know. There *is* one place where it's more problematic to use ., and that's interpolating method calls. For this reason, method interpolations are likely to require parentheses, even if there are no arguments. Otherwise "$file.ext" is gonna break badly. Larry
Re: Tying & Overloading
On Mon, Apr 23, 2001 at 12:36:47PM -0400, Dan Sugalski wrote:
> At 02:52 PM 4/23/2001 +0200, Davíð Helgason wrote:
> >"H.Merijn Brand" wrote:
> > >
> > > > > $a = $b ~ $c; # Mmm!
> > > > >
> > > > > I like that last one a lot, because it doesn't disturb anything.
> > > > > You'd have to alter ~'s precedence so that binary ~ is higher
> > > > > than named unary operators. (It's print($a~$b), not print $a (~b).)
> > > >
> > > > I am not sure I do like the use of ~ here. It does not screan concatenate
> > > > to me (but then again neither did . when I started perl)
> > > >
> > > > I am thinking that maybe it should be a 2 character operator with at
> > > > least one of then being + as + is common in many other languages
> > > > for doing concatenation.
> >
> >Which of qw[~ ++ +~ + &] do we dislike the least? Using + would be
> >nice, but introduce no end of problems with number/sting behaviour. '&'
> >is too much like a certain unpopular language. And there was no end to
> >the quabbling :(
>
> What's wrong with something like:
>
>$foo = $a :+ $b;
I was thinking along those lines too.
In fact it made me think of something Larry said (I think) about operators
operating on whole arrays. So :+ might be the addition of all elements, eg
@foo = @a :+ @b;
So if a leading : would mean the operator was an array operator, maybe we
could use something else for string operators (say ~). This would also help
disambiguate the difference of & when its operands are numbers or strings
as & would always be for numbers and ~& would be for strings. eg
$foo = $a + $b; # addition
$foo = $a ~+ $b; # concat
$foo = $a & $b; # logical and of IVs
$foo = $a ~& $b; # bitwise and of PVs
@foo = @a :+ @b; # same as @foo = map { $a[$_] + $b[$_] } for 0..max($#a,$#b);
@foo = $a :+ @b; # same as @foo = map { $a + $b[$_] } for 0..$#b;
etc...
Graham.
Re: Tying & Overloading
Nathan Wiger writes:
: Larry Wall wrote:
: >
: > : I _really_ think dot-syntax would make perl prettier as well as make it
: > : more acceptable to the world of javacsharpbasic droids. Which is some
: > : kind of goal, no?
: >
: > Consider it a given that we'll be using . for dereferencing. (Possibly
: > with -> as a synonym, just for Dan. :-)
:
:
:
: > + is out because it will add numbers.
:
: FWIW, if we're going to go "all the way" and make Perl's objects .-based
: (which I personally dread, but oh well),
The . is just syntax. Do you mean something semantic by ".-based"?
: then we should adopt the "+"
: for string concat as well. Yes, I know that string concat isn't
: commutative and all the other stuff, but who cares?
I don't care about commutative either, but what you are proposing is to
throw away a particularly useful feature of Perl, which is its
autoconversion between numbers and strings. That we're not going
to lose. This implies that string operators must stay distinct
from numeric operators.
: Sometimes taking
: what other languages do just because it's widely used is worthwhile. I
: personally don't know of any other language that uses "~" for string
: concat. Does anyone else?
Doesn't ~ look like a piece of string to you? :-)
I think it kind of looks like a stitch.
: Besides, if everything's an object and you have a vtable/whatever PLUS
: method, then why shouldn't:
:
:print "The next loop will be " + $i + 1 + "\n";
:
: DWIM?
Then how do you concatenate a number?
: As a segue for a second, we should keep in mind which types of people
: we're trying to satisfy. I personally don't care at all if Perl 6 is
: more popular with Java and C# people than Perl 5. But I definitely don't
: want it to be less popular with Perl folks (like me).
Me either. But then you propose to break one of the most endearing
features of Perl 5.
: With the proposed
: changes in this thread so far, you've got:
:
:P5 P6
:--- ---
:-> .
:. ~
:
: For no net gain.
For no *perceived* net gain. Let us be precise. :-)
There are many people who would prefer . to ->, if for no other reason
than it's cleaner looking and is one less character to type. The fact
that it's become the industry standard for method call syntax is also
a point in its favor.
Incidentally, Perl 6 will not require . everywhere that Perl 5 requires
->. The deref will be assumed before (), [], and {} (where an operator
is expected). We're only talking about method calls here, really.
: I know we're just brainstorming still,
Well, maybe we are, at that. But I feel as though I've been in design
mode for a while now. That is, any brainstorming I'm doing at this
point is merely to feel my way into the ramifications of making some of
the hard-nosed decisions that have to be made.
: but -> is not an
: oddity to Perl. There are other languages (like C) that use this.
To be fair, C also has the . variant, so there's certainly prior art on
the other side as well.
: And personally I think Perl is far more effective as a C-sh/cgi glue than a
: Java-.Net glue.
I think Perl is still suboptimal as C glue, and we can improve it. If
it becomes better VM glue at the same time, all the better. But I fail
to see how . notation can be much of a political issue, unless people
choose to turn it into one.
: The latter space is already populated w/ Java and C#,
: and Sun and MS have a little bit of marketing cash.
And because they have better marketing we should therefore concede in
the technical sphere? I don't follow.
: Just my own personal feelings. I don't want Perl 6 to be a complete
: disregard for Perl 5, but rather an improvement over it (RFC 28, you
: know...).
The question is, what is the essence of Perl 5? There are many
different levels on which we can conserve the spirit of Perl 5.
Syntactic continuity is merely one of those levels. An important
level, to be sure, but not inviolate. Not this time.
Larry
Re: Tying & Overloading
Why not
@foo = @( a + b ); # element by element add of @a and @b
or even
@( foo = a + b ); # element by element add of @a and @b assigned to
@foo.
I guess one could claim the idea is similar to the old BASIC MAT prefix,
although it was clearly reached by a different path. This could also
address the Highlander variables, to some extent leaving in today's
variable prefixes $, @, and %, one could factor out a certain amount of the
line noise in some circumstances via
$( foo = a + b ); # scalar addition of $a and $b, assigned to $foo
And for hashes, corresponding element addition...
%( foo = a + b );
If (keys %a) and (keys %b) do not produce the same list, it would be
expected that (keys %foo) would be the union, addition would be done on the
common keys, and the unique keys wold be copied. If you want %foo to get
the intersection, you could do something like
%( foo = a{keys %b} + b{keys %a}); # remember, the % context gets
distributed
Austin Hastings wrote:
> Okay, then:
>
> @foo = @( @a + @b );# @(), $(), and %() set context.
>
> Easier to identify the operators, and little or no question about the
> context...
>
> --- Larry Wall <[EMAIL PROTECTED]> wrote:
> > Stephen P. Potter writes:
> > : Maybe this is a crazy (or stupid) idea, but why couldn't we use the
> > $, @,
> > : and % characters?
> > :
> > : @foo = @a @+ @b;# element by element add
> >
> > Because it's difficult to tell the operators from the terms visually.
> >
> > Larry
>
> =
>
> Austin Hastings
> Global Services Consultant
> Continuus Software Corporation
> [EMAIL PROTECTED]
>
> __
> Do You Yahoo!?
> Yahoo! Auctions - buy the things you want at great prices
> http://auctions.yahoo.com/
--
Glenn
=
Due to the current economic situation, the light at the
end of the tunnel will be turned off until further notice.
Re: Tying & Overloading
Stephen P. Potter writes: : Maybe this is a crazy (or stupid) idea, but why couldn't we use the $, @, : and % characters? : : @foo = @a @+ @b; # element by element add Because it's difficult to tell the operators from the terms visually. Larry
Re: Larry's Apocalypse 1 \}
David L. Nicol writes: : Dan Sugalski wrote: : > I'm not a parser guy by any means (unfortunately) but we have : > the distinct possibility of completely replacing all of the : > parser rules after token X appears, whatever that token might : > be. (Heck, we may have the possibility of replacing the entire : > parser) There's no guarantee the non-perl-6 section will have a : > nice end-delimiter for us to find. Granted that won't be the : > case all the time, but it's certainly quite feasable. We might : > not even be able to rely on perl's definition of a token. (Or : > whitespace for that matter--Whitespace isn't just whitespace in : > python mode) : : : sounds a lot like an "exec" system call: there are some things : which remain in effect (open file handles, current directory, : environment) but there are many others which do not. Maybe : switching parsers is best an absolute kind of thing rather than : a stacked kind of thing, with the later parser responsible for : switching back. The truth is somewhere in the middle. It is incumbent on the outer rule to inform the inner rule how it thinks the inner rule ought to terminate, and it is the choice of the inner rule whether to follow the convention suggested by the outer rule. A rule that starts at a left parenthesis will suggest stopping on a right parenthesis, but if the inner rule is parsing troff, all bets are off on properly nesting parens. Larry
Re: Strings vs Numbers (Re: Tying & Overloading)
Bart Lateur writes:
: On Mon, 23 Apr 2001 16:14:50 -0400, John Siracusa wrote:
:
: >Using + for concat: no!
: >
: >My vote is to use . and require space before and after.
: >$this.$is.$ugly.$anyway ;)
:
: My vote is to ditch the concat operator altogether. Hey, we have
: interpolation!
:
: "$this$is$just$as$ugly$but$it$works"
At the moment I'm leaning toward ^ for concat, and ~ for xor. That
will help with ^= not resembling =~, though ~= would still mean The
Wrong Thing...
HOF is not an issue, since those will be $^whatever.
: Which reminds me... one problem I have with it is that it's too hard to
: separate a variable name from the rest of the string, if it also
: consists of word characters:
:
: my $bar = "BAR";
: print "foo${bar}baz"; -> fooBARbaz
:
: Since $bar is a lexical variable, this syntax doesn't make much sense
: anyway: it reeks of symbolic references and those don't work for
: lexicals.
:
: I think I'd like something incorporating a backslash would be nicer:
:
: print "foo$bar\Ebaz";
:
: It works, but it may have unwanted side effects -- in case the "\E"
: actually serves a purpose.
:
: But, you may completely forget about it. I just had to say this one day.
No, I already thought of that one yesterday, and I agree with you completely.
Though \E is probably not it.
Well, they're calling my flight, so I'd better shut down. (On layover
in Phoenix.)
Larry
RE: Re: Tying & Overloading
>I am not sure I do like the use of ~ here. It does not screan concatenate to me (but then again neither did . when I started perl) >I am thinking that maybe it should be a 2 character operator with at least one of then being + as + is common in many other languages for doing concatenation. How about $a cat $b? That keeps the theme of strings using words and numbers using symbols--like eq vs. ==. --Brent Dax
Re: Larry's Apocalypse 1 \}
Larry Wall wrote: > > David L. Nicol writes: > : > : [this parser switch thing] > : sounds a lot like an "exec" system call: there are some things > : which remain in effect (open file handles, current directory, > : environment) but there are many others which do not. Maybe > : switching parsers is best an absolute kind of thing rather than > : a stacked kind of thing, with the later parser responsible for > : switching back. > > The truth is somewhere in the middle. It is incumbent on the > outer rule to inform the inner rule how it thinks the inner rule > ought to terminate, and it is the choice of the inner rule whether > to follow the convention suggested by the outer rule. A rule that > starts at a left parenthesis will suggest stopping on a right > parenthesis, but if the inner rule is parsing troff, all bets are > off on properly nesting parens. > > Larry Right. The existence of these "all bets are off" cases is what makes, IMO, a non-stacked system look better. If the conversation starts in Russian, switches to Chechen, then Turkish, then English, the conversants might want to switch back to Russian without having to say a single word of Turkish or Chechen on the way back. Or they might not switch back at all! What I see as needed is a designated meta-token that will be reserved, in some form or another, as the switch-parser command. In human language you just switch, and the conversants notice that a switch has occured and if they are fluent they, by default, switch too -- this behaviour is confirmable by anyone who has spent time slacking at an embassy. The consensus remains that computers are not yet ready to figure out which of the languages they can understand they are being addressed in, even though the mechanism (start all the interpreters and the one that doesn't err out is the winner) has been available in science fiction since the early seventies (I encountered it in a yellowing paperback in 1977, the plot involved a midwestern dystopia run by a central computer which had been set up by a lone genius who later disappeared: it appeared to the naive that "the computer was running amok and killing people" but the protagonist was able to rule out mechanical error, eventually the culprit is cornered after a variety of suspensful moments -- Does anyone know the title of the book? I'd like to read it again now that I have Adult Perspective -- addititional remembered plot and setting details available on request) ... so we can't have the programs just switch. Even if they leave five consecutive blank lines between them? What about a hash-bang? Maybe putting a hash-bang in the middle of the text (outside of quoted literals, of course) could indicate that the referenced program is to take over the parsing duties. The problem with the oughts and incumbencies is, you have to come up with a whole minilanguage for telling the inner rule, "parse until you get to a right angle bracket at the beginning of a line" or something like that -- but then what have you gained over HERE notation? HERE notation is grand for language nesting: all those millions of perl programs that output HTML are a perfect example. But to replace the whole parser (replacing part of the parser can be reduced to replacing the whole parser with a very similar one) we don't care if we come back. We might not come back. We just need to choose a syntax for the transition. __PARSER_NAME__ matches other parts of the language behind the scenes the linkage could be arbitrarily complex, some languages might not be able to handle transitioning directly into some others, others might be able to switch over in medias. I don't know enough python to produce an example of a fragment that starts in perl and does __PYTHON__ to do some python-style array slicing using the variable names which had been momentarily before prefixed with @ symbols then does __PERL__ some time down, after the loops opened up with right curlies before the first switch have been closed by abandonment of indentation. That would be based on some very sophisticated handshaking, where the second language could close the first one's scopes and so on. What is the minimum granualrity of JPL? Can you write the first five lines of a function in JAVA and the last five lines in Perl? And the default case, the sensible autovivification, on encountering a __FUTBOL__ token would be to throw a syntax exception: Whatever is managing the developing op-code tree would have to catch those and see if it has a FUTBOL parser. Or throw an exception because it doesn't. -- David Nicol 816.235.1187 [EMAIL PROTECTED] "Described as awesome by users"
RE: Larry's Apocalypse 1 \}
> What I see as needed is a designated meta-token that will be reserved, in some form or another, as the switch-parser command. . . . > What about a hash-bang? Maybe putting a hash-bang in the middle of the text (outside of quoted literals, of course) could indicate that the referenced program is to take over the parsing duties. Or that we should dynaload (a la XS) a previously registered parser with that name. $foo=bar(); #!syntax VisualBasic baz=foo & frob() #!syntax Perl6 print $baz; That just feels right for some reason. Spooky... (cue X-Files theme) So, what else would we do with our new inline #! notation? Hmm... $foo=$bar; #!comment yadda yadda yadda blah blah blah foo bar baz #!endcomment $bar.=$baz; Maybe? Possibly? No? Darn... --Brent Dax [EMAIL PROTECTED]
Re: Larry's Apocalypse 1 \}
Brent Dax wrote: Yes, that is exactly what I had in mind, thanks for the validation. Only the comment syntax would have to come back to a designated module, with another hashbang. #!comment yadda yadda yadda blah blah blah foo bar baz #!VB6 foor=bar & frob()
Re: Larry's Apocalypse 1 \}
Why would it? Someone posited a nested stack of parsers, this thread is discussing the abandonment of one parser when going to the next. Really, the claim that it should be up to the invoked parser to determine where to go next allows the invoked parser to have syntax to return to the prior parser if it chooses to provide that option. So #!endcomment could be a perfectly valid termination of #!comment even if there is no #!endpython as much as we might like one. It also seems like the case of the outer parser determining the end of the text to which the inner parser is to be applied would be a useful one, but since the outer parser doesn't know the details of the syntax interpreted by the inner parser, it would be inappropriate to require that all parser switches be so delimited. So it seems like it would be useful to have a form of eval that has a parser specification parameter (or indirect object?) in addition to the usual string parameter. eval python "gibberish"; This would complement the parser switching syntax, and provide for text that is delimited and escaped by the rules of the outer parser to be interpreted by an inner parser. Of course, not all parsers necessarily would provide that feature, but if the standard perl6 parser did, that would allow it to be the meta-language (which would please most of us). "David L. Nicol" wrote: > Brent Dax wrote: > > Yes, that is exactly what I had in mind, thanks for > the validation. Only the comment syntax would have to > come back to a designated module, with another hashbang. > > > #!comment > yadda yadda yadda > blah blah blah > foo bar baz > #!VB6 > foor=bar & frob() -- Glenn = Due to the current economic situation, the light at the end of the tunnel will be turned off until further notice.
Re: Strings vs Numbers (Re: Tying & Overloading)
On Mon, Apr 23, 2001 at 05:19:22PM -0700, Larry Wall wrote: > At the moment I'm leaning toward ^ for concat, and ~ for xor. That I think that would lead to confusion too. In many languages ^ is xor and ~ is a bitwise invert. It is that way in perl now too, so perl is already quite standard in that area. Changing these just to get . for -> so that we are more "standard" seems very strange as you are loosing two standards to gain one. To be honest though I don't think it is possible to get a single char concat operator with loosing something else, which is a shame. It would be good if we could somehow overload + to be both string and numeric, but I not sure that is possible. The other choice is not to have a concat operator but instead have C, but I guess not many people would like that either. Graham.
Re: Tying & Overloading
Dan Sugalski wrote: > It wouldn't be all that tough to change this if you were so inclined--it'd > certainly be a simpler parser modification than some others that have been > proposed. Yes, I hadn't thought of that. Yay again. > (The requirement to predeclare all variables would come into play) Absolutely. > You'd lose easy interpolation of variables into strings, though) That would become the sole use for the funky chars. And since the type of each var is known, you'd only need one funky char. In effect, its semantics would change to purely one of forcing the recognition of an identifier where otherwise a string literal would be understood. my @things; # declare that things is an array print "things are $things"; # second occurrence of "things" here is taken as a variable name. # its type -- array -- is already known. -- John Porter
Re: s/./~/g
Larry Wall wrote:
> Okay, but it's just as many characters to say -> as it is \., y'know.
Yep. But I'll plead rule #1 for myself, and let it go.
(The other thought I had was that slashes might be nice, since
some filesystem hierarchies use it. But then the division op
gets squeeged.
Hm. Maybe by following the m// pattern, the component separator
could be locally user-settable.
Foo::Bar# the normal case
d./Foo.Bar/ # make it dot for the nonce. I mean hence.
d/[Foo/Bar] # make it slash.
d(->){Foo->Bar} # on second though... never mind.
)
> method interpolations
> are likely to require parentheses, even if there are no arguments.
> Otherwise "$file.ext" is gonna break badly.
I expect to see a lot more parens and/or curlies in interpolations.
And frankly it won't bother me none. As long as "$foo" still works
without 'em -- and I know I don't need to worry about that.
--
John Porter
It's a sky-blue sky
The satellites are out tonight
let x = x
Re: Strings vs Numbers (Re: Tying & Overloading)
Graham Barr wrote:
> The other choice is not to have a concat operator but instead have
> C, but I guess not many people would like that either.
sub concat(@) { join '', @_ }
Seems to me like the sort of thing that ought to be in the core.
--
John Porter
Re: Tying & Overloading
On Mon, 23 Apr 2001 13:19:24 +0100, Graham Barr wrote: >> Or we change the concatenation operator. >I am thinking that maybe it should be a 2 character operator with at >least one of then being + as + is common in many other languages >for doing concatenation. Or, in analogy to "cmp", "gt" etc: $a = $b plus $c; or $a = $b cat $c; -- Bart.
Re: Tying & Overloading
At 07:44 PM 04-23-2001 +0100, Graham Barr wrote: >Hm, I would expect @() in a scalar context to give the >same result as > > @tmp = @(...); $x = @tmp; > >That is, yeild the number of elements in the list. I can see this. But unless there is a good reason, that seems like a less-than-optimal side-effect. >What would be the benefit of it being the same as [...] ? It would be >one more character. I suspect that Larry is seeing that if @() in scalar context yielded the length of the resulting operation would result in vastly more uses of: $sums = [@(@a+@b)]; than $num_of_sums = @(@a+@b); If that's the case, then it makes sense to use the shorter notation for the more common case, especially when there is an easy, shorter way to get the uncommon case: $sums = @(@a+@b); $sumcount = \@(@a+@b); # assuming that $sumcount = @a isn't sufficient.
Re: Tying & Overloading
Graham Barr writes:
: On Mon, Apr 23, 2001 at 11:40:50AM -0700, Larry Wall wrote:
: > I do expect that @() and $() will be used for interpolating list and
: > scalar expressions into strings, and it is probably the case the $()
: > would be a synonym for scalar(). @() would then be a synonym for
: > the mythical list() operator. Which probably, in Perl 6, turns out
: > to be equivalent to [...] when used in a scalar context, and a no-op
: > in list context. That is, $() and @() would essentially be typecasts.
:
: Hm, I would expect @() in a scalar context to give the
: same result as
:
: @tmp = @(...); $x = @tmp;
:
: That is, yeild the number of elements in the list.
Well, it does, but it does it differently. After the assignment, $x
contains a pointer to @tmp. However, if you say $x where a number is
wanted, you still get the length. If you're worried about the delayed
operation, you can force numeric context with $x = +@tmp;, just as you
can force string context with a unary ~.
: What would be the benefit of it being the same as [...] ? It would be
: one more character.
It's not the same. It's a cast, not a composer. It only comes out the
same in scalar context by accident. In string context, it
interpolates. In list context, it does nothing. The behavior of
emulating [] in a scalar context really stems from the more basic
notion that lists in Perl 6 should behave more polymorphically,
emulating the behavior of Perl 5 where it can. So when you say
for ($i = 0, $j = 0; $i < 10; $i++, $j++) {
}
The C-style comma operator would actually no longer be defined quite
the same. Rather, it's notionally producing a list that gets discarded
in void context. In the rare case that you're really interested in the
last value of a list, use ()[-1] instead.
All subject to Rule 2, of course. :-)
Larry
