caller with no sub scope
In Perl 5, caller EXPR returns undef if the caller is top-level code. If
you need it, you can still get file, line, and package information
(this last is important for import subs) by using caller with the
EXPR-less form.
How do you do that in Perl 6? I'd been working with this presumed
signature:
multi sub caller (Class ?$kind = Any, Int +$skip = 0, Str +$label)
returns Control::Caller is primitive is export is safe { ... }
And an implementation which *always* expected a VCode frame (to check
$kind against). Obviously, this leaves no way to peek at frames with no
?SUB, i.e., the top level.
The hacky way to solve this is to stipulate that kind=Any actually
means something so general that it matches things that are not VCode
at all. The cleaner way in terms of formalism is to allow $kind to be
undef (actually, *default* to it), in which case it functions as that
wider-than-Any qualifier.
I'd go with the second way, since I think it leaves us with DWIMmy
usage. This will start working, which is good:
sub import() { # (do we still have that?)
die I'm not speaking with you! if caller().package ~~ Rival;
...
}
Anyone spot any problems?
--
Gaal Yahas [EMAIL PROTECTED]
http://gaal.livejournal.com/
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: (OT) Re: Perl development server
Vadim Konovalov wrote: Icelandic: laukur (Incidentally, none of you will ever guess how to correctly pronounce that.) Russian: luk (pronounced similar to English look). For some reason, Icelandic translation of onion is much closer to Russian than any other variants... The English leek is another cognate (as a word, of the laukr; as a plant, of the onion)...
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
