Re: ='s autoquoted identifiers
HaloO,
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 );
:foobar ; # 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 $^
--
Re: ='s autoquoted identifiers
On Thu, Nov 17, 2005 at 10:05:55PM -0700, Luke Palmer wrote:
: On 11/17/05, Joshua Choi [EMAIL PROTECTED] 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
Re: ='s autoquoted identifiers
On Fri, Nov 18, 2005 at 12:12:02PM +0100, TSa wrote: : I hope all these are now the same: : : foo = bar ; # result of evaluating bar available under foo key : :foo( bar ); : :foobar ; # 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
Re: ='s autoquoted identifiers
On 11/17/05, Joshua Choi [EMAIL PROTECTED] 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.
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
