Re: Tying Overloading
James Mastros [EMAIL PROTECTED] writes: From: Larry Wall [EMAIL PROTECTED] Sent: Monday, April 23, 2001 1:10 PM Subject: Re: Tying Overloading 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. :-) Larry I hate yelling without good reason, but this /is/ good reason. CAN SOMBODY PLEASE TELL ME A _GOOD_ REASON TO SWITCH TO . FOR METHOD CALLS? One reason I have heard is that COM (Common Object Model) documents incantations to call up external objects in VBish thing.whatnot.attrib style. Not having to s/\./-/ make it easier on newbies. -- Nick Ing-Simmons who is looking for a new job see http://www.ni-s.u-net.com/
Re: Tying Overloading
Will it be possible to define pointer classes, a la C++, in a relatively smooth manner? That is, an object R has methods of its own as well as methods belonging to the referred to object? E_G: print $R.toString is a reference to $R-toString; Or some such? The notion of $R.getData.toString is kind of lame... =Austin Consider it a given that we'll be using . for dereferencing. (Possibly with - as a synonym, just for Dan. :-) 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
On Wed, May 09, 2001 at 02:05:48PM -0700, Austin Hastings wrote: Will it be possible to define pointer classes, a la C++, in a relatively smooth manner? That is, an object R has methods of its own as well as methods belonging to the referred to object? Sounds you're looking for automatic delegation. There's an RFC dealing with this... http://dev.perl.org/rfc/193.pod and a Perl5 module planned, Class::Delegation. -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One An official I want James Earl Jones' cock up my ass t-shirt. http://www.goats/com/archive/010303.html
Re: Strings vs Numbers (Re: Tying Overloading)
On Wed, 25 Apr 2001 06:09:56 -0700 (PDT), Larry Wall wrote:
Bart Lateur writes:
: Er... hip hip hurray?!?!
:
: This is precisely the reason why I came up with the raw idea of
: highlander variables in the first place: because it's annoying not being
: able to access a hash passed to a sub through a hash reference, in the
: normal way. Not unless you do aliasing through typeglobs.
: But, if there won't be full blown highlander variables, how does Perl
: know if by $foo{THERE} you mean an item of the hash %foo, or a item in a
: hash referenced by the hashref $foo?
$foo{THERE} always means the hashref in $foo. %foo{THERE} always means
the hashref in %foo. %foo by itself in scalar context means a hashref.
@foo by itself in scalar context means an arrayref. foo by itself in
a scalar context means a coderef. It's gonna be pretty consistent.
Yeah. But no cheers then. The problem still remains: you can access a
hash in the normal way in plain code, but inside a sub, you can mainly
only access a passed hash through a reference.
It's annoying to basically having two ways of doing something, and one
of them can't be used half of the time.
Even though @foo and %foo may be two different structures, a scalar $foo
can only reference one of them at a time.
Are you going to provide a simpler aliasing mechanism to turn a hash
reference, for example as passed to a sub as an argument, back into the
full-blown hash? Simpler (and safer) than the much frowned upon
assignment to a tyeglob, that is.
--
Bart.
Re: Strings vs Numbers (Re: Tying Overloading)
Bart Lateur writes: : Yeah. But no cheers then. The problem still remains: you can access a : hash in the normal way in plain code, but inside a sub, you can mainly : only access a passed hash through a reference. Won't be a problem. : It's annoying to basically having two ways of doing something, and one : of them can't be used half of the time. : : Even though @foo and %foo may be two different structures, a scalar $foo : can only reference one of them at a time. : : Are you going to provide a simpler aliasing mechanism to turn a hash : reference, for example as passed to a sub as an argument, back into the : full-blown hash? Simpler (and safer) than the much frowned upon : assignment to a tyeglob, that is. Yes. In fact, a %hash prototype will provide a scalar context, forcing a %foo arg to return a reference, and that ref will be aliased to %hash. You will be required to do something explicit to declare an argument that supplies list context and slurps the rest of the args. (There will also be an explicit way to slurp a list of items but supply scalar context.) Larry
Re: Strings vs Numbers (Re: Tying Overloading)
At 09:06 PM 4/24/2001 -0700, Larry Wall wrote:
Edward Peschko writes:
: Ok, so what does:
:
: my %hash = ( 1 = 3);
: my $hash = { 1 = 4};
:
: print $hash{1};
:
: print?
4. You must say %hash{1} if you want the other.
I was teaching an intro class yesterday and as usual, there were several
people who typed just that instead of what I'd taught, so there is
obviously some intuitive merit to it.
Re: Strings vs Numbers (Re: Tying Overloading)
John Porter wrote: We could y/$@%/@%$/ ... ... and create an alternate parser able to handle the full internal internals API. I have finally figured out the main motivation behind the whole perl6 effort: the obfuscated perl contests were getting repetitive. Good night.
Re: Strings vs Numbers (Re: Tying Overloading)
On Tue, 24 Apr 2001 18:39:09 -0700 (PDT), Larry Wall wrote:
Edward Peschko writes:
: I guess my question is what would be the syntax to access hashes? Would
:
: $hashref.{ }
:
: be that desirable? I really like -{ } in that case..
It won't be either of those. It'll simply be $hashref{ }.
Er... hip hip hurray?!?!
This is precisely the reason why I came up with the raw idea of
highlander variables in the first place: because it's annoying not being
able to access a hash passed to a sub through a hash reference, in the
normal way. Not unless you do aliasing through typeglobs. A highlander
variable would get you that: that if a hash %foo exists, the scalar $foo
would automatically be a reference to that hash.
But, if there won't be full blown highlander variables, how does Perl
know if by $foo{THERE} you mean an item of the hash %foo, or a item in a
hash referenced by the hashref $foo?
--
Bart.
Re: Strings vs Numbers (Re: Tying Overloading)
On Tue, 24 Apr 2001 21:06:56 -0700 (PDT), Larry Wall wrote:
: Ok, so what does:
:
: my %hash = ( 1 = 3);
: my $hash = { 1 = 4};
:
: print $hash{1};
:
: print?
4. You must say %hash{1} if you want the other.
Ok. So how about hash slices? Is $hash{$a, $b}, the faked
multidimensional hash, going to go? Otherwise %hash{$a, $b} is going to
be ambiguous.
--
Bart.
Re: Strings vs Numbers (Re: Tying Overloading)
Bart Lateur writes:
: Er... hip hip hurray?!?!
:
: This is precisely the reason why I came up with the raw idea of
: highlander variables in the first place: because it's annoying not being
: able to access a hash passed to a sub through a hash reference, in the
: normal way. Not unless you do aliasing through typeglobs. A highlander
: variable would get you that: that if a hash %foo exists, the scalar $foo
: would automatically be a reference to that hash.
:
: But, if there won't be full blown highlander variables, how does Perl
: know if by $foo{THERE} you mean an item of the hash %foo, or a item in a
: hash referenced by the hashref $foo?
$foo{THERE} always means the hashref in $foo. %foo{THERE} always means
the hashref in %foo. %foo by itself in scalar context means a hashref.
@foo by itself in scalar context means an arrayref. foo by itself in
a scalar context means a coderef. It's gonna be pretty consistent.
Likewise, bare @foo, %foo, foo in function prototypes will default
to supplying a scalar context, so they don't eat arguments. The final
argument will have to be specifically marked if you want it to eat
up arguments. And we'll probably distinguish eating a list in list
context from eating a list of scalars, so you could pass a list of
arrays easily to a variadic function with each variable name in
scalar context so as to produce a reference.
This is a little hard to explain, but I intuit that it will turn out to
be intuitive.
Larry
Re: Tying Overloading
From: Larry Wall [EMAIL PROTECTED] Sent: Monday, April 23, 2001 1:10 PM Subject: Re: Tying Overloading 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. :-) Larry I hate yelling without good reason, but this /is/ good reason. CAN SOMBODY PLEASE TELL ME A _GOOD_ REASON TO SWITCH TO . FOR METHOD CALLS? Reasons I have seen are: 1) Two less keys to press. 2) Looks cleaner. 3) Looks more like other languages. Counterarguments: 1) Produces confusion for perl5 programmers. I think that we should be kinder to perl5 programmers switching to perl6 then to java[script]/vb programmers switching to perl6. (C and C++ shouldn't be an issue; we stole - from C in the first place.) I submit that := is far uglyer and harder to type then -. I don't think that we should change around huge amounts of other things just so we can s/-/./. If we really want an easyer-to-type method call operator, I'd go with \. It's use currently outside of a qq is erronious. It can't interoperlate inside of qq, but nor can any other operator discussed here. It doesn't look much like whitespace (if that's what you mean by looks nice). If you want that, you could go with `, which could produce some ambiguity, both with qx and with ', which looks very similar in many fonts. BTW, I think that considering no-whitespace cases of indirect object is quite silly -- does anybody acatualy use that? This is the first I thought it wasn't a syntax error. -=- James Mastros
Re: Strings vs Numbers (Re: Tying Overloading)
Nathan Wiger wrote: Here's something I was thinking about at lunch: $concated_number = $number + $other_number; $numerical_add = $number + $other_number; One major, MAJOR pet peeve I have wrt Javascript is that it uses + to mean concatenation as well as addition, and that it (like perl) allows scalars to contain strings or numbers. One is continually forced to jump through hoops to do simple arithmetic. User has entered a number -- ah, but it comes in as a string. Want to add 666 to it? You have to do this nonsense: $sum = $addend - 0 + 666; You constantly have to subtract zero in order to force a numeric context. Asinine. Whatever the final Perl 6 solution to string concatenation/addition is, don't let it become the ambiguous mess that Javascript is. My two cents. Thanks for listening. -- Eric J. Roode[EMAIL PROTECTED] Senior Software Engineer, Myxa Corporation
Re: Tying Overloading
On Wed, Apr 25, 2001 at 12:44:11PM -0400, James Mastros wrote: I hate yelling without good reason, but this /is/ good reason. CAN SOMBODY PLEASE TELL ME A _GOOD_ REASON TO SWITCH TO . FOR METHOD CALLS? You've made it impossible for anyone to answer you until you tell us what good means to you. We could give reasons all day long and you could reply with those aren't GOOD reasons. How about this one: Because Larry said so. Seems good enough to me. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: Strings vs Numbers (Re: Tying Overloading)
On Mon, Apr 23, 2001 at 12:59:54PM -0700, Nathan Wiger wrote: Doesn't ~ look like a piece of string to you? :-) It looks like a bitwise op to me, personally. That's because every time you've used it in Perl, it's been a bitwise op. Sapir-Whorf, and all that. -- So what if I have a fertile brain? Fertilizer happens. -- Larry Wall in [EMAIL PROTECTED]
Re: Strings vs Numbers (Re: Tying Overloading)
On Wed, Apr 25, 2001 at 06:46:20PM +0100, Simon Cozens wrote: On Mon, Apr 23, 2001 at 12:59:54PM -0700, Nathan Wiger wrote: Doesn't ~ look like a piece of string to you? :-) It looks like a bitwise op to me, personally. That's because every time you've used it in Perl, it's been a bitwise op. Sapir-Whorf, and all that. Not just Perl. Many other languages use ~ the same as Perl does now. Graham.
Re: Tying Overloading
On Wed, 25 Apr 2001, James Mastros wrote: I hate yelling without good reason, but this /is/ good reason. CAN SOMBODY PLEASE TELL ME A _GOOD_ REASON TO SWITCH TO . FOR METHOD CALLS? It might be prudent to avoid rushing to judgment until the bigger picture becomes clearer. We have yet to see what changes might be in store for how, when, and why we'll be using method calls in perl6 vs. perl5. -- Andy Dougherty [EMAIL PROTECTED] Dept. of Physics Lafayette College, Easton PA 18042
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 Cconcat LIST, 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: Strings vs Numbers (Re: Tying Overloading)
Graham Barr wrote:
The other choice is not to have a concat operator but instead have
Cconcat LIST, 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: Strings vs Numbers (Re: Tying Overloading)
Bart Lateur [EMAIL PROTECTED] writes:
My vote is to ditch the concat operator altogether. Hey, we have
interpolation!
$this$is$just$as$ugly$but$it$works
How do you concatenate together a list of variables that's longer than one
line without using super-long lines? Going to the shell syntax of:
PATH=/some/long:/bunch/of:/stuff
PATH=${PATH}:/more/stuff
would really be a shame.
--
Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: Tying Overloading
On Mon, Apr 23, 2001 at 11:31:18AM -0700, Larry Wall wrote:
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.
Something in my gut feels wrong about needing to relearn all my operators
to use Perl 6. When I write Perl, . MEANS concatination to me. It's
spread through all my code. I know that Perl 6 is going to evolve...but
this is attacking something fundamental to the way I perceive the language.
Change what ., ~, and ^ mean in Perl 6, and I'll need to keep two
operator maps in my head whenever I look at Perl code. OK, this is
some old Perl 5, so ~$foo is a bitwise negat...oh, wait, it's really
new Perl 6, and this is a concatination...
I'm a neophile, and I'd balk at switching to a Perl 6 that did that.
I know my coworkers would revolt; they're already dubious about Perl's
level of complexity.
I'd really rather just make method calls with -.
If you're dead-set on reassigning ., please consider leaving it at
that, rather than juggling all the other operators around. Make
concatination be $a cat $b. (eq and friends already provide
precedent for string operators being words rather than symbols.)
- Damien
Re: Strings vs Numbers (Re: Tying Overloading)
On 24 Apr 2001 00:29:23 -0700, Russ Allbery wrote:
How do you concatenate together a list of variables that's longer than one
line without using super-long lines? Going to the shell syntax of:
PATH=/some/long:/bunch/of:/stuff
PATH=${PATH}:/more/stuff
would really be a shame.
A backslash at the end of a line?
Kidding!
--
Bart.
Re: Tying Overloading
On Tue, 24 Apr 2001 10:49:18 +0100, Simon Cozens wrote: While that's true, concatenation is quite a common operation that I'd be really uncomfortable with it necessitating 4 keystrokes ( cat) instead of one. Er, ~ is an extremely annoying character to type at many keyboards. It may depend on your keyboard localization. On my Belgian keyboard, I have to press Alt-Gr (the second Alt) and keep it down, then the ~ button, release Alt-Gr, then a space. I don't find this handy, because it's far too easy to mess up. Just the word cat (or cc) is a lot less work, simply because it requires no special keypresses. -- Bart.
RE: Tying Overloading
From: Simon Cozens [mailto:[EMAIL PROTECTED]] Make concatination be $a cat $b. (eq and friends already provide precedent for string operators being words rather than symbols.) While that's true, concatenation is quite a common operation (Introspection is cool. Run perl -MO=Terse someprogram | grep concat.) that I'd be really uncomfortable with it necessitating 4 keystrokes ( cat) instead of one. On my keyboard '~' is 3 keystrokes - and rather complicated ones at that: hold down ALTGR (rigth alt) and press the ^/ยจ/~ key release them both press spacebar This is a danish keyboard - many other non-US keyboards have similar (but different) encodings. Please don't use the keypresscount as an argument. Henrik Tougaard - FOA, Copenhagen, Denmark.
Re: Tying Overloading
On Tue, Apr 24, 2001 at 12:31:44PM +0200, Henrik Tougaard wrote: On my keyboard '~' is 3 keystrokes - and rather complicated ones at that: Then maybe ~ isn't best. Please don't use the keypresscount as an argument. Why not? We're making easy things easy, remember. -- Rule 3: If the character is comprised of a container without another radical, then Rule 3 will not apply.
Re: Tying Overloading
At 02:55 AM 4/24/2001 -0400, John Porter wrote: 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 one downside is that you'd have essentially your own private language. Whether this is a bad thing or not is a separate issue, of course. OTOH, it might not be inappropriate for there to be several variants of perl available with differing syntax. PL/I seemed to manage OK with something like this. (While PL/I is mostly dead, its death wasn't as a result of the varying subsets out there...) Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Tying Overloading
Dan Sugalski wrote: The one downside is that you'd have essentially your own private language. Whether this is a bad thing or not is a separate issue, of course. IIUC, this ability is precisely what Larry was saying Perl6 would have. -- John Porter
Re: Tying Overloading
On Tue, Apr 24, 2001 at 03:26:04PM +0200, Henrik Tougaard wrote: From: Simon Cozens [mailto:[EMAIL PROTECTED]] On Tue, Apr 24, 2001 at 12:31:44PM +0200, Henrik Tougaard wrote: Please don't use the keypresscount as an argument. Why not? We're making easy things easy, remember. Because your keyboard layout isnt mine! Let's put it a different way - if we can find a short operator which is readily accessible on most people's keyboards, then that would score over a longer operator which is readily accessible on most people's keyboards. Maybe ~ isn't that operator. Maybe is, or ^ or #, or whatever. -- Having just ordered 40 books and discovered I have no change out of a grand, I'm thinking of getting a posse together and going after some publishers. I'd walk into a petrol station and buy lots of petrol on Monday, too, but I think I'd get funny looks. More funny looks. - Mark Dickerson
Re: Tying Overloading
At 09:33 AM 4/24/2001 -0400, John Porter wrote: Dan Sugalski wrote: The one downside is that you'd have essentially your own private language. Whether this is a bad thing or not is a separate issue, of course. IIUC, this ability is precisely what Larry was saying Perl6 would have. I am passing no judgement on the goodness or badness of the proposal, merely observing that you will be working with a variant of perl, and that may have some issues. It's not my call as to whether you should or not. (It may be, however, that a language variant would cause more cognitive dissonance in many people than a completely different language. IOW, switching to python in mid-source may cause folks fluent in perl less trouble than switching to prefixless highlander perl) Having done this myself (Dec BASIC allowed this for the longest time) I find that it isn't a big deal if it's a known thing. I am not most people, though. Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Tying Overloading
On Tue, 24 Apr 2001 14:37:02 +0100, Simon Cozens wrote: Let's put it a different way - if we can find a short operator which is readily accessible on most people's keyboards, then that would score over a longer operator which is readily accessible on most people's keyboards. Maybe ~ isn't that operator. Maybe is, or ^ or #, or whatever. '~' is not good because it's very hard to reach. But ^ is a deadkey too, so this one also needs pressing a space. If you want something that's easy to type and that won't conflict with current Perl, try !. Too bad _ is a word character. -- Bart.
Re: Strings vs Numbers (Re: Tying Overloading)
On Tue, Apr 24, 2001 at 12:29:23AM -0700, Russ Allbery wrote: How do you concatenate together a list of variables that's longer than one line without using super-long lines? join '', $var1, $var2, $var3, ..., $varN; TMTOWTDI, remember. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: Tying Overloading
Simon Cozens wrote: Let's put it a different way - if we can find a short operator which is readily accessible on most people's keyboards, then that would score over a longer operator which is readily accessible on most people's keyboards. Maybe ~ isn't that operator. Maybe is, or ^ or #, or whatever. Or maybe a word operator, in the same family as cmp, eq, ne, le, gt... Perl's stigma for unreadability is bad enough already; now at least we have a good opportunity to unwreak some badness. -- John Porter
Re: Strings vs Numbers (Re: Tying Overloading)
On Tue, 24 Apr 2001, Graham Barr wrote: 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. I think someone may have mentioned this already, but why not just say that if you want '.' to mean concatenation, you have to surround it on either side with white space? If there's no white space around it, then it is forced to mean method invokation, or whatever else. Sure, some japhs will break, but that's just too bad :-) Perl already has other cases where white space matters, why not one more. That way, perhaps we can all get what we want, namely that '.' means both concatenation _and_ method invokation. John.
Re: Strings vs Numbers (Re: Tying Overloading)
On Tue, Apr 24, 2001 at 12:32:29PM -0400, John L. Allen wrote: I think someone may have mentioned this already, but why not just say that if you want '.' to mean concatenation, you have to surround it on either side with white space? If there's no white space around it, then it is forced to mean method invokation, or whatever else. This approaches whitespace as syntax. Very few Perl operators care about whitespace between their words (even -) or whitespace at all. More generally, its going to cause alot of careful squinting at code to distinguish between different operators. This will lead to subtle bugs because someone accidentally put a space after the . and didn't notice. Its just cutting it too thin. Don't go this route unless others are exhausted first. -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One BOFH excuse #100: IRQ dropout
Re: Strings vs Numbers (Re: Tying Overloading)
On Tue, Apr 24, 2001 at 12:32:29PM -0400, John L. Allen wrote: : : On Tue, 24 Apr 2001, Graham Barr wrote: : : 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. : : I think someone may have mentioned this already, but why not just say : that if you want '.' to mean concatenation, you have to surround it on : either side with white space? If there's no white space around it, then : it is forced to mean method invokation, or whatever else. Sure, some : japhs will break, but that's just too bad :-) Perl already : has other cases where white space matters, why not one more. That way, : perhaps we can all get what we want, namely that '.' means both : concatenation _and_ method invokation. No thanks. We already have the ability to put white space around '-' which is helpfull a la Soap::Lite. Besides, I can't think of instances where white space matters without being except: print __EOT__ __EOT__ which is easily avoidable via 'print __EOT__'. -- Casey West
Re: Strings vs Numbers (Re: Tying Overloading)
On Tue, Apr 24, 2001 at 05:44:49PM +0100, Michael G Schwern wrote:
On Tue, Apr 24, 2001 at 12:32:29PM -0400, John L. Allen wrote:
I think someone may have mentioned this already, but why not just say
that if you want '.' to mean concatenation, you have to surround it on
either side with white space? If there's no white space around it, then
it is forced to mean method invokation, or whatever else.
This approaches whitespace as syntax. Very few Perl operators care
about whitespace between their words (even -) or whitespace at all.
More generally, its going to cause alot of careful squinting at code
to distinguish between different operators. This will lead to subtle
bugs because someone accidentally put a space after the . and didn't
notice.
Its just cutting it too thin. Don't go this route unless others are
exhausted first.
ok, well.. I've heard arguments for '+' (namely that its intuitive, other
language compatible, etc...) so what are the arguments against it?
after all, it has a corresponding operator in minus:
hey - y = he
my $singluar = $plural - s;
The only thing I could see gumming up the works is if one argument is a string,
and the other argument is a number, and both are in variables:
my $a = hello;
my $b = 3;
print $a + $b; # should print hello3;
print $b + $a # prints 3hello;
This would be doable ( along with making $a $b context dependent ).
Question is, would it be too confusing, too prone to error? I like it better
than '~' (which seems odd to me..)
As for '.', well I think that makes sense if packages are 'first class', and
they can contain variables, ie:
class MyClass
{
my $a = 1; # instance variable
our $b = 2; # static variable
my @c = (1,2);
}
my $b = new MyClass()
print $b.a;
print @b.c
print $b.d{'a'}
print $MyClass::b;
Ed
Re: Strings vs Numbers (Re: Tying Overloading)
ok, well.. I've heard arguments for '+' (namely that its intuitive, other language compatible, etc...) so what are the arguments against it? Well, it looks like I'm a little bit behind. Spend 15 minutes typing something, and you get 7 messages in your mailbox on the exact topic that you had questions on. sheesh. Ed
Re: Strings vs Numbers (Re: Tying Overloading)
On Tue, Apr 24, 2001 at 12:23:33PM -0700, Edward Peschko wrote: ok, well.. I've heard arguments for '+' (namely that its intuitive, other language compatible, etc...) so what are the arguments against it? This one seems to have slipped by... http://archive.develooper.com/perl6-language%40perl.org/msg06550.html Basically talking about the problems of trying to use the same operator for strings and concat in a typeless language. -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One Beer still cheaper than crack!
Re: Strings vs Numbers (Re: Tying Overloading)
Michael G Schwern wrote:
On Tue, Apr 24, 2001 at 12:23:33PM -0700, Edward Peschko wrote:
ok, well.. I've heard arguments for '+' (namely that its intuitive, other
language compatible, etc...) so what are the arguments against it?
This one seems to have slipped by...
http://archive.develooper.com/perl6-language%40perl.org/msg06550.html
From that email:
Consider the following...
sub foo { $_[0] + $_[1] }
What do the following return?
foo(1,1); obviously 2
foo(this, that) obvious thisthat
Those are simple enough.
foo(1, 1);is that 11 or 2?
foo(undef, 1); 1 or 1?
Those can be solved by definining precidence, but its still a bit
arbitrary.
foo($foo, $bar);who knows?
Based on what I posted, my position would be: foo returns numeric
addition.
Again, don't think of + as a dual-natured op. That's not what I'm
saying. It remains numeric addition. The C + operator is your string
concat.
If you wanted foo to return a string concat, you would have to say:
sub foo { $_[0] + $_[1] }
(or use $_[1], either way). Without the quotes you're not properly
using the operator.
I'm not really fighting for what I posted per se, but I do want to
emphasize it's not the same as what's been discussed before.
-Nate
Re: Strings vs Numbers (Re: Tying Overloading)
I still think it's a good idea - better than any other proposed so far.
Are we so afraid of a little mandatory disambiguating white space
that we are willing to pay the price of contorting other syntax
beyond the bounds of sanity? :-)
It's perfectly obvious to me that
$x = $foo . bar;
wants to mean concatenation, and that
$x = $foo.bar;
doesn't.
Well, that's this inmate's HO anyway.
John.
I agree. The more I think about it, the more I like it. Think about it; we are
actually considering space *by itself* to be syntax. Which is bound to cause
more problems than space + '.'.
As for usability, I remember one project where someone had done this exact same
thing (via Filter::Util::Call) and it didn't cause any problems that I can
remember.
I guess my question is what would be the syntax to access hashes? Would
$hashref.{ }
be that desirable? I really like -{ } in that case..
Ed
Re: Strings vs Numbers (Re: Tying Overloading)
Edward Peschko writes:
: I guess my question is what would be the syntax to access hashes? Would
:
: $hashref.{ }
:
: be that desirable? I really like -{ } in that case..
It won't be either of those. It'll simply be $hashref{ }.
Larry
Re: Tying Overloading
On Tue, Apr 24, 2001 at 06:54:18PM -0700, Larry Wall wrote: Nick Ing-Simmons writes: : Larry Wall [EMAIL PROTECTED] writes: : I think using overloading to write a parser is going to be a relic of : Perl 5's limitations, not Perl 6's. : : I am _NOT_ using overloading to write a parser. : Parse::Yapp is just fine for writing parsers. I am trying to re-use : a parser that already exists - perl5's parser. Not trying to be pedantic or anything, but 'Parse::Yapp' is *not* the model to follow IMO if there is to be a generic parser tool made to create plug-in grammars. I'm not sure of performance issues, but 'Parse::FastDescent' would be a better model for designing one. IMO, tons more flexible and easy to use. Ed
Re: Strings vs Numbers (Re: Tying Overloading)
On Tue, Apr 24, 2001 at 06:39:09PM -0700, Larry Wall wrote:
Edward Peschko writes:
: I guess my question is what would be the syntax to access hashes? Would
:
: $hashref.{ }
:
: be that desirable? I really like -{ } in that case..
It won't be either of those. It'll simply be $hashref{ }.
Larry
Ok, so what does:
my %hash = ( 1 = 3);
my $hash = { 1 = 4};
print $hash{1};
print?
Ed
Re: Strings vs Numbers (Re: Tying Overloading)
Edward Peschko writes:
: Ok, so what does:
:
: my %hash = ( 1 = 3);
: my $hash = { 1 = 4};
:
: print $hash{1};
:
: print?
4. You must say %hash{1} if you want the other.
Larry
Re: Tying Overloading
Larry Wall wrote: (And juxtaposition is out because we're not going to destroy indirect object syntax How often is indirect object syntax used without some whitespace? Having the perl5-perl6 converter locate it and insert a space shouldn't be too very tricky. $these=$this$that$the_other; is what we've been doing inside double quotes for years. Making butted-against-each-other be the string concatenation operator looks good IMO. I'm thinking concat will be ~. Furthermore, I'm thinking unary ~ will be stringify. Not unary diglyph \ ?
Re: Tying Overloading
On Tue, Apr 24, 2001 at 02:01:11AM -0700, Damien Neil wrote: If you're dead-set on reassigning ., please consider leaving it at that, rather than juggling all the other operators around. Don't forget that binary ~ doesn't currently exist, so this is adding syntax rather than reassigning it. Make concatination be $a cat $b. (eq and friends already provide precedent for string operators being words rather than symbols.) While that's true, concatenation is quite a common operation (Introspection is cool. Run perl -MO=Terse someprogram | grep concat.) that I'd be really uncomfortable with it necessitating 4 keystrokes ( cat) instead of one. -- emacs: Terminal type emacs is not powerful enough to run Emacs.
Re: Tying Overloading
Hmm.
Larry Wall wrote: [to [EMAIL PROTECTED]]
This is much like a method:
my Cat chases (Dog $spot) :lvalue method = { ... };
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? whistle 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
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
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? whistle 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
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: Tying Overloading
Simon Cozens wrote: Or we change the concatenation operator. Perl: Snobol with embedded gravel. $a = $b $c; -- John Porter
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: 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: 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
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
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: 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
=?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
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
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. :-) snip + 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
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: 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
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
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. :-)
:
: snip
:
: + 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
[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: 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
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
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 Ccc if it had come to that. Larry
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: 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
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 out some alternatives. At which point you lose
people to Java or C# or other similar languages.
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: 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: 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)
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: 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
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: 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: 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: 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: 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.
