Re: ./method defunct
On Mon, Jun 20, 2005 at 07:34:57PM -0400, Kurt wrote: On 6/18/05, Juerd wrote: Why exactly is the slash not acceptable for you? Almost everyone has said they like it. I personally find ./method prettier and easier to type than any of the alternatives. I don't like it because I think method calls should look like method calls, and the slash separating the dot and name makes it look like something else entirely. On 6/19/05, Juerd wrote: David Storrs skribis 2005-06-19 13:45 (-0400): All that said, I still agree with John... './' does not look like method call syntax to me. That's good, because it's different from all other method syntax anyway, because it does not have any left hand side -- not even implied. I don't think it's good. A method call should look like a method call. What are the salient characteristics of looks like a method call? Is it no intervening characters between the . and the name of the method? Frankly, I don't understand the objection to using a keyword for $?SELF, such as `self`. Um ... isn't $?SELF a keyword? :-) Most other object-oriented languages use such a keyword, if not exactly the same one, so it will be a familiar concept. Certainly more readily understood for a newcomer than `./method`. I think the difference in how readily understood it is will be infinitesimally small. What's confusing about ./method is shorthand for $?SELF.method? As a bonus, `self` is easily searchable within the documentation, whereas `./` is not. I'll grant you that. But, as punctuation rich as perl is, we should provide a tool (p6doc?) to help with the searching and encourage people to use it. I missed responding to the thread the last time this subject came up, but the more I see this syntax the less I like it, so I wanted to add another voice to the dissention. However, if it remains official, I expect I'll simply be naming my invocants, as chromatic has suggested. I expect that soon after perl6 is released (heck, maybe before it's released) we'll get tools that will translate perl6 to perl6 while performing some syntactic manipulation. For instance, it could explicitize code (replacing ./method with $?SELf.method and .foo with $_.foo and so on) -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: ./method defunct
What does this have to do with perl6-internals? F-up to p6l. Matthew Zimmerman skribis 2005-06-21 11:27 (-0400): $self-_fraction * $self-concentration + $s2-_fraction * $s2-concentration You can still write it like that, if you declare a name ($self) for the invocant. Added to Perl is a shortcut, not a replacement. ./:fraction * ./concentration + $s2.:fraction * $s2.concentration That looks silly indeed, and is a good reason for not using ./foo HERE. It's not a good reason to not have ./foo at all. and it gives me the willies. Then don't use it. You don't have to use it. If I have a complicated mathematical expression If you have anything that is complicated, a verbose version should always be considered, if only to avoid getting lost in punctuation. This is not specific to ./foo in any way. with method calls in it (which happens a lot for me), the '/' part of './' in particular gives me lots of visual problems. It is visually much more suited for action than functional use: ./foo($bar, $baz); # beautiful print 5 + ./foo($bar); # ugly at the top of my code if I have to, but I want to make one last gasp at getting $Larry / @Larry to reconsider this. I find o. absolutily horrifying. But then, that's apparently how you think of ./, so we have to trust Larry's decision on this. I don't think further discussing this is really fruitful, as it has already been discussed more than is good for us. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: ./method defunct
Jonathan Scott Duff skribis 2005-06-21 10:00 (-0500): I expect that soon after perl6 is released (heck, maybe before it's released) we'll get tools that will translate perl6 to perl6 while performing some syntactic manipulation. For instance, it could explicitize code (replacing ./method with $?SELf.method and .foo with $_.foo and so on) Deparse. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: ./method defunct
Juerd wrote: What does this have to do with perl6-internals? F-up to p6l. Sorry! Typing faster than my brain is working. Resent to the right list. If I have a complicated mathematical expression If you have anything that is complicated, a verbose version should always be considered, if only to avoid getting lost in punctuation. This is not specific to ./foo in any way. If I'm calling a method on $?SELF five times in a statement and you're only calling one once, wouldn't such an operator be more important to me than to you? I'm not arguing that having a short way to call a method on the current invocant-- be it operator or keyword-- is a bad thing. It's a great feature, and why I'm delurking to comment on this. If 'o.' really doesn't work, it doesn't work. We could pick a different operator. I'm just saying that the particular choice of './' doesn't work for me (and evidently a number of other people). It is visually much more suited for action than functional use: ./foo($bar, $baz); # beautiful print 5 + ./foo($bar); # ugly Right here, in my mind, is an argument against it. I'd end up using the operator in some places and not others, because in some contexts it'd be ugly and others beautiful. Thus further reducing the visual consistency of the code. I haven't yet given up on the idea that there's a shortened operator that would be more universally readable. at the top of my code if I have to, but I want to make one last gasp at getting $Larry / @Larry to reconsider this. I find o. absolutily horrifying. But then, that's apparently how you think of ./, so we have to trust Larry's decision on this. I don't think further discussing this is really fruitful, as it has already been discussed more than is good for us. Fair point. I mean no offense, nor do I wish to beat a dead horse. I just want to make sure it's dead, instead of merely resting. -- Matt Matthew Zimmerman Interdisciplinary Biophysics, University of Virginia http://www.people.virginia.edu/~mdz4c/
Re: ./method defunct
[Sorry, sent this to the wrong list by mistake.]
Matthew Zimmerman wrote:
Juerd wrote:
Kurt skribis 2005-06-20 19:46 (-0400):
On 6/20/05, Juerd wrote:
Or you can just get your self with a simple (module that does)
macro self () { '$?SELF' }
And you could do the same for `./`.
Certainly.
However, there has proven to be much demand for something like ./method,
and in such cases, having it by default is probably the best thing.
I personally don't think it's either necessary or too much. I care about
.method using $_, and many other people care about having short syntax
for self.method too. ./method was something that would work for me, so I
shared that idea, and it was generally accepted.
Apart from the personal joy of seeing something I invented become part
of the official language, I don't really care if ./method is eventually
part of Perl 6 or not. I have always named my invocants, and don't mind
continue to do so. On the other hand, if there is a shorthand, I will
use it, because regardless of whether you think it's pretty or ugly, and
regardless of whether you think it looks enough like a method call,
having a short two character operator for this is in fact very
convenient.
Could we revisit the idea of using a shorter keyword for $?SELF, like
'o'? I know that $Larry said the idea was probably not going to work:
http://tinyurl.com/7baz6
but I'm curious if the reasoning that killed it then still holds now,
now that './' has emerged as a replacement.
Count me among the './' dissenters, too. The virtual explosion of new
operators in Perl 6 has not concerned me too much, as I don't envision
myself using many of them, but the operation that './' does is something
I do very frequently. I'm just imaging a lot of my Perl 5 code like:
if ( $self-unit_id == $s2-unit_id ) {
$self-add_component(
$self-_fraction * $self-concentration +
$s2-_fraction * $s2-concentration
);
$self-update;
}
replaced with:
if ( $.unit_id = $s2.unit_id ) {
./add_component(
./:fraction * ./concentration +
$s2.:fraction * $s2.concentration
);
./update;
}
and it gives me the willies. If I have a complicated mathematical
expression with method calls in it (which happens a lot for me), the '/'
part of './' in particular gives me lots of visual problems.
I'll put
macro o () { '$?SELF' }
at the top of my code if I have to, but I want to make one last gasp at
getting $Larry / @Larry to reconsider this.
--
Matt
Matthew Zimmerman
Interdisciplinary Biophysics, University of Virginia
http://www.people.virginia.edu/~mdz4c/
Re: ./method defunct
On 6/18/05, Juerd wrote: Why exactly is the slash not acceptable for you? Almost everyone has said they like it. I personally find ./method prettier and easier to type than any of the alternatives. I don't like it because I think method calls should look like method calls, and the slash separating the dot and name makes it look like something else entirely. On 6/19/05, Juerd wrote: David Storrs skribis 2005-06-19 13:45 (-0400): All that said, I still agree with John... './' does not look like method call syntax to me. That's good, because it's different from all other method syntax anyway, because it does not have any left hand side -- not even implied. I don't think it's good. A method call should look like a method call. Frankly, I don't understand the objection to using a keyword for $?SELF, such as `self`. Most other object-oriented languages use such a keyword, if not exactly the same one, so it will be a familiar concept. Certainly more readily understood for a newcomer than `./method`. As a bonus, `self` is easily searchable within the documentation, whereas `./` is not. The argument that this keyword cannot then be defined by user code is weak, as it would be rather hostile to use `self` for any other meaning inside of a class. I presume it could be overridden anyway, as with the other core built-ins, so it is not even an eternal loss, should the need actually arise. I missed responding to the thread the last time this subject came up, but the more I see this syntax the less I like it, so I wanted to add another voice to the dissention. However, if it remains official, I expect I'll simply be naming my invocants, as chromatic has suggested. Kurt
Re: ./method defunct
Kurt skribis 2005-06-20 19:34 (-0400):
However, if it remains official, I expect I'll simply be naming my
invocants, as chromatic has suggested.
Or you can just get your self with a simple (module that does)
macro self () { '$?SELF' }
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Re: ./method defunct
On 6/20/05, Juerd wrote:
Or you can just get your self with a simple (module that does)
macro self () { '$?SELF' }
And you could do the same for `./`.
Kurt
Re: ./method defunct
Kurt skribis 2005-06-20 19:46 (-0400):
On 6/20/05, Juerd wrote:
Or you can just get your self with a simple (module that does)
macro self () { '$?SELF' }
And you could do the same for `./`.
Certainly.
However, there has proven to be much demand for something like ./method,
and in such cases, having it by default is probably the best thing.
I personally don't think it's either necessary or too much. I care about
.method using $_, and many other people care about having short syntax
for self.method too. ./method was something that would work for me, so I
shared that idea, and it was generally accepted.
Apart from the personal joy of seeing something I invented become part
of the official language, I don't really care if ./method is eventually
part of Perl 6 or not. I have always named my invocants, and don't mind
continue to do so. On the other hand, if there is a shorthand, I will
use it, because regardless of whether you think it's pretty or ugly, and
regardless of whether you think it looks enough like a method call,
having a short two character operator for this is in fact very
convenient.
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Re: ./method defunct
John Siracusa wrote: On 6/18/05 8:28 PM, Juerd wrote: The unix shell and things resembling it will still be in use much fifteen years after today, Perl 5 will not. Ooo, a bold prediction :) Heh, it is indeed. And it means given the 16,000,000 lines of Perl in CPAN, we only have to keep the porting rate up at around a million lines of code a year. Adam K
Re: ./method defunct
On Jun 18, 2005, at 9:24 PM, Damian Conway wrote: chromatic wrote: I find it ugly enough that I plan to name my invocants explicitly. ...which should be construed as a *feature* of the current syntax. ;-) Damian In that case, why do we have this feature? Seriously. Are default invocants really such a good idea? At least, do they need to be there in 6.0.0? Do they need to be supported in the core engine, or could they be pushed out to a module? I guess that as long as we're arguing the color, we might as well argue the location of the bikeshed. All that said, I still agree with John... './' does not look like method call syntax to me. But, whatever. I suppose I'll get used to this, along with all the other things that have given me the heebie- jeebies so far. :/ --Dks
Re: ./method defunct
David Storrs skribis 2005-06-19 13:45 (-0400): Seriously. Are default invocants really such a good idea? Yes, as long as the default is $_. ./method doesn't use a default invocant. It calls method on the current invocant, which happens to be available as $?SELF: that doesn't mean it defaults to $?SELF. The term default is inappropriate if there is no way to specify anything else: $object./method is still invalid syntax. All that said, I still agree with John... './' does not look like method call syntax to me. That's good, because it's different from all other method syntax anyway, because it does not have any left hand side -- not even implied. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: ./method defunct
The reason we ended up at ./method was simply because it was the best suggestion anyone had. Compared to the previous suggestions it was way ahead. It's other advantage is that (except for on nordic keyboards) dot and slash are generally right next to each other, so the expense of using it is two chars and one fingering position, as they would likely be hit by fourth and fifth fingers (for touch typist style) and some other two fingers for the rest of us, and only 1 cm travel for hunt and peck. It has a very low RSI index :) (something I don't think we take into account enough as it is when we use the Huffman name to justify shortening something) So call it (2ch|2key|1pos|1cm) cost .::method on the other hand is 2 chars, 4 keystrokes, one of which must be held down between the two colons, is a strech for touch typists, requires you to get you hand completely away from the letters for the rest, and god help the hunt and peckers. Something like (3ch|4.5key|2pos|5cm) cost. And I dislike having a THIRD sigil even more than I dislike the second. Adam K I think $ is way more objectionable to the lily-white non-Perl heathens, but I don't really care about them either way. I'm just saying ./ screams file path to me, or maybe even typo-ed Java/C++ comment or something. Certainly not method invocation or implicit invocant. The .: thing, OTOH, totally works for me and I've always liked it. I'm just trying to stretch it to cover both public and private. Maybe there's something better than both.
Re: ./method defunct
On 6/18/05 12:23 AM, Adam Kennedy wrote: The reason we ended up at ./method was simply because it was the best suggestion anyone had. That's what I'm trying to remedy :) It's other advantage is that (except for on nordic keyboards) dot and slash are generally right next to each other, so the expense of using it is two chars and one fingering position, as they would likely be hit by fourth and fifth fingers (for touch typist style) and some other two fingers for the rest of us, and only 1 cm travel for hunt and peck. As I noted, . and : are also right next to each other. Yes, there's a modifier (shift) for one of them, but I didn't see anyone crying when .: was originally proposed, and .:: is just a double-tap on the 2nd key. IMO, the RSI index is basically a wash between .: and ./. The ugliness and appropriateness indexes, OTOH, heavily favor .: and .::, IMO. BTW, I'm still not sure which will be more common, private or public implicit-invocant method calls. I assigned .:: to private because it simply looks more internal to me. And I dislike having a THIRD sigil even more than I dislike the second. Objective-C has some spare characters if you're feeling adventurous :) [.method()] # ha, jk .-method() [EMAIL PROTECTED]() Hm, that last one actually isn't half bad, the mnemonic being call this 'at' the current object...or something. Again, maybe it's not feasible due to parsing constraints. How about resurrecting the spirit of the arrow? .method() That actually looks more private to me. Let's line 'em up again: PUBLIC PRIVATE -- -- ./method() .:method() [EMAIL PROTECTED]() .:method() .method() .:method() .:method() .method() .:method() .::method() I'm just trying to get some more suggestions out there on paper, because it seemed to me that the old thread jumped from ^ to ./ with less exploration than I'd like. -John
Re: ./method defunct
At 7:52 AM -0400 6/18/05, John Siracusa wrote: That actually looks more private to me. Let's line 'em up again: PUBLIC PRIVATE -- -- ./method() .:method() [EMAIL PROTECTED]() .:method() .method() .:method() .:method() .method() .:method() .::method() I'm just trying to get some more suggestions out there on paper, because it seemed to me that the old thread jumped from ^ to ./ with less exploration than I'd like. As I recall, it was decided for a broad scope that public and private item invocation syntax was exactly the same but with the consideration that all private items have a ':' as the first character in their otherwise alphanumeric names (the ':' looks like part of an operator but it isn't). That seems to be getting ignored in this discussion, and I *like* that ':' public vs private consistency, so here's an alteration to your table: PUBLIC PRIVATE -- -- ./method() ./:method() [EMAIL PROTECTED]() .@:method() .method() .:method() This looks way more consistent and predictable to me. -- Darren Duncan
Re: ./method defunct
Darren Duncan skribis 2005-06-18 11:40 (-0700): item invocation syntax was exactly the same but with the consideration that all private items have a ':' as the first character in their otherwise alphanumeric names (the ':' looks like part of an operator but it isn't). Except for attributes, which play a different game: the colon comes *instead* of the dot as the twigil, while the accessor method gets : in front of its name. If I recall correctly, the syntax is very misleading in that it is NOT part of the name. I don't like the inconsistency. PUBLIC PRIVATE -- -- ./method() ./:method() ./:method is what I originally suggested along with my suggestion of ./method itself. I strongly dislike that .:method would work on $?SELF and I also strongly dislike the contrived and false two-\W-characters-mean-invocant-otherwise-it's-$_ rule. (It'd be true (but would still feel artificial) if .+method would also use the invocant. Which I pray is not the case.) I do not want there to be any indication of there being two defaults and that there is a way to select the other default. ./ is an operator by itself and not the combination of . and /, and it cannot be used infix. There is only ever one default variable|object in syntax, and that is $_. I'd like the colon to be part of the name, like underscore is used in Perl 5: outside access is discouraged but entirely possible. I don't think ANY syntax should be special cased for a method, just because it's private. That doesn't mean there can't be a warning (warnings are not syntax), and in fact a warning is all there should IMO be. This means these public-private equivalency pairs exist: $foo.bar $foo.:bar .bar .:bar ./bar ./:bar $.bar $.:bar # I wouldn't mind if $:bar were an *abbreviation* .+bar .+bar ./+bar ./+:bar (People could introduce other prefixes (although the number of available characters is very limited) for other accessability indicators, like perhaps [EMAIL PROTECTED] to allow web access. [EMAIL PROTECTED]() .@:method() In Perl, @ has a VERY strong association with arrays, so except for specialised frameworks, I recommend against using it for other purposes. .method() .:method() I think has just enough purposes, and that it should be left alone now. gt = pair == pipe qw qw +, ~ shift -, - sub Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: ./method defunct
On 6/18/05 2:40 PM, Darren Duncan wrote: As I recall, it was decided for a broad scope that public and private item invocation syntax was exactly the same but with the consideration that all private items have a ':' as the first character in their otherwise alphanumeric names (the ':' looks like part of an operator but it isn't). Doh! If that's the case, then your revised table is indeed the place to start. I'll throw one more on for good measure. PUBLIC PRIVATE -- -- ./method() ./:method() [EMAIL PROTECTED]() .@:method() .method() .:method() .-method() .-:method() I was also thinking about putting something before the . instead of after it. That actually makes more sense as a location for a syntax for an implicit invocant, since the invocant would come before the . too. Unfortunately, a that syntax is used for member variables and such, so the usual sigils are out ($ @ % ), and the rest start to look like unary operators on method calls implicitly made on $_ (e.g., -.method()) So we're back to the table above, I guess. I miss .::method(), but of the above choices I think I'd rank them this way, from best to worst. PUBLIC PRIVATE -- -- [EMAIL PROTECTED]() .@:method() # best .method() .:method() # . .-method() .-:method() # . ./method() ./:method() # worst It was a tough battle for last place, but in the end I think - even is a nicer placeholder for an implicit something. I just can't get over the path-y-ness of ./ (not to mention the division-y-ness) -John
Re: ./method defunct
John Siracusa skribis 2005-06-18 19:55 (-0400): ./method() ./:method() [EMAIL PROTECTED]() .@:method() .method() .:method() .-method() .-:method() [...] ./method() ./:method() # worst Why exactly is the slash not acceptable for you? Almost everyone has said they like it. I personally find ./method prettier and easier to type than any of the alternatives. I was also thinking about putting something before the . instead of after it. That actually makes more sense as a location for a syntax for an implicit invocant, since the invocant would come before the . too. It's not implicit invocant. You're not selecting a second default (the first being $_). The slash does not represent $?SELF. And there is no such thing as $object./method. Instead, see ./ as a whole. I agree that the dot makes it look like .:, .+, .=, but anything without the dot is practically impossible because we're out of characters. ^ is the only single-character possibility. Many people have said to dislike ^method, some have said to like it. And if you're using two characters, ./ is a good one because it's easy to type, good looking and looks familiar (and can thus get a mnemonic, even if the metaphor is far fetched). Unfortunately, a that syntax is used for member variables and such, so the usual sigils are out ($ @ % ), and the rest start to look like unary operators on method calls implicitly made on $_ (e.g., -.method()) -.method should return -5 if .method returns 5. Minus in term position is already taken. Please refer to the available operator characters thread: we have only ^ we can reliably use without shuffling other things around or using whitespace. It was a tough battle for last place, but in the end I think - even is a nicer placeholder for an implicit something. I just can't get over the path-y-ness of ./ (not to mention the division-y-ness) The pathiness was on purpose. In fact, ./pugs inspired it and a metaphor between cwd and $?SELF plays for mnemonic. The divisioniness is something you'll just have to get over. Do you see any division in /\w+/? Or any addition in $foo +| $bar? Or any comparison in =, +, or ? Or any price in $var? Or any percentage in %hash? Or any conjunction in sub? Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: ./method defunct
On 6/18/05 7:54 PM, Juerd wrote: [EMAIL PROTECTED]() .@:method() In Perl, @ has a VERY strong association with arrays, so except for specialised frameworks, I recommend against using it for other purposes. The / character has very strong associations in nearly every programming language with division. In Perl it's also strongly associated with regexes, albeit in pairs. In Unix and URLs, it's associated with file paths. At least @ is vaguely associated with method calls in one existing programming language (Objective-C). .method() .:method() I think has just enough purposes, and that it should be left alone now. gt = pair == pipe qw qw +, ~ shift -, - sub I don't think there's any confusion between .method() and the other uses. In fact, I'd say there's less potential ambiguity about the in .method() than in some of other uses of the character. And that's what's important: ambiguity, not some arbitrary limit on the number of places that a character should be used. Also, in the context of Perl, 's historic usage in as the method caller thingie - in Perl 5 and its Perl 6 usage as the sub thingie - ties to method/function calls much more strongly than /. -John
Re: ./method defunct
John Siracusa skribis 2005-06-18 20:16 (-0400): On 6/18/05 7:54 PM, Juerd wrote: In Perl, @ has a VERY strong association with arrays, so except for specialised frameworks, I recommend against using it for other purposes. The / character has very strong associations in nearly every programming language with division. That is true. But in nearly every single US household and business, the dollar sign has to do with money. We create our own uses for existing characters. Sometimes this is based on something that we can recognise from inside or outside Perl, but almost never is something avoided because it has another meaning in another context. Perl would not be possible if we'd let ourselves be limited by this. In Perl it's also strongly associated with regexes, albeit in pairs. Regexes and other quotelike forms. qw/foo bar/ is very common use. $/ had nothing to do with regexes in Perl5 (in a way, it did have to do with division), but it will in Perl 6. Even though it's not in pairs. In Unix and URLs, it's associated with file paths. Yes. And . in a file path means current working directory. That's about as close to current working invocant as one can get :) At least @ is vaguely associated with method calls in one existing programming language (Objective-C). I don't know objective C. .method() .:method() I think has just enough purposes, and that it should be left alone now. gt = pair == pipe qw qw +, ~ shift -, - sub I don't think there's any confusion between .method() and the other uses. I think there is. There is little point in further arguing over this. Also, in the context of Perl, 's historic usage in as the method caller thingie - in Perl 5 and its Perl 6 usage as the sub thingie - ties to method/function calls much more strongly than /. - in Perl 6 not being related in any way (except spelling) to what - used to do in Perl 5 makes this highly irrelevant. The unix shell and things resembling it will still be in use much fifteen years after today, Perl 5 will not. Perl 6 is much about not letting history get in the way of good things. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: ./method defunct
On 6/18/05 8:11 PM, Juerd wrote: John Siracusa skribis 2005-06-18 19:55 (-0400): ./method() ./:method() [EMAIL PROTECTED]() .@:method() .method() .:method() .-method() .-:method() [...] ./method() ./:method() # worst Why exactly is the slash not acceptable for you? Almost everyone has said they like it. I personally find ./method prettier and easier to type than any of the alternatives. I think it's jarring. It definitely doesn't look like a method call to me. It looks out of place, like a typo of some kind. That was my honest initial reaction, as I posted earlier. I literally didn't even consider that it could be some sort of new syntax--and that's saying a lot considering I was reading p6l. I though GMail had mangled the text while trying to interpret quoting or something. It was a tough battle for last place, but in the end I think - even is a nicer placeholder for an implicit something. I just can't get over the path-y-ness of ./ (not to mention the division-y-ness) The pathiness was on purpose. In fact, ./pugs inspired it and a metaphor between cwd and $?SELF plays for mnemonic. I understand that, but I don't think it's a very applicable analogy. First, I think it's a long bridge from the file/path world to method calls. Second, even ignoring that, ./ in file/path context is a composition of two well-defined primitives, rather than the single unit proposed for Perl 6, the call this on $?SELF operator. (That could also be why I was breaking ./ down into . and / earlier, proposing alternatives for the / part alone.) The divisioniness is something you'll just have to get over. Do you see any division in /\w+/? No, because it's in pairs there (and because of ~12 years of perl 4-5 :) Or any addition in $foo +| $bar? Or any comparison in =, +, or ? Or any price in $var? Or any percentage in %hash? Or any conjunction in sub? I do see a bit of addition in +|. The constructs mostly look arrow-y to me, which is usually the intention (again, except in pairs where it looks bracket-y). Price in $var, well, years of shell combine there with years of perl (not to mention BASIC or whatever :) % and mostly ride on the perl 4-5 wave mentioned above. Anyway, I'm just giving my opinion. At least three other people agree with me, although we do seem to be in the minority so far. I'm just hoping there's an alternative that everyone will like better :) -John
Re: ./method defunct
On 6/18/05 8:28 PM, Juerd wrote: The unix shell and things resembling it will still be in use much fifteen years after today, Perl 5 will not. Ooo, a bold prediction :) -John
Re: ./method defunct
John Siracusa skribis 2005-06-18 20:35 (-0400): On 6/18/05 8:28 PM, Juerd wrote: The unix shell and things resembling it will still be in use much fifteen years after today, Perl 5 will not. Ooo, a bold prediction :) Do you really think so? I think that there is no way that Perl 5 can survive another 15 years. It used to be the best tool for almost everything, but for some purposes there are already better tools. Perl 5 had a long life for a dynamic language, but it's fading quickly. Web monkeys choose PHP now (they wouldn't have if our interpreters were light weight and mod_perl could be more like mod_php), larger systems are more and more written in Ruby and Python, and with PCRE, using regexes for basic string manipulation got easy in dozens of languages. The only things that really keeps Perl 5 alive (sort of) are CPAN and the community. The community is a fragile thing, and CPAN is more and more known as that uncontrolled place where any newbie can upload their templating engine and DBI wrapper. While unixish shells probably won't evolve much further. Microsoft is trying now, but their approach isn't needed in sh-land, because we've used those techniques for ages. The syntax is somewhat awkward, but if that's the only thing, you take it for granted because that keeps things compatible with existing code. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: ./method defunct
John Siracusa skribis 2005-06-18 20:33 (-0400): I literally didn't even consider that it could be some sort of new syntax--and that's saying a lot considering I was reading p6l. You missed a 33 message thread that was referred to many times. Such things happen, I am surprised by new inventions all the time too because I don't read everything that flashes by. Still, if you hadn't missed the thread in question, or if you had read documentation about this, then you wouldn't have been surprised. I'm sure someone who hasn't been paying attention finds [+] or + or even foo bar extremely weird, but that does not influence the design. The simple fact that someone who doesn't read the manual is lost entirely, remains with Perl 6. The divisioniness is something you'll just have to get over. Do you see any division in /\w+/? No, because it's in pairs there (and because of ~12 years of perl 4-5 :) I think the remark in parens is extremely important. Perl is an operator based language. Thinks WILL looks weird if you don't know the language. But it just takes some time. I'm just hoping there's an alternative that everyone will like better As long as I'm part of everyone, that won't happen. I've listed numerous possibilities for myself, and found none that I liked better than ./method. I don't think you can come up with a pretty and easy-to-type and unambiguous ASCII based operator that I haven't considered yet. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: ./method defunct
On Sun, 2005-06-19 at 02:11 +0200, Juerd wrote: Why exactly is the slash not acceptable for you? Almost everyone has said they like it. I find it ugly enough that I plan to name my invocants explicitly. -- c
Re: ./method defunct
On 6/18/05 8:55 PM, Juerd wrote: I'm just hoping there's an alternative that everyone will like better As long as I'm part of everyone, that won't happen. I've listed numerous possibilities for myself, and found none that I liked better than ./method. I don't think you can come up with a pretty and easy-to-type and unambiguous ASCII based operator that I haven't considered yet. I think I'd be just as happy if we found an alternative that everyone but Juerd liked better (just as I'm sure you'd be okay if everyone but me liked ./ the best ;) Anyway, this isn't really a democracy. Who knows what evil syntax lurks in the mind of Larry... (well, other than The Shadow, natch :) -John
Re: ./method defunct
chromatic wrote: I find it ugly enough that I plan to name my invocants explicitly. ...which should be construed as a *feature* of the current syntax. ;-) Damian
Re: ./method defunct
At 1:54 AM +0200 6/19/05, Juerd wrote:
Except for attributes, which play a different game: the colon comes
*instead* of the dot as the twigil, while the accessor method gets : in
front of its name. If I recall correctly, the syntax is very misleading
in that it is NOT part of the name.
I would argue that the same rule applies to attributes and methods
alike; privates of both have ':' as part of their name, and *every*
attribute or method reference, public or private, has a '.'. No
instead here.
So if you just factor out the ':' as being part of a private thing's
name, then all other discussions for syntax can treat public and
private the same way.
This goes for both explicit invocant forms like $obj.attr or
$obj.meth and implicit forms like $.attr or $.meth, where in all
cases 'attr' or 'meth' may or may not contain a leading ':', but it
doesn't matter for the main discussion, except that ':' can't be used
in the trailing edge of the operator.
Its much more consistent that way.
$.bar $.:bar # I wouldn't mind if $:bar were an *abbreviation*
I agree and would accept $:bar *if* it were officially an
abbreviation, as you suggest, just like one can omit the '.' on
things like $foo.[0].{'bar'}; however, the full/longer form should
always be valid syntax.
-- Darren Duncan
Re: ./method defunct
Oops, part of Diamian's quoted text got trimmed accidentally in my last post. It should have looked like this: On 6/17/05 10:42 PM, John Siracusa wrote: [...] I'm not, however, buying Damian's argument here: On 2005-05-15 20:33:19, [EMAIL PROTECTED] (Damian Conway) said: This missing design rationale here is that the colon acts as part of the unary operator: ./unary public-method-call-on-invocant .:unary private-method-call-on-invocant So the rule is: One-character operator -- call on $_ Two-character operator -- call on $?SELF It strikes me as more of a rationalization than a rationale--picking out patterns after the fact, because that's what our brains like to do. [...] -John
Re: ./method defunct
On Jun 17, 2005, at 10:42 PM, John Siracusa wrote: But the truth is that / really does look file-path-y to me, and just plain old ugly. I think at least two other people had similar reactions (Martin Kuehl and Carl Franks). David Storrs, reporting to show solidarity, sir(acusa)! Maybe .:: has even more detractors, I dunno. All I know is that I dislike ./ and I'm trying to come up with an alternative. What say you all? Too many dots in .::? Surely ./ isn't as good as it gets... I'm not fond of .:: because I don't think it's sufficiently visually distinct from .:. I don't have a better suggestion...but that's mostly because I dislike this entire concept of secondary sigils. I already get to have the Perl is line noise! conversation _way_ too often...I don't feel that we need to give the trolls more ammunition. For that matter, I'm a Perl zealot and /I/ think they're ugly and obfuscatory. For what it's all worth, I suppose. --Dks
Re: ./method defunct
On 6/17/05 10:56 PM, David Storrs wrote:
I'm not fond of .:: because I don't think it's sufficiently visually
distinct from .:.
Hm, let's look at it:
method total(...)
{
.::sanity_check();
return .:value_one() + .:value_two();
}
Maybe lined up?
.::internal_value();
.:public_value();
I don't mind it, dots and all. I also think the .:: is quickly identifiable
as thicker than .: even at a glance. YMMV.
I don't have a better suggestion...but that's mostly because I
dislike this entire concept of secondary sigils. I already get to
have the Perl is line noise! conversation _way_ too often...I don't
feel that we need to give the trolls more ammunition.
I think $ is way more objectionable to the lily-white non-Perl heathens, but
I don't really care about them either way. I'm just saying ./ screams file
path to me, or maybe even typo-ed Java/C++ comment or something.
Certainly not method invocation or implicit invocant. The .: thing,
OTOH, totally works for me and I've always liked it. I'm just trying to
stretch it to cover both public and private. Maybe there's something better
than both.
(You know, if I had a nickel for every minute I've spent staring at my
keyboard's key caps while reading the p6 lists over the years...)
-John
