Patrick R. Michaud wrote:
Just a few comments from a brief review of pdd19:
=item 'char constant'
Are delimited by single-quotes (C<'>). They are taken to be ASCII encoded. No
escape sequences are processed.
What exactly does "They are taken to be ASCII encoded" mean here?
For example, what happens if I write a statement like...?
say '«hello»'
The original documentation says C<ascii> (the 7-bit charset), but the
encoding is 8-bit (C<fixed_8>). So that string works now.
The only inconsistency is that double quoted strings have the same
defaults (C<ascii> and C<fixed_8>), but currently throw a "Malformed
string" exception with anything that isn't 7-bit ASCII. Specifying
$S0 = iso-8859-1:"«hello»"
works, while specifying:
$S0 = ascii:"«hello»"
Throws the same exception as double-quoted strings.
So, for consistency, I'd say single quoted strings should have the same
exception.
=item .lex <identifier>, <reg>
Declare a lexical variable that is an alias for a PMC register. The
PIR compiler calls this method in response to a .lex STRING, PREG
directive. For example, given this preamble:
The part about "The PIR compiler calls this method ..." is ambiguous
here -- what method is "this method"? I think the second sentence can
be eliminated altogether (I suspect it was just copy+pasted from the
lexicals PDD).
Done.
=item .HLL "<hll_name>", "<hll_lib>"
[...]
=item .HLL_map '<CoreType>', '<UserType>'
Are the double-quotes and single-quotes part of the syntax specification --
i.e., are double-quotes required with .HLL while single-quotes
are required with .HLL_map ?
Not significant.
More directly, is a PIR program allowed to use any string
constant specification for these directives, or is it limited
limited to bare double-quote strings for .HLL and single-quoted
strings for .HLL_map ?
Yes, any string constant is valid. Text clarified.
=item .return <var> [:<flag> ...]
Between C<.begin_return> and C<.end_return>, specify one or
more of the return value(s) of the current subroutine. Available
flags: C<:flat>, C<:named>.
This is probably not the C<.return> the typical PIR programmer
will be looking for. IMO, the C<.return> directives that are
documented along with C<.param> are the ones that are normally
used in PIR -- i.e., the ones that allow for multiple values to
be returned to the caller or that specify tailcalls.
In general to aid understanding and readability, I think that
all of the PASM-oriented directives (.emit, .eom, .begin_*, .end_*,
and this particular use of .return) ought to go in a section separate
from and after all the "normal" PIR directives and syntactic sugar have
been covered.
Perhaps we should change the name of the .return that's paired with
.begin_return and .end_return. Like .arg_return. The other .return is
syntactic sugar for the whole combination.
I've reordered the entries to make it clearer.
=item <var> = new '<type>'
...
=item <var1> = new '<type>', <var2>
...
=item <var1> = defined <var2>
...
=item <var1> = defined <var2> [ <var3> ]
...
=item <var1> = clone <var2>
...
=item <var> = addr <identifier>
...
=item <var> = null
Are these in fact specially-defined syntactic sugar in PIR,
or are they simply instances of the more generic
<var> = <opcode> <param>
that is automatically translated into
<opcode> <var>, <param>
If they're specially-defined syntactic sugar, then why? If not,
then why are these particular examples in the PIR documentation
where others are not mentioned?
They're just the ordinary syntactic sugar. I've edited these down to one
entry.
Allison
