On Wed, Feb 02, 2005 at 04:07:26PM -0700, Luke Palmer wrote:
> > Also, is the "all lists are lazy by default" rule correctly used in
> > the @squares and @fib examples?  Is there a way to turn them into
> > functions instead of arrays?
>     @fib ::= (1, 1, for zip(@fib;@fib[1...]) -> { $^a + $^b })
> I don't know why you're doing compile-time binding (::=) in this case.

Mostly because I've only started implementing "::=" and not ":=" (and
certainly not "=").

> And you can't really embed a for inside an expression like that.  That's
> why we have map:
>     @fib := (1, 1, map { $^a + $^b } zip(@fib; @fib[1...]))

I have updated the page to have this instead:

    @fib ::= (1, 1, zip(@fib; @fib[1...]).map( $^a + $^b ))

Can you explain how "::=" is different from ":=" here?  Does "::="
require all the RHS terms to be defined first, and ":=" somehow
allows for recursive let?

> > Finally, the distributive laws and semantics for one() gives me troubles,
> > as my intuition on how to evaluate one() is weak.
> Mine too.  I've never seen much use for one().
> But you can think of all junctions as simply a set together with a
> boolean evaluation operation.  They all distribute the same way; they
> nest inside each other with the associativity of the operator that
> they're distributing over (or from left to right if your in a function
> call or something).

Hmm.  S09v4 says that conjunction (all) and injunction (none) are always
distributed prior to abjunction (one) and disjunction (any).

> Where they differ is in boolean evaluation, and the semantics there are
> obvious.  Evaluate recursively.  (But things do get tricky when they
> have to return something---I'm not even sure we've hashed that out yet)

Yes, in boolean context the intuition is obvious.  I'm mostly puzzling
over the behaviour in other contexts, both as values and (even more
confusingly) as lvalues.

> > As the implementation progresses, I'll probably bother the list with
> > many of such naive questions.  Thanks in advance for your patience. :-)
> Such "naive" questions are the only things we have to test the coherency
> of the design.  Please, keep them coming.

I will. :)


Attachment: pgpdecrZKDaeF.pgp
Description: PGP signature

Reply via email to