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

> 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

> >                 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

        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!!!!!!!!!!!!!!!!!!!!!!

Attachment: pgpzsQPvto7BO.pgp
Description: PGP signature

Reply via email to