On Thu, Jul 07, 2005 at 06:37:58PM +0800, Autrijus Tang wrote:
: * Non-source-filter-ish macros work on the PIL(AST) level, not on parse tree
: level. The AST should preserve enough information to derive the original
: parse tree and source code back, for the compiler to use.
It's not clear to me why we shouldn't *also* have parse-tree level that is
taken to be consistent with whatever the current language is, as long
as we retain enough information to deparse it into the current language,
or to compile down to PIL.
: * The "Hash", "Int", "Str" etc are just roles:
: role Hash[?::returns=Any, ?::shape=Str] {
: }
: implementation classes are known as "PerlHash", "PerlInt" etc.
I thought part of the reason for allowing roles to act as classes via
an anonymous class is to allow both the role and the class in question
to be referred to via name "Hash".
: * Filehandles opens chomped by default; you need to add the `:unchomped` flag
: to turn off chumping.
s/unchomped/newlines/
: my $fh = open 'file'; # autochomp
: my $fh = open 'file', :newlines; # non-autochomp
: $fh.newline = '\r'; # now split on \r
: $str = $fh.readline;
: $str.newline; # \r
:
: for chomp =$fh { ... }
:
though perhaps it would be less confusing with :newline if we renamed
:unchomped to :savenl instead. Or maybe change 'newline' to 'nl'.
In that case, we have to differentiate them a little better than with
just a trailing 's', since open can take either of them. I think I
vote for :newlines and :nl("\r"). (Along with .newlines as boolean
and .nl as string/rule attributes on the handle, and a .nl string/match
attribute on the input string.)
: If .newline is a rule, then its captured variables are made available to the
: calling block as if it has done a matching.
More precisely, If $fh.nl is a rule, then $str = =$fh sets $/. The match
object is also returned as $str.nl.
: * `&prefix:<int>` now always mean the same thing as `&int`. In the symbol
table
: it's all stored in the "prefix" category; &int is just a short name way for
: looking it up -- it's just sugar, so you can't rebind it differently.
Might end up actually storing the short form of those and inferring the
'prefix' as needed. Dunno.
: * Constrained types in MMD position, as well as value-based MMDs, are _not_
: resolved in the type-distance phase, but compile into a huge given/when
: loop that accepts the first alternative. So this:
:
: multi sub foo (3) { ... }
: multi sub foo (2..10) { ... }
:
: really means:
:
: multi sub foo ($x where { $_ ~~ 3 }) { ... }
: multi sub foo ($x where { $_ ~~ 2..10 }) { ... }
:
: which compiles two different long names:
:
: # use introspection to get the constraints
: &foo<ANONTYPE_1>
: &foo<ANONTYPE_2>
:
: which really means this, which occurs after the type-based MMD tiebreaking
: phase:
:
: given $x {
: when 3 { &foo<ANONTYPE_1>.goto }
: when 2..10 { &foo<ANONTYPE_2>.goto }
: }
:
: in the type-based phase, any duplicates in MMD is rejected as ambiguous; but
: in the value-based phase, the first conforming one wins.
See subsequent discussion, including the part that hasn't happened yet. :-)
Larry
