unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
From: Andy Wingo <wingo@pobox.com>
To: Mark H Weaver <mhw@netris.org>
Cc: guile-devel <guile-devel@gnu.org>
Subject: Re: summary: lilypond, lambda, and local-eval
Date: Fri, 16 Dec 2011 10:28:36 +0100	[thread overview]
Message-ID: <87liqcamrf.fsf@pobox.com> (raw)
In-Reply-To: <87pqfpj7e3.fsf@netris.org> (Mark H. Weaver's message of "Fri, 16 Dec 2011 02:35:48 -0500")

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 <mhw@netris.org> 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 (the-environment)))
  
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 :)

Andy
-- 
http://wingolog.org/



  parent reply	other threads:[~2011-12-16  9:28 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-12-15 10:21 summary: lilypond, lambda, and local-eval Andy Wingo
2011-12-15 14:46 ` David Kastrup
2011-12-15 16:52 ` Hans Aberg
2011-12-15 17:24   ` David Kastrup
2011-12-15 17:52     ` Hans Aberg
2011-12-16  7:35 ` Mark H Weaver
2011-12-16  8:08   ` Mark H Weaver
2011-12-16  8:49   ` Mark H Weaver
2011-12-16  9:16     ` David Kastrup
2011-12-18  7:11     ` Mark H Weaver
2011-12-18 11:27       ` Andy Wingo
2011-12-18 15:32         ` Noah Lavine
2011-12-18 16:19           ` David Kastrup
2011-12-18 21:24             ` Noah Lavine
2011-12-19  9:13         ` Mark H Weaver
2012-01-09 14:44           ` David Kastrup
2011-12-16  9:28   ` Andy Wingo [this message]
2011-12-16  9:59     ` David Kastrup
2011-12-16 10:33     ` Mark H Weaver
2011-12-16 12:13       ` Hans Aberg
2011-12-16 12:43         ` David Kastrup
2011-12-16 14:57           ` Hans Aberg
2011-12-21 10:32 ` Ian Hulin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/guile/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87liqcamrf.fsf@pobox.com \
    --to=wingo@pobox.com \
    --cc=guile-devel@gnu.org \
    --cc=mhw@netris.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).