On Fri, Apr 29, 2005 at 10:57:01AM -0500, David Christensen wrote:
: 1) What type of introspection, if any, are we providing to the language
: level? I.e., are we providing something along the lines of
:
: %traits = &?BLOCK.traits
:
: where %traits is keyed on trait name (FIRST, LAST, whatever) and in
: turn is an array of closures? This would mean, for instance that we
: could say
:
: &?BLOCK.traits<FIRST>
:
: to get the current block's FIRST closures, if any.
There is no .traits method. Traits store their values into properties,
and properties are just mixins, and you get at the properties by calling
methods. These particular traits push onto a correspondingly named
property, so you're probably looking for
$?BLOCK.firstlist
or some such.
: When parsing the
: block for traits, coming across a new FIRST block would be akin to
: saying:
:
: push &?BLOCK.traits<FIRST>, {...block contents...}
:
: Specifically, I'm looking for definition of the syntax, which is only
: alluded to in the Synopsis.
Probably does something like:
&?BLOCK does First; # no-op if it already does First
&?BLOCK.firstlist.push(&block);
: 2) If we accept the introspection at the block-level above, it seems
: clear that we should also accept the same .traits method on variables.
: I.e., in the above DBI example, we should get back the closure(s) for
: undoing by referring to $sth.traits<UNDO>. Is a variable-level trait a
: single entry, or can we have multiple "will undo {...}" predicates on a
: single variable? (The utility of such is left as an exercise to the
: reader.)
The variable might not be aware that it has had such a trait applied
to it. Remember that traits are allowed to cheat. These traits need
only arrange to have &block pushed onto the appropriate list after the
corresponding variable is successfully elaborated at run time, or otherwise
arrange not to run if their variable is not yet elaborated. If this
information also shows up as metadata on the variable, that's probably
okay, but the implementation is unlikely to use that property directly.
Of course, a trait like "constant" would be expected to an effect on
the variable itself.
: 3) User-definable traits. Now, this may be a closed domain of sorts,
: but do we need to allow for the possibility of user-defined traits?
: (I'm thinking here of variable-level "will" predicates.) If so, do
: user-defined traits get normalized to UPPER? It would seem like we
: would want consistency here, because if "will undo {...}" and "UNDO
: {...}" get stored in the same trait slot, we're obviously transforming
: one of the identifiers -- should this behavior be specific to our
: "built-in" ones, or to all traits?
Already specced in A12. As far as I know that part hasn't changed
significantly, but that could be because nobody's tried to implement
it yet. :-)
: 4) Which of the closure traits are supported as "will" predicates on
: variables? Not all of the closure traits make sense on the
: variable-level -- this information will be useful when trying to parse
: the "will" predicates.
As Luke mentioned, "will" is just syntactic sugar for "is". A trait
is allowed to care about its semantics at compile time when you call
the trait handler, but this is totally transparent to the parser,
which will happily accept "will qufklzuxfvklj {...}", turn it into
"is qufklzuxfvklj({...})", and then fail to find an appropriate trait
handler in semantic analysis, or find some default trait handler that
scratches its head over "qufklzuxfvklj" before admitting defeat.
Or it may be that any trait that is unrecognized just gets applied as
a property of the variable. But I think it's better if we treat
traits as declared items so that we catch typos, unless someone has
explicitly declared a autoloading trait handler.
Larry
