{Pre-Post-Script: After all this trouble below, which is hairy and yet
not even complete, parameter-by-parameter conversion is actually
starting to look good for complex cases. Despite all my reasons
against it. I start to suspect that we need both; that get_params
can be used for cases that are quite simple, and get_param [one at a
time] can be introduced for more complex cases.}
Currently, @MULTI declares metadata that are attached to the Sub
structure, while get_params claims to be an executable opcode but
that's a deception -- since Parrot is cheating by looking for the
opcode and saving a pointer to it, it's really metadata that just
takes the form of an opcode. Since we're going to need type
validation for all parameters, not just invocant(s), it makes no sense
to embed any type information in an invocant-specific construct like
@MULTI.
So all the information currently in these places, plus more, should be
collected into a single construct that is explicitly metadata. Most
of the difficulty of the Perl6 syntax is related to the complex ways
to specify a type. At the Parrot level, we can assume that complex
types will be constructed with artificial names, so all we have left
to see is the parameter, its type, the register to put it in, and the
flags that we've started defining. The ".param" pseudo-op is headed
in the right direction, for example; we just need more info.
.sub __add
.param MyType $P0 :flags(0x40) # or @flags(0x40)? - inv. w/o colon
(e.g.)
.param $I0 :flags(0x20) # invocant with colon (e.g.)
As for default values: That's tough. Optional P parameters can be
left as null when they're missing. In addition, we'll probably need
to keep a bit mask of parameter-present flags which can be queried.
(Alternatively we could have a word pointing to a label which contains
code that will initialize the given parameter when it's missing. But
that's pretty ugly, and probably doesn't save us much.)
Named parameters will need an extra word for each feature to hold the
string contant containing the string name. Looks like we're even
going to be variable length represenation per-parameter.
What do you think?
--
Chip Salzenberg <[EMAIL PROTECTED]>
