Re: Multidimensional hyper
On Fri, Aug 19, 2005 at 21:29:11 -0700, Larry Wall wrote: Basically, unaries don't have to worry about reconciling different shapes. They just recurse as much as is reasonable, whatever that is. Possible exact semantics of reasonable: hyper recurses at least one level, and then tries to match the type of the hyper'ed function on each element. If the type does not match, more attempts are made at recursion. If at any point the shapes of the current node is different from it's corresponding node in the other structure, then a binary function is applied regardless of type (resulting in coercion or a fatal error). -- () Yuval Kogman [EMAIL PROTECTED] 0xEBD27418 perl hacker /\ kung foo master: /me does not drink tibetian laxative tea: neeyah! pgpZh5buBST12.pgp Description: PGP signature
Re: Disappearing code
On Thu, 09 Jan 2003 21:12:07 -0500, John Siracusa
[EMAIL PROTECTED] wrote:
[...]
Hey, it adds up! Okay, maybe it doesn't...but still, Perl 6 Should Be Able
To Do This! :) And I'd also like inline constructs like:
ASSERT $foo 5 is_happy(blah);
macro debug ($code) is parsed (/{Perl6::Block}/) {
if ($debug) {
$code
} else {
}
}
--
Please excuse my spelling as I suffer from agraphia. See
http://dformosa.zeta.org.au/~dformosa/Spelling.html to find out more.
Free the Memes.
Re: Multidimensional hyper
On Sat, Aug 20, 2005 at 12:27:23PM +0300, Yuval Kogman wrote:
: On Fri, Aug 19, 2005 at 21:29:11 -0700, Larry Wall wrote:
:
: Basically, unaries don't have to worry about reconciling different shapes.
: They just recurse as much as is reasonable, whatever that is.
:
: Possible exact semantics of reasonable:
:
: hyper recurses at least one level, and then tries to match the
: type of the hyper'ed function on each element. If the type does
: not match, more attempts are made at recursion.
Depends on what you mean by match the type. By one definition, an
array matches the type of +, so it should just hyper on the length of the
array, which is not what people are going to want generally. I think you
have to try to recurse first.
: If at any point the shapes of the current node is different from
: it's corresponding node in the other structure, then a binary
: function is applied regardless of type (resulting in coercion or
: a fatal error).
That doesn't do dimension extension of scalars. We want this to work
1 + [1,2,3]
at any level in the hyper, but by the definition above it would add
1 to the length of [1,2,3]. Perhaps there's a Hyper role that says
whether a container can hyper, or defines a function that returns
some kind of hyper conformability type, so that scalars, arrays, and
hashes can be recognized, and maybe other types added. I guess what
we're saying is that hyper does a mapping from named type to a general
structural type and then does MMD on the structural types.
Or maybe we just treat Item, Array, and Hash roles as structural
types, and let people add other MMDs if they want hyperdispatch to
other structural types. Though this is getting dangerously close to
letting people change the parallel semantics of hyper for individual
named types, which is something I want to discourage, if not disallow
outright. So I'm inclined to make named types pick one of the Big
Three to behave as before hyper ever sees them.
Though there could be a pecking order. For instance, a match object
can do both the Array and Hash roles. For hyper, it first tries to be
an Array, then a Hash. If it's matched up against an Item or an Array,
it does Array. If it's matched up against another Hash, it does Hash.
For now, I think we can just hardwire the analysis in terms of does:
given $obj {
when Array { participate_as_array() }
when Hash { participate_as_hash() }
default { participate_as_item() }
}
or maybe it's
given $obj {
when Ordered { participate_as_list() }
when Hash { participate_as_hash() }
default { participate_as_item() }
}
to admit un-indexable lists.
Larry
Re: Serializing code
Hi,
Yuval Kogman nothingmuch at woobling.org writes:
On Thu, Aug 18, 2005 at 12:24:40 +, Ingo Blechschmidt wrote:
Yuval Kogman nothingmuch at woobling.org writes:
So now that the skeptics can see why this is important, on the
design side I'd like to ask for ideas on how the code serialization
looks...
sub { $?DOM.document.write(phello world!/p) }.emit(
:runtime($browser_autodetect_object),
# this can be guessed by asking the $runtime object:
# :languagejavascript,
);
This is superficially nice,
Indeed!
but here's what's missing:
[...]
- what exactly is a code object?
- a wrapper for some PIL code
- that can be executed by the runtime
Code objects may as well be executed at compile-time
(think macros, use and BEGIN blocks), but...:
But it's still the runtime that runs them
Compilation has a runtime that runs the compiler, and compile-time
code. The output may be handed down to another runtime that actually
runs.
Oh, right, of course. I misread that.
Well, you call code.emit above, so it's probably a Code
object, even though it calls subs and methods from the
Perl6::Internals namespace (or somesuch).
Not code, but the return value of code.emit
Hm, Str? Or possibly a subtype of Str, allowing:
$template.param(globaljs)= $emitted.global_section;
$template.param(js_of_a_div) = $emitted.main_section;
Of course, these additional methods wouldn't be available for
all backends.
- handling of data
- types of:
- globals?
I've probably misunderstood you, but can't globals, like all
other variables, have any type you want them to have?
Not types in the kind of value type... Read it as:
handling of data... what types of data... global variables are
types of data
Ah. Normal globals can probably be freezed more or less exactly
like normal lexical variables, I don't see a big problem there.
WRT pads: Luckily, pads are constant, i.e. you can't inject
a new lexical variable at runtime (%MY::new_var = ...).
The backend does have to take care of read accesses, of course
(think $CALLER::, $::(...), %MY::, %OUR::, etc.).
FYI, this is how PIL2JS handles this currently:
my $foo; # is really
my $foo; %MY::foo := $foo;
sub foo {...}; # is really
sub foo {
my %MY:: = ();
push @*CURRENT_SUBPADS, %MY::;
LEAVE { pop @*CURRENT_SUBPADS };
...;
}
- closures?
A subclass of Code, e.g. Bare.
How are they stored?
The code itself isn't much a problem, much more problematic
are access to outer lexical variables:
my $a = ...;
my $b = { ...$a... };
$b();
A backend can then either use the native closure support of the
runtime it targets (if existing) or it has to lambda lift, i.e.
my $b = { ...$a... }; # is really
my $b = - $a { ...$a... };
$b(); # is really
$b($a);
I'd like to have a pragma to switch between these policies.
I doubt a pragma is enough - we need full introspection and fine
grained control for this, both in the lexical and the dynamic
scopes.
Even better! :)
--Ingo
--
Linux, the choice of a GNU | The computer revolution is over. The
generation on a dual AMD | computers won. -- Eduard Bloch
Athlon!|
Symbolic dereferentiation of magical variables
Hi,
S02 says:
our $a; say $::(a); # works
my $a; say $::(a); # dies, you should use:
my $a; say $::(MY::a); # works
How can I use symbolic dereferentiation to get $?SELF, $?CLASS,
::?CLASS, %MY::, etc.?
say $::('$?SELF');# does this work?
say $::('MY::$?SELF');# or this?
Also, is $::! valid syntax? (Or am I required to write this as
$::(!)?)
--Ingo
--
Linux, the choice of a GNU | self-reference, n. - See self-reference
generation on a dual AMD |
Athlon!|
Re: Serializing code
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.
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?
The backend does have to take care of read accesses, of course
(think $CALLER::, $::(...), %MY::, %OUR::, etc.).
That's just the pads of the lexical structure and the dynamic stack,
and they're existence is implied by PIL. Adding the interface is
easy if the implementation isn't drunk, since things will tend to
just work out.
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.
--
() Yuval Kogman [EMAIL PROTECTED] 0xEBD27418 perl hacker
/\ kung foo master: /me sushi-spin-kicks : neeyah
pgpi2FAoBtqax.pgp
Description: PGP signature
