On 9/12/05, Yuval Kogman <[EMAIL PROTECTED]> wrote:
> Hi,
Hi. These are superficial thoughts, before I've had time to really
think about the Big Picture.
> 2. each block of code has a cryptographic digest, which is the hash
> of it's body with the digests of all the functions it calls.
> This digest is stable regardless of optimization semantics, and
> is applied to the PIL structure.
Okay, a little clarification needed here. Is the digest of the code
itself a collection of digests, one for the lexical body, and one for
each funciton it calls (1)? Or is it a hash that combines all of
those somehow?
How do you deal with recursive/mutually recursive functions? (I'm
pretty sure there's a way, I just can't think of it)
What about "temp &foo = sub {...}" ?
> 5. Functions have a notion of equivelence. This is managed based on
> the digest. For example
>
> my &c_int_mul = BEGIN { Code::Foreign.new(:language<C>,
> :body("
> int foo (int x, int y) { return x * y }
> ") };
>
> multi &infix:<*> (int $x, int $y --> int) {
> [+] $x xx $y;
> }
>
> my $str = &infix:<*><int, int --> int>.digest; # must specify
> the variant
You mean:
my $str = &infix:<*>:(int, int --> int).digest;
Also, you said that the digest contains the digests of all called
functions. How do you deal with multis there, which may depend on the
runtime types?
> &c_int_mul.set_equiv($str); # could be in another file
>
> # or, if they are maintained together
>
> &c_int_mul.set_equiv(&infix:<*><int, int --> int>);
>
> This equivelence is with respect to the semantics of the input
> and output. The test suite supposedly can assure that these are
> really equivelent by running the same tests against either
> version.
Okay, good. So you have a way of marking that two functions do the
same thing, without having the program try to figure that out (which
is impossible). That's something that Haskell didn't figure out :-)
I suppose it would be nice to have subtype semantics, in that
"function A does the same thing as function B for all arguments that
are valid for function B (but function A may have additional
functionality for arguments that are not valid for B)". Then you
specify equivalence by specifying subtype equivalence in both
directions (with a shortcut, of course).
> 9. static analysis may be leveraged to compile direct calls to
> native functions when compile time resolution is possible. In
> the example graph, for example, no eval or symbol table
> assignments are made, so there is no way the code will ever
> change. Hence the entire program can be pre-resolved. This
> should be controlled via the 'optimize' pragma.
Rather than having the compiler try to infer for itself, which would
come up negative 99% of the time and just waste compile time.
> Since FFIs are going to be a core feature of perl 6, they can be
> used to bootstrap the whole compilation process. In effect, the
> "primitive" operations are now just FFI calls to the runtime we
> happen to be executing on.
And if you have a circular reference implementation, the implementors
can decide to implement whatever generating subset is easiest and get
a working Perl. I like this.
Hmm, could we pull the idea of a generating subset out to
roles/theories? That is, have a role specify that "a" and "b" are
implemented in terms of each other, so if you provide one, you fulfill
the role contract. In Haskell, if you don't fulfill a class contract
that's mutually recursive, you get infinite loops. It be nice to
catch that.
Then I guess we would have "theory PerlCore". Neat.
> To make things modular, the paring of FFI and pure perl functions is
> orthogonal to their location of definition based on the hashing
> scheme.
So as we're hashing PIL, we'd leave out line number information and whatnot.
> WRT MMD, you can set the entire MM equivalent to
> a certain foreign function, and you can also set any variant
> individually. You can even set a single variant to be equivalent to
> a multimethod to make the FFI implementation simpler. The compiler
> simply presents the runtime with all the possible MMD choices, and
> lets the runtime choose between conflicting ones.
Like a nice "wrapping" MMD scheme ought to.
All in all, I like the idea. I hope there are no major technical
hurdles. The hashing scheme scares me a little, because it's easy to
create equivalent code that does not look the same from PIL, but it
seems like you covered that base.
Luke
