On Sat, Jul 09, 2005 at 11:34:23PM +0800, Autrijus Tang wrote:
: In Pugs's ext/Set/lib/Set.pm, there are a number of user-defined
: infix operators. To avoid unicode in mails, I'll use a hypothetical
: &infix:<===> as the operator name.
We've intentionally been using Unicode in this mailing list on the
assumption that people will learn to deal with it one way or another if
they have to, and will otherwise put it off as long as possible. :-)
: Consider the sub case:
:
: class Set;
: sub infix:<===> (Set $x, Set $y) { ... }
:
: Is it correct that this line:
:
: Set.new === Set.new
:
: Only works when the &infix:<===> function is in scope? That is, one
: would need to add `is export` to its declaration for the user of the
: Set module to access to this operator.
A6 discusses this to some extent. We need to distinguish the function
from its syntax. A function or method, even if it has a funny name
like infix:<===>, is just an ordinary function or method, and can
exist in any scope that any other function or method can exist in.
As such, it can be subject either to early binding or late binding,
just as any other function or method can.
However, anything which implies a change in syntax must, by definition,
be bound as early as possible, but no earlier. In particular, Perl 6
mandates that all syntax change be lexically scoped. So the *syntax* of
anything macro-like is propagated only by export, and has a syntactic
effect only if imported lexically, or more precisely, when bound into
a lexical scope at compile time. Everything from user-defined syntactic
categories to wholesale Perl grammer rule overrides falls into this
category of macro-like entities.
: Does the same holds for `multi sub` as well?
Yes, at least one of the multi-subs in question must export its syntax
to your lexical scope (or be predefined by Perl). It is not necessary
for all of them to export to your scope, since as soon as you've installed
infix:<===>, you have a way to call all of them.
: What if this is expressed as a method:
:
: class Set;
: method infix:<===> (Set $y) { ... }
:
: Does it also need `is export`? If not, how does the parser know that
: the === is a valid operator name, without the ability to deduce the type
: of its left hand side object? If yes, does it simply fail at runtime
: if the left hand side has no infix:<===> defined? Exporting a method
: is a novel concept to me, too.
You aren't exporting the method. You're exporting the call syntax
that remaps A === B into infix:<===>(A, B). That's going to use MMD
by default, but that includes ordinary methods in its calculations.
I suppose it would be possible to allow the exported syntax to instead
map A === B into A.infix:<===>(B), but I'm told SMD is for weenies. :-)
Nevertheless, if someone writes that, SMD is probably what they expect.
There are a couple of unanswered questions here you haven't asked yet.
First, how do builtins get installed, and can I influence the parsing
of a module I'm about to use by installing some syntax into * first.
That is, does a compilation clone * for its initial grammar when
it starts up? I think that's a little too dangerous as it stands.
It should take a little more effort to mess with the minds of
unsuspecting modules, so maybe the standard syntax is cloned out of
*STANDARD_PERL_6 or some such scary package name. It's the default for
starting all require-like Perl 6 parses. By default, eval() should
start in the current grammar, but there needs to be a p6eval that
starts in the standard grammar, and hopefully for the translator,
a p5eval that parses in Perl 5 by default, at least until it sees a
v6; or some such. (Or maybe it's just an option on eval, which would
let us even specify the version we were hoping to emulate.)
Another question is whether some or all of the syntax declarations
should be exported by default, in the absence of an explicit
"is export". And if so, what is the default export tag? I suspect
most such syntax will be defined with the intention of exporting it.
On the other hand, there may well be some people who will prefer
never to import syntax except explicitly. We want to serve both
needs expeditiously. I think any macro, foo: category, or grammar mod
automatically exports with "is export<SYNTAX>" or some such (unless
you override it), and that is considered a subset of the DEFAULT tag.
However, there needs to be some setting on the "use" end that kicks
SYNTAX out of DEFAULT for the current use. Not sure what that would
be.
no syntax;
use use :SYNTAX(0);
$?USE_SYNTAX ::= 0;
[your ad here]
Larry
