unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
From: Clinton Ebadi <clinton@unknownlamer.org>
Cc: guile-devel@gnu.org
Subject: Re: Status of the "Project Ideas" page / Summer of Code
Date: Fri, 05 May 2006 19:13:36 -0400	[thread overview]
Message-ID: <1146870816.22375.17.camel@localhost.localdomain> (raw)
In-Reply-To: <c1d5a43d0605051502l4aa5a6e3i26c8b0141e6aea70@mail.gmail.com>


[-- Attachment #1.1: Type: text/plain, Size: 1476 bytes --]

On Sat, 2006-05-06 at 00:02 +0200, Martin Kuehl wrote:
> Damn, macros again :-)
> I'll definitely take a look at the revival, but I really doubt I'm the
> one to take on first-class macros just yet.  I seem to have a hard
> time reasoning about them instead of CL macros (or maybe I just
> confuse them too much with Haskell-style pattern matching, i'm not
> sure), and that's something I'd want to change before dealing with
> their compilation.

Guile's built in macros are unhygenic, and work in the same way that
Common Lisp macros do.

A few weeks ago I spent a few hours in the eval code, and it looks like
the big thing that still needs doing is making memoization and macro
expansion eager (macroexpand + memoize an entire expression before
beggining to evaluate any part of it instead of waiting until the
evaluator evals the statement itself like it does now).

Once that is done then the first part of the eval should be split into a
compiler, and the second half into the actual eval step. Then it would
be relatively trivial to drop a new compiler/executor into Guile (if I
understood the code correctly). All the new backend would need to do is
understand the primitive operations that the macroexpander/memoizer
produces.

-- 
http://unknownlamer.org
AIM:unknownlamer IRC:unknown_lamer@fnode#tpu Jabber:clinton@hcoop.net
I use Free Software because I value freedom over features.
443E 4F1A E213 7C54 A306  E328 7601 A1F0 F403 574B

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 143 bytes --]

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

  reply	other threads:[~2006-05-05 23:13 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-04-24 21:17 Status of the "Project Ideas" page / Summer of Code Martin Kuehl
2006-04-25 14:11 ` Andy Wingo
2006-04-25 22:56   ` Neil Jerram
2006-04-25 14:14 ` Ludovic Courtès
2006-04-30  0:34   ` Martin Kuehl
2006-05-02  8:39     ` Ludovic Courtès
2006-05-05 22:02       ` Martin Kuehl
2006-05-05 23:13         ` Clinton Ebadi [this message]
2006-05-04  9:40     ` Neil Jerram
2006-05-05 22:02       ` Martin Kuehl
2006-05-10 18:42         ` Neil Jerram
2006-04-30  7:38 ` Martin Kuehl

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=1146870816.22375.17.camel@localhost.localdomain \
    --to=clinton@unknownlamer.org \
    --cc=guile-devel@gnu.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).