=>'s autoquoted identifiers
Joshua Choi
still "autoquotes" its first arguement if it's bare, a la barewords.
Synopsis 1 says:
But => still autoquotes any bare identifier to its immediate left
(horizontal whitespace allowed but not comments). The identifier is
not subject to keyword or even macro interpretation. If you say:
$x = do {
call_something();
if => 1;
}
then $x ends up containing the pair ("if" => 1). Always. (Unlike in
Perl 5, where version numbers didn't autoquote.)
[end quote]
But what does that mean for =>'s signature? What type would be its
first parameter? Would you call it "&infix:{'=>'}:(Bareword | Any,
Any)" or something like that? And in any case, would you be able to
use this autoquoting in or as a sub, operator, type, etc.?
Thanks,
Joshua Choi
Luke Palmer
> But what does that mean for =>'s signature? What type would be its
> first parameter? Would you call it "&infix:{'=>'}:(Bareword | Any,
> Any)" or something like that? And in any case, would you be able to
> use this autoquoting in or as a sub, operator, type, etc.?
I think => gets special treatment from the parser; i.e. it is
undeclarable. It's probably not even declarable as a macro, since it
needs to look behind itself for what to quote.
And I think this is okay. For some reason, we are not satisfied if
"if" is undeclarable, but => being so is fine. I can't put my finger
on why I feel this way, though.
Luke
TSa
Luke Palmer wrote:
> I think => gets special treatment from the parser; i.e. it is
> undeclarable. It's probably not even declarable as a macro, since it
> needs to look behind itself for what to quote.
>
> And I think this is okay. For some reason, we are not satisfied if
> "if" is undeclarable, but => being so is fine. I can't put my finger
> on why I feel this way, though.
The 'operator orientation' of Perl to me dictates that the core
where the recognition process---be it machine or human---starts
is non-alphanumeric. Named functionality are derived concepts in this
respect. The sigils fall into the same atomicity category as the
key part of pairs that link a compile time name to a varying value
at runtime as well.
I hope all these are now the same:
foo => bar ; # result of evaluating bar available under foo key
:foo( bar );
:foo bar ; # does that exist?
In a certain way these are inner pairs where the label syntax is an
outer pair
foo: bar; # perhaps also written as: foo --> bar
that names the landing pat for the bar evaluation. The question to me
is, where the symbol foo is inserted into. E.g. if it were available
in the innermost syntactical scope---this email---the following
$x = foo;
would unequivocally mean to copy a pre-calculated value into $x. In the
end this makes => a detachable *postfix* sigil! The only thing that
surpasses such a thing is an attached prefix sigil, right? Thus
$foo => bar;
links the variadic key of $foo to an eager bar evaluation right there.
Here my thought stream reaches a branch point :)
$foo => *bar; # lazy value or global symbol or both?
and as we know, not even the one can see past such choices!
I can argue it both ways with a slight preference for global symbol
because the lazy evaluation could be written as
$foo => {bar}; # circumfix anonymous closure,
$foo => &bar; # ref to not yet called code invocation
or
$foo => * bar; # detached unary prefix.
These lead me to the question: which evironment is captured in each
of these cases? And what is the latest on the twigil cases?
:$ $: # void name
:foo$ $foo: # infix name
:$foo $:foo # postfix name
:foo$bar $foo:bar # postcircumfix names
And similarly with ^$ and $^
--
Larry Wall
: On 11/17/05, Joshua Choi <rbys...@gmail.com> wrote:
: > But what does that mean for =>'s signature? What type would be its
: > first parameter? Would you call it "&infix:{'=>'}:(Bareword | Any,
: > Any)" or something like that? And in any case, would you be able to
: > use this autoquoting in or as a sub, operator, type, etc.?
:
: I think => gets special treatment from the parser; i.e. it is
: undeclarable. It's probably not even declarable as a macro, since it
: needs to look behind itself for what to quote.
Yes, it's basically a lookahead on the rule that parses a bare identifier,
that is, one that is not "forced" by something to its left like $ or "sub".
: And I think this is okay. For some reason, we are not satisfied if
: "if" is undeclarable, but => being so is fine. I can't put my finger
: on why I feel this way, though.
How do you declare '.' in Lisp? :-)
Larry
Larry Wall
: I hope all these are now the same:
:
: foo => bar ; # result of evaluating bar available under foo key
: :foo( bar );
: :foo bar ; # does that exist?
No. :foo with trailing whitespace is taken to mean :foo(1), so the
"bar" would be parsed with the expectation that it's an operator,
not a term. And much though certain people might like one, I don't
think there's currently a "bar" operator in Perl.
Larry