On Mon, Sep 12, 2005 at 13:27:21 -0600, Luke Palmer wrote: > 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?
If there is a given function x, that calls another function y, and
there is an FFI function z that is "the same" as x (it refers to
it's hash). If 'y' is changed, then the semantics of x may change,
hence the hash must change (a call to z is no longer equal to a call
to x). (unless y says it is equal to the old y, by mentioning it's
hash).
> How do you deal with recursive/mutually recursive functions? (I'm
> pretty sure there's a way, I just can't think of it)
Right now I don't, i'm cheating.
In the future I'd like to hash the body for all functions, and then
hash the hash of the body and the hashes of all the called bodies to
make a function hash.
> What about "temp &foo = sub {...}" ?
This has an entirely different hash, so it doesn't go to the same
thing.
> > my $str = &infix:<*><int, int --> int>.digest; # must
> > specify the variant
>
> You mean:
>
> my $str = &infix:<*>:(int, int --> int).digest;
uh, yeah... I keep forgetting the syntax.
>
> 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?
replacements are per variant i guess, and the catch all (completely
unqualified multi) has a hash built out of all it's variants.
> 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).
I'll leave this part to you ;-)
> > 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.
I disagree... Most one liners and small scripts could really benefit
from this, and it's an easy test - just set a flag the moment you
see either the eval opcode or the ::= opcode.
> 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.
Yes, this is why I brought it up =)
> 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.
it's too late for me to understand that... sorry...
> So as we're hashing PIL, we'd leave out line number information and whatnot.
Yeah, this is also possibly the canonical representation. For
example
sub foo ($x) {
$x ? 1 : 2;
}
sub foo ($x) {
if ($x) {
return 1;
} else {
return 2;
}
}
> 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.
I won't expect a reference implementation to be refactored too much,
but even if it does, you just say that this function is the same as
the function with the hash value x, where x is the hash it had
before the refactoring.
--
() Yuval Kogman <[EMAIL PROTECTED]> 0xEBD27418 perl hacker &
/\ kung foo master: /me tips over a cow: neeyah!!!!!!!!!!!!!!!!!!!!!!
pgpzsQPvto7BO.pgp
Description: PGP signature
