Re: Serializing code
Hi,
Yuval Kogman nothingmuch at woobling.org writes:
On Sat, Aug 20, 2005 at 22:27:56 +, Ingo Blechschmidt wrote:
Not code, but the return value of code.emit
Hm, Str? Or possibly a subtype of Str, allowing:
I would guess an AST, that is, any object, that implements
stringification.
the AST could just be the same PIL reblessed with some new
serialization magic, but I guess for most languages you want to make
a real AST to AST conversion, and only then serialize.
Even better :)
But we should note that some backends don't generate meaningful
ASTs, simply because they don't convert PIL - target language
AST - target language, but PIL - target language directly. I.e.
my $ast = $code.emit(..., :languageFoo);
say keys $ast; # FooCode
say $astFooCode; # ...
my $ast = { 3 + 4 }.emit(..., :languagePIL);
say $ast.pBody.pStmt.pExpr.pLV.pArgs[1].pLit.pVal; # 4
Ah. Normal globals can probably be freezed more or less exactly
like normal lexical variables, I don't see a big problem there.
The question is - should globals be frozen? Or should they
optimistically refer to values on the other side?
I think that
sub hello {
$*DOM.document.write(pHello World!/p);
}
should capture $*DOM in the same sense that a closure matches them,
and the global scope is implicitly the uber-parent lexical scope
type thingy.
Then, once we've unified, we can steal something from C and friends:
$*DOM is external;
sub hello {...} # $*DOM is not serialized, but will be resolved
# by the runtime on the other side
Anybody got ideas on how control is needed, and how it should be
specified?
Hm, I think the $*DOM thing could be solved quite elegantly:
There could be a module JavaScript::Browser or so, which would
export $*DOM. I.e.:
#!/usr/bin/pugs
$*DOM.document.write(...);
# Compile-time error: $*DOM not declared
#!/usr/bin/pugs -BParrot
use JavaScript::Browser $*DOM;
$*DOM.document.write(...);
# error: $*DOM does only work when running in a browser
#!/usr/bin/pugs -CJS
use JavaScript::Browser $*DOM;
$*DOM.document.write(...);
# fine now
This exported $*DOM object could then be a (proxy) object with
appropriate magic -- i.e. die when the current runtime is not
a browser and relay all calls to the respective native JavaScript
objects otherwise.
I think something like $*DOM is exported is too generic,
not sure...
The code itself isn't much a problem, much more problematic
are access to outer lexical variables:
my $a = ...;
my $b = { ...$a... };
$b();
Right... It is my assumption that actually serializing this is
trivial. The real question is whether we want to serialize, and
what parts we would like to serialize when we do.
Hm, probably we should serialize all variables which are not
specifically marked as objects which should not be freezed (e.g.
$*DOM).
--Ingo
--
Linux, the choice of a GNU | There are no answers, only
generation on a dual AMD | cross-references.
Athlon!|
Re: Serializing code
On Sun, Aug 21, 2005 at 12:11:17 +, Ingo Blechschmidt wrote:
Hi,
Yuval Kogman nothingmuch at woobling.org writes:
But we should note that some backends don't generate meaningful
ASTs, simply because they don't convert PIL - target language
AST - target language, but PIL - target language directly. I.e.
my $ast = $code.emit(..., :languageFoo);
say keys $ast; # FooCode
say $astFooCode; # ...
my $ast = { 3 + 4 }.emit(..., :languagePIL);
say $ast.pBody.pStmt.pExpr.pLV.pArgs[1].pLit.pVal; # 4
In that case they just take the PIL tree and rebless it with the
code emitter as the stringifier.
There could be a module JavaScript::Browser or so, which would
export $*DOM. I.e.:
#!/usr/bin/pugs
$*DOM.document.write(...);
# Compile-time error: $*DOM not declared
#!/usr/bin/pugs -BParrot
use JavaScript::Browser $*DOM;
$*DOM.document.write(...);
# error: $*DOM does only work when running in a browser
#!/usr/bin/pugs -CJS
use JavaScript::Browser $*DOM;
$*DOM.document.write(...);
# fine now
This exported $*DOM object could then be a (proxy) object with
appropriate magic -- i.e. die when the current runtime is not
a browser and relay all calls to the respective native JavaScript
objects otherwise.
I think something like $*DOM is exported is too generic,
not sure...
Yes, you're absolutely right.
--
() Yuval Kogman [EMAIL PROTECTED] 0xEBD27418 perl hacker
/\ kung foo master: /me spreads pj3Ar using 0wnage: neeyah!!!
pgpDFO1VuzNuF.pgp
Description: PGP signature
Re: Symbolic dereferentiation of magical variables
On Sat, Aug 20, 2005 at 10:33:03PM +, Ingo Blechschmidt wrote:
: Hi,
:
: S02 says:
: our $a; say $::(a); # works
:
: my $a; say $::(a); # dies, you should use:
: my $a; say $::(MY::a); # works
That looks like somebody's relic of Perl 5 thinking. Personally,
I don't see why the second one should die. I was kind of hoping
that symbolic lookups would include lexicals in Perl 6, unlike in
Perl 5. Then you use MY or OUR to force it one way or the other.
An unqualified lookup should find exactly the same symbol at run-time
that the compiler would find at compile time (though with non-strict
semantics on undeclared globals regardless of lexical strictness,
since the whole point of differentiating $::() notation from ${}
notation is to get rid of use strict refs). Also remember that
leading :: in general doesn't imply main as it does in Perl 5.
: How can I use symbolic dereferentiation to get $?SELF, $?CLASS,
: ::?CLASS, %MY::, etc.?
:
: say $::('$?SELF');# does this work?
Probably not, since the ::() notation doesn't want sigils in the key,
and you have to say
$?::('SELF')
to have any hope of it working. On the other hand
%MY::$?SELF
might get you the symbol out of the symbol table hash, unless $?SELF
is too macro-y for that. $? variables aren't required to have
a dynamically lookupable meaning at run time, since their native
dynamic context is the compiler, not the run-time.
: say $::('MY::$?SELF');# or this?
No, we don't currently allow sigils after ::. But maybe we could have
some quoting mechanism to allow it:
say $::('MY::$?SELF');# or this?
: Also, is $::! valid syntax? (Or am I required to write this as
: $::(!)?)
I suspect :: after a sigil is always a no-op unless it's followed by
parens (and maybe , if we allow sigil lowering, which would also
give us:
$OUTER::OUTER::$_
and such.) I think I like the option lowering the sigil to the key.
Maybe the outer sigil is meaningless in that case, and it's just
OUTER::OUTER::$_
But if we say that any package/type name can tagmemically function
as a hash if you use like one, then the last :: can go too:
OUTER::OUTER$_
OUTER::OUTER{'$_'}
Though we're getting close to confusing this notation with
%OUTER::OUTER::{'$_'}
which looks similar, but (if we take the Perl 5 meaning) doesn't
do :: splitting on the key. In other words, this would also get
to OUTER::OUTER$_:
OUTER{'$OUTER::_'}
because it's accessing through the package as a hash and does further
:: breakdown. But this wouldn't work:
%OUTER::{'$OUTER::_'}
because it's accessing through the actual symbol table hash, which doesn't
have any such symbol as one of its keys.
That's an awfully subtle distinction, though. I think OUTER::OUTER's
symbol table hash needs a better name than %OUTER::OUTER. Maybe it's
named OUTER::OUTER%OUR or OUTER::OUTER::%MY or some such.
Which makes me think that Perl 5's %FOO::{'name'} symbol table
notation is really bogus, because %OUTER:: doesn't really refer to a
single symbol table in Perl 6, but the starting place for a symbol
search that may span several symbol tables. At least, that's how
I've been thinking of it. Maybe we nail OUTER down to one MY and
just use OUTER.findsym('$x') if that's what we mean. But then we
get bad interactions if someone says
FOO.findsym('$x')
on a class that defines its own findsym method. Or maybe that's
a feature. Or maybe only pseudo classes that resolve to MY variants
have a findsym method. ENOCAFFEINE.
Larry
*%overflow
Output?
sub foo (+$a, *%overflow) {
say %overflow{};
}
foo(:a(1), :b(2)); # b2
foo(:a(1), :overflow{ b = 2 }); # b2
foo(:a(1), :overflow{ b = 2 }, :c(3)); # ???
Luke
Re: *%overflow
Hi,
Luke Palmer wrote:
sub foo (+$a, *%overflow) {
say %overflow{};
}
foo(:a(1), :b(2)); # b2
foo(:a(1), :overflow{ b = 2 }); # b2
I'd think so, too.
foo(:a(1), :overflow{ b = 2 }, :c(3)); # ???
Error: Too many arguments passed to foo?
Presuming that multiple *%slurpy_hashes are allowed, I'd say that...
sub bar (+$a, *%overflow, *%real_overflow) {
say [%overflow{}] [%real_overflow{}];
}
bar(:a(1), :overflow{ b = 2 }); # [b2] []
bar(:a(1), :overflow{ b = 2 }, :c(3)); # [b2] [c3]
But it seems to be cleaner to disallow multiply *%slurpies and just go
with the error.
--Ingo
--
Linux, the choice of a GNU | The future is here. It's just not widely
generation on a dual AMD | distributed yet. -- William Gibson
Athlon!|
Re: *%overflow
On 22/08/05, Luke Palmer [EMAIL PROTECTED] wrote:
Output?
sub foo (+$a, *%overflow) {
say %overflow{};
}
foo(:a(1), :b(2)); # b2
foo(:a(1), :overflow{ b = 2 }); # b2
I would have thought:
overflow b 2
i.e. %overflowoverflow = (b = 2)
Because :overflow() is an unrecognised named argument, so it goes in the slurpy
hash. The fact that the hash has the same name as the argument is a
coincidence--does it make sense to explicitly name a slurpy when you can just
splat *{ b = 2 } in directly?
foo(:a(1), :overflow{ b = 2 }, :c(3)); # ???
overflow b 2
c 3
Of course, that's just my way of thinking.
(Also, last I heard you /could/ have multiple slurpy hashes, but any after the
first would always be empty.)
Stuart
Re: Demagicalizing pairs
On Fri, Aug 19, 2005 at 06:42:04PM +0300, Yuval Kogman wrote: If there is some really odd code signature which takes in a mess, I may want to intermix positionals and named's in order to increase readability. AFAIR, named parameter syntax will work for positionals as well[*]. So even if you want to intermix the positional parameters with named, there's no need for us to support intermixing positional parameter *syntax* with named...? /me relurks -- Chip Salzenberg [EMAIL PROTECTED]
