[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: summary: lilypond, lambda, and local-eval

From: Andy Wingo
Subject: Re: summary: lilypond, lambda, and local-eval
Date: Fri, 16 Dec 2011 10:28:36 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux)

Hi Mark,

This is an interesting plan.  I still have some doubts, but perhaps you
can make it work.

First, a couple of notes:

On Fri 16 Dec 2011 08:35, Mark H Weaver <address@hidden> writes:

>     (quote <compiler-environment>)  ;; simple list structure
>     (quote <expander-environment>)  ;; simple list structure

Perhaps syntax-objects can give you what you need here. 

>     <module>)  ;; XXX not sure how best to represent this

The expander needs to serialize representations of modules in syntax
objects, and for that purpose it uses the module name.  "Anonymous"
modules actually have generated names, lazily.  Use `module-name'.

I like the "modeling the-environment as a scheme expression" approach;
it gives `the-environment' some semantics.  I used to ignore people who
yammered on about semantics and languages, but I have grown to respect
that approach to language development.  So thank you there.

Also, note that forms that `set!' all bound lexicals in the
`the-environment' will cause them all to be boxed, so there is no boxed
bitvector needed.

> How to implement `local-eval'
> =============================
> When `local-eval' is called on a lexical environment that was created by
> compiled code, it will do the following:
> * Macroexpand the local expression within <expander-environment>.
> * Compile the expanded expression within <compiler-environment>.
>   (I'll explain how to do this below)
> * Make a copy of the closure from the lexical environment object, but
>   replace its code (the dispatcher) with the newly compiled code.
> * Call the newly created closure.

We are really far from considering efficiency here :)  Would you always
use the compiler for this task?  (I think I would.)  But otherwise, this
sounds sensible, with a caveat:: hygiene, nested definitions, and the
macro expander.

What does local-eval really mean?

What are the meanings of these expressions:

  ;; Toplevel
  (local-eval '(define foo 42) (the-environment))

  ;; Lexical, tail context
  (local-eval '(define foo 42) (let ((x 100)) (the-environment)))

  ;; Lexical, tail context -- but with a definition
  (local-eval '(begin (define foo 42) foo) (let ((x 100)) (the-environment)))

  ;; Lexical, tail context -- but with a definition, and nested reference
  (local-eval '(begin (define foo 42) (bar))
              (let ((x 100)) (define (bar) foo) (the-environment)))

  ;; Lexical, not a definition context
  (local-eval '(define foo 42) (let ((x 100)) not-a-definition 
What about this one:

  ;; Keeping in mind that `or' expands to (let ((t ...)) (if t t ...)),
  ;; hygienically
  (local-eval 't '(let ((t 42)) (or #f (the-environment)))) 

Can you pass syntax objects into `local-eval'?

Are let-syntax / letrec-syntax / nested define-syntax forms present in a
local environment?  Currently these things never leave the expander.  I
suppose as long as they are understood to be opaque, it would be OK.

That's all I really wanted to write about local-eval, I think, so no
promised other mail.  Thanks for thinking about these things :)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]