Guile Lua

Guile Lua

[Ian Price]

About two weeks ago, I emailed "Phil", who had shown some interest in
hacking guile lua a while back. I still haven't heard back from him, nor
has that branch been touched in 18 months, so I think we can safely say
we need a new maintainer for it.

I have little knowledge of lua, so I can't really do it, but if you know
anyone who likes lua, and would be willing to hack on it, please suggest
it to them. It'd be a shame to see that code go to waste.

Wingo, Ludovic
I hope this isn't too forward of me.

-- 
Ian Price -- shift-reset.com

"Programming is like pinball. The reward for doing it well is
the opportunity to do it again" - from "The Wizardy Compiled"

Re: Guile Lua

[nalaginrut]

On Sat, 2012-11-17 at 16:30 +0000, Ian Price wrote:
> About two weeks ago, I emailed "Phil", who had shown some interest in
> hacking guile lua a while back. I still haven't heard back from him, nor
> has that branch been touched in 18 months, so I think we can safely say
> we need a new maintainer for it.
> 
> I have little knowledge of lua, so I can't really do it, but if you know
> anyone who likes lua, and would be willing to hack on it, please suggest
> it to them. It'd be a shame to see that code go to waste.
> 

I'm interested on our multi-language feature. And I wish Guile become
the real dynamic language compiler collection someday, which mean we
need to add more workable languages. 
I'd like to know what work should the maintainer take? As I know there's
some work has been done, but it didn't merge into stable-2.0. What's the
rest work? Does it work now? 

> Wingo, Ludovic
> I hope this isn't too forward of me.
> 

Re: Guile Lua

[Ludovic Courtès]

Hi!

nalaginrut <nalaginrut@gmail.com> skribis:

> I'd like to know what work should the maintainer take? As I know there's
> some work has been done, but it didn't merge into stable-2.0. What's the
> rest work? Does it work now? 

I think the first task for you (congratulations! ;-)) or anyone else
interested will be to check out the branch, build it, assess it, and
tell us what it’s current status is.

Then, assuming it’s in a good shape, one would have to try running
actual Lua programs, in search of bugs.  Along the way, these bugs would
have to be fixed, and the test suite augmented accordingly.

Then the fine points regarding multi-language integration will have to
be sorted out.  The manual will have to be updated.

When all this is in place, we can consider merging the branch.  I
wouldn’t want to merge a half-baked front-end.

WDYT?

Ludo’.

Re: Guile Lua

[Ian Price]

nalaginrut <nalaginrut@gmail.com> writes:

> I'm interested on our multi-language feature. And I wish Guile become
> the real dynamic language compiler collection someday, which mean we
> need to add more workable languages. 
> I'd like to know what work should the maintainer take? As I know there's
> some work has been done, but it didn't merge into stable-2.0. What's the
> rest work? Does it work now? 

I'm no expert on lua, so I can't give you a huge long list, but Phil did
make a post titled "Creating a Lua Roadmap" at
http://article.gmane.org/gmane.lisp.guile.devel/12291

The first issues would be them. There appears to be a notes.org in the
modules/language/lua directory, so compare with that, but I expect the
roadmap covered that. Then it would be a matter of working through the
lua manual, and seeing what else is missing.

-- 
Ian Price -- shift-reset.com

"Programming is like pinball. The reward for doing it well is
the opportunity to do it again" - from "The Wizardy Compiled"

Re: Guile Lua

[nalaginrut]

On Mon, 2012-11-19 at 22:07 +0100, Ludovic Courtès wrote:
> Hi!
> 
> nalaginrut <nalaginrut@gmail.com> skribis:
> 
> > I'd like to know what work should the maintainer take? As I know there's
> > some work has been done, but it didn't merge into stable-2.0. What's the
> > rest work? Does it work now? 
> 
> I think the first task for you (congratulations! ;-)) or anyone else
> interested will be to check out the branch, build it, assess it, and
> tell us what it’s current status is.
> 
> Then, assuming it’s in a good shape, one would have to try running
> actual Lua programs, in search of bugs.  Along the way, these bugs would
> have to be fixed, and the test suite augmented accordingly.
> 
> Then the fine points regarding multi-language integration will have to
> be sorted out.  The manual will have to be updated.
> 
> When all this is in place, we can consider merging the branch.  I
> wouldn’t want to merge a half-baked front-end.
> 
> WDYT?
> 
> Ludo’.
> 
> 

@ijp: thanks for the info ;-)

@ludo: Thanks! I'll try to do it follow your steps. 
Besides, do we have the final conclusion for the multi-lang choosing
approach, say, --lang=lua/elisp or #lang lua or a script:
guile-lua/guile-elisp... whatever. IIRC, ijp raised such a topic, but it
seems no conclusion.
I ask this because there should be an easy way to test some big code
segment written in other language. 

Re: Guile Lua

[Daniel Hartwig]

On 20 November 2012 08:24, Ian Price <ianprice90@googlemail.com> wrote:
> I'm no expert on lua, so I can't give you a huge long list, but Phil did
> make a post titled "Creating a Lua Roadmap" at
> http://article.gmane.org/gmane.lisp.guile.devel/12291
>
> The first issues would be them. There appears to be a notes.org in the
> modules/language/lua directory, so compare with that, but I expect the
> roadmap covered that. Then it would be a matter of working through the
> lua manual, and seeing what else is missing.

Add to these lists that (language lua) does not implement the
table–array optimization [1].  This would be an interesting early task
for someone as the algorithm is relatively simple.  Without it the
performance of “arrays”  will be poor.

[1] <http://www.lua.org/doc/jucs05.pdf>

Re: Guile Lua

[Ian Price]

nalaginrut <nalaginrut@gmail.com> writes:

> Besides, do we have the final conclusion for the multi-lang choosing
> approach, say, --lang=lua/elisp or #lang lua or a script:
> guile-lua/guile-elisp... whatever. IIRC, ijp raised such a topic, but it
> seems no conclusion.

No, I started compiling a list of the pros/cons of the various suggested
approaches, but the only conclusion I've reached is that no single
solution is going to work out on its own.

I'll take some time to finish this list up and post it later today

-- 
Ian Price -- shift-reset.com

"Programming is like pinball. The reward for doing it well is
the opportunity to do it again" - from "The Wizardy Compiled"

Re: Guile Lua

[Ludovic Courtès]

Hi!

nalaginrut <nalaginrut@gmail.com> skribis:

> @ludo: Thanks! I'll try to do it follow your steps. 
> Besides, do we have the final conclusion for the multi-lang choosing
> approach, say, --lang=lua/elisp or #lang lua or a script:
> guile-lua/guile-elisp... whatever. IIRC, ijp raised such a topic, but it
> seems no conclusion.
> I ask this because there should be an easy way to test some big code
> segment written in other language. 

This can achieved with a simple wrapper script.  Do we need a standard
executable or command-line option for this?

Ludo’.

Re: Guile Lua

[nalaginrut]

On Tue, 2012-11-20 at 18:04 +0100, Ludovic Courtès wrote:
> Hi!
> 
> nalaginrut <nalaginrut@gmail.com> skribis:
> 
> > @ludo: Thanks! I'll try to do it follow your steps. 
> > Besides, do we have the final conclusion for the multi-lang choosing
> > approach, say, --lang=lua/elisp or #lang lua or a script:
> > guile-lua/guile-elisp... whatever. IIRC, ijp raised such a topic, but it
> > seems no conclusion.
> > I ask this because there should be an easy way to test some big code
> > segment written in other language. 
> 
> This can achieved with a simple wrapper script.  Do we need a standard
> executable or command-line option for this?
> 

Yes, I need such a thing, since I'll test other and try new language
either. 
But as ijp pointed out, this may not solve easily, and it's been
discussion.
So would you please give me a temporary method to run non-scheme script
file with Guile? 

> Ludo’.

Re: Guile Lua

[nalaginrut]

On Mon, 2012-11-19 at 22:07 +0100, Ludovic Courtès wrote:
> Hi!
> 
> nalaginrut <nalaginrut@gmail.com> skribis:
> 
> > I'd like to know what work should the maintainer take? As I know there's
> > some work has been done, but it didn't merge into stable-2.0. What's the
> > rest work? Does it work now? 
> 
> I think the first task for you (congratulations! ;-)) or anyone else
> interested will be to check out the branch, build it, assess it, and
> tell us what it’s current status is.
> 

I switch to lua branch then compiled it and try, seems some bugs there,
it can't run successfully:
-------------------cut--------------------
scheme@(guile-user)> ,L lua
Happy hacking with Lua!  To switch back, type `,L scheme'.
lua@(guile-user)> x=1
[enter]
[enter]
[enter]
^CWhile reading expression:
ERROR: User interrupt
lua@(guile-user)> 
-------------------end--------------------

And I checked the code, it doen't use Guile inner LALR parser.
Anybody point me out what is the suggested parser implementation? The
inner scheme-LALR(which contains GLR also) or manual parser generator?
Which is better for a practical multi-lang implementation?

And is there anyone ever evaluated the efficiency about the non-scheme
language implemented within Guile? 
Anyway, this wouldn't be a big problem, since Guile could be the future
dynamic language compiler collection, it could be optimized later.

> Then, assuming it’s in a good shape, one would have to try running
> actual Lua programs, in search of bugs.  Along the way, these bugs would
> have to be fixed, and the test suite augmented accordingly.
> 
> Then the fine points regarding multi-language integration will have to
> be sorted out.  The manual will have to be updated.
> 
> When all this is in place, we can consider merging the branch.  I
> wouldn’t want to merge a half-baked front-end.
> 
> WDYT?
> 
> Ludo’.
> 
> 

Re: Guile Lua

[Ludovic Courtès]

Hi!

nalaginrut <nalaginrut@gmail.com> skribis:

> I switch to lua branch then compiled it and try, seems some bugs there,
> it can't run successfully:
> -------------------cut--------------------
> scheme@(guile-user)> ,L lua
> Happy hacking with Lua!  To switch back, type `,L scheme'.
> lua@(guile-user)> x=1

Maybe you need a semicolon here?

> And I checked the code, it doen't use Guile inner LALR parser.
> Anybody point me out what is the suggested parser implementation?

(system base lalr).

> And is there anyone ever evaluated the efficiency about the non-scheme
> language implemented within Guile? 

I don’t think so.  Only the Scheme and Emacs Lisp front-end are
reasonably mature, anyway.

> Anyway, this wouldn't be a big problem, since Guile could be the
> future dynamic language compiler collection, it could be optimized
> later.

FWIW, I don’t quite buy the “dynamic language compiler collection”.
Others tried this before (Parrot), with some success in terms of
supported languages, but not much beyond that.

In terms of strategy, I think Guile’s focus should remain primarily on
Scheme variants, and ELisp.  Other language front-ends are of course
welcome, but we must keep an eye on what the demand is.

Thanks,
Ludo’.

Re: Guile Lua

[Stefan Israelsson Tampe]

[-- Attachment #1: Type: text/plain, Size: 1889 bytes --]

Hi,
> In terms of strategy, I think Guile’s focus should remain primarily on
> Scheme variants, and ELisp.  Other language front-ends are of course
> welcome, but we must keep an eye on what the demand is.

What about common lisp is scheme a lisp or is CL a scheme :-)

Anyway to support CL I would think that we need to support placing
properties
on symbols, e,g. currently a symbol slot is a variable, but to effectively
support CL I would go for
/Stefan

Den 21 nov 2012 14:26 skrev "Ludovic Courtès" <ludo@gnu.org>:

> Hi!
>
> nalaginrut <nalaginrut@gmail.com> skribis:
>
> > I switch to lua branch then compiled it and try, seems some bugs there,
> > it can't run successfully:
> > -------------------cut--------------------
> > scheme@(guile-user)> ,L lua
> > Happy hacking with Lua!  To switch back, type `,L scheme'.
> > lua@(guile-user)> x=1
>
> Maybe you need a semicolon here?
>
> > And I checked the code, it doen't use Guile inner LALR parser.
> > Anybody point me out what is the suggested parser implementation?
>
> (system base lalr).
>
> > And is there anyone ever evaluated the efficiency about the non-scheme
> > language implemented within Guile?
>
> I don’t think so.  Only the Scheme and Emacs Lisp front-end are
> reasonably mature, anyway.
>
> > Anyway, this wouldn't be a big problem, since Guile could be the
> > future dynamic language compiler collection, it could be optimized
> > later.
>
> FWIW, I don’t quite buy the “dynamic language compiler collection”.
> Others tried this before (Parrot), with some success in terms of
> supported languages, but not much beyond that.
>
> In terms of strategy, I think Guile’s focus should remain primarily on
> Scheme variants, and ELisp.  Other language front-ends are of course
> welcome, but we must keep an eye on what the demand is.
>
> Thanks,
> Ludo’.
>
>

[-- Attachment #2: Type: text/html, Size: 2355 bytes --]

Re: Guile Lua

[nalaginrut]

On Wed, 2012-11-21 at 14:25 +0100, Ludovic Courtès wrote:
> Hi!
> 
> nalaginrut <nalaginrut@gmail.com> skribis:
> 
> > I switch to lua branch then compiled it and try, seems some bugs there,
> > it can't run successfully:
> > -------------------cut--------------------
> > scheme@(guile-user)> ,L lua
> > Happy hacking with Lua!  To switch back, type `,L scheme'.
> > lua@(guile-user)> x=1
> 
> Maybe you need a semicolon here?

I don't think so. But even I add a semicolon, it's still the same.
Anyway, bug is inevitable. ;-)

> Ludo’.

Re: Guile Lua

[Nala Ginrut]

On Wed, 2012-11-21 at 16:51 +0100, Stefan Israelsson Tampe wrote:
> Hi,
> > In terms of strategy, I think Guile’s focus should remain primarily
> on
> > Scheme variants, and ELisp.  Other language front-ends are of course
> > welcome, but we must keep an eye on what the demand is.
> 
> What about common lisp is scheme a lisp or is CL a scheme :-)
> 

IIRC， someone raised the topic that emerge Clisp into Guile in 2011,
but what's the status now?

> Anyway to support CL I would think that we need to support placing
> properties
> on symbols, e,g. currently a symbol slot is a variable, but to
> effectively support CL I would go for 
> /Stefan
> 
> 
> 
> Den 21 nov 2012 14:26 skrev "Ludovic Courtès" <ludo@gnu.org>:
>         Hi!
>         
>         nalaginrut <nalaginrut@gmail.com> skribis:
>         
>         > I switch to lua branch then compiled it and try, seems some
>         bugs there,
>         > it can't run successfully:
>         > -------------------cut--------------------
>         > scheme@(guile-user)> ,L lua
>         > Happy hacking with Lua!  To switch back, type `,L scheme'.
>         > lua@(guile-user)> x=1
>         
>         Maybe you need a semicolon here?
>         
>         > And I checked the code, it doen't use Guile inner LALR
>         parser.
>         > Anybody point me out what is the suggested parser
>         implementation?
>         
>         (system base lalr).
>         
>         > And is there anyone ever evaluated the efficiency about the
>         non-scheme
>         > language implemented within Guile?
>         
>         I don’t think so.  Only the Scheme and Emacs Lisp front-end
>         are
>         reasonably mature, anyway.
>         
>         > Anyway, this wouldn't be a big problem, since Guile could be
>         the
>         > future dynamic language compiler collection, it could be
>         optimized
>         > later.
>         
>         FWIW, I don’t quite buy the “dynamic language compiler
>         collection”.
>         Others tried this before (Parrot), with some success in terms
>         of
>         supported languages, but not much beyond that.
>         
>         In terms of strategy, I think Guile’s focus should remain
>         primarily on
>         Scheme variants, and ELisp.  Other language front-ends are of
>         course
>         welcome, but we must keep an eye on what the demand is.
>         
>         Thanks,
>         Ludo’.
>         

Re: Guile Lua

[Noah Lavine]

[-- Attachment #1: Type: text/plain, Size: 2914 bytes --]

I sent an email about that, but it was only an idea. I thought it would be
nice if we could work with the Clisp people. However, I can see some
barriers to actually doing that, and I don't intend to work on it any time
soon.

Noah


On Sat, Jan 12, 2013 at 3:43 AM, Nala Ginrut <nalaginrut@gmail.com> wrote:

> On Wed, 2012-11-21 at 16:51 +0100, Stefan Israelsson Tampe wrote:
> > Hi,
> > > In terms of strategy, I think Guile’s focus should remain primarily
> > on
> > > Scheme variants, and ELisp.  Other language front-ends are of course
> > > welcome, but we must keep an eye on what the demand is.
> >
> > What about common lisp is scheme a lisp or is CL a scheme :-)
> >
>
> IIRC， someone raised the topic that emerge Clisp into Guile in 2011,
> but what's the status now?
>
> > Anyway to support CL I would think that we need to support placing
> > properties
> > on symbols, e,g. currently a symbol slot is a variable, but to
> > effectively support CL I would go for
> > /Stefan
> >
> >
> >
> > Den 21 nov 2012 14:26 skrev "Ludovic Courtès" <ludo@gnu.org>:
> >         Hi!
> >
> >         nalaginrut <nalaginrut@gmail.com> skribis:
> >
> >         > I switch to lua branch then compiled it and try, seems some
> >         bugs there,
> >         > it can't run successfully:
> >         > -------------------cut--------------------
> >         > scheme@(guile-user)> ,L lua
> >         > Happy hacking with Lua!  To switch back, type `,L scheme'.
> >         > lua@(guile-user)> x=1
> >
> >         Maybe you need a semicolon here?
> >
> >         > And I checked the code, it doen't use Guile inner LALR
> >         parser.
> >         > Anybody point me out what is the suggested parser
> >         implementation?
> >
> >         (system base lalr).
> >
> >         > And is there anyone ever evaluated the efficiency about the
> >         non-scheme
> >         > language implemented within Guile?
> >
> >         I don’t think so.  Only the Scheme and Emacs Lisp front-end
> >         are
> >         reasonably mature, anyway.
> >
> >         > Anyway, this wouldn't be a big problem, since Guile could be
> >         the
> >         > future dynamic language compiler collection, it could be
> >         optimized
> >         > later.
> >
> >         FWIW, I don’t quite buy the “dynamic language compiler
> >         collection”.
> >         Others tried this before (Parrot), with some success in terms
> >         of
> >         supported languages, but not much beyond that.
> >
> >         In terms of strategy, I think Guile’s focus should remain
> >         primarily on
> >         Scheme variants, and ELisp.  Other language front-ends are of
> >         course
> >         welcome, but we must keep an eye on what the demand is.
> >
> >         Thanks,
> >         Ludo’.
> >
>
>
>
>

[-- Attachment #2: Type: text/html, Size: 3991 bytes --]

Re: Guile Lua

[Nala Ginrut]

On Sat, 2013-01-12 at 09:37 -0500, Noah Lavine wrote:
> I sent an email about that, but it was only an idea. I thought it
> would be nice if we could work with the Clisp people. However, I can
> see some barriers to actually doing that, and I don't intend to work
> on it any time soon.
> 
Thanks for asking that.
Anyway, we may throw it into TODO list.
I don't intend to work on it too, since Lisp is not on my hack line, I
have Scheme anyway. ;-P
> 
> Noah
> 
> 
> On Sat, Jan 12, 2013 at 3:43 AM, Nala Ginrut <nalaginrut@gmail.com>
> wrote:
>         On Wed, 2012-11-21 at 16:51 +0100, Stefan Israelsson Tampe
>         wrote:
>         > Hi,
>         > > In terms of strategy, I think Guile’s focus should remain
>         primarily
>         > on
>         > > Scheme variants, and ELisp.  Other language front-ends are
>         of course
>         > > welcome, but we must keep an eye on what the demand is.
>         >
>         > What about common lisp is scheme a lisp or is CL a
>         scheme :-)
>         >
>         
>         
>         IIRC， someone raised the topic that emerge Clisp into Guile
>         in 2011,
>         but what's the status now?
>         
>         > Anyway to support CL I would think that we need to support
>         placing
>         > properties
>         > on symbols, e,g. currently a symbol slot is a variable, but
>         to
>         > effectively support CL I would go for
>         > /Stefan
>         >
>         >
>         >
>         > Den 21 nov 2012 14:26 skrev "Ludovic Courtès"
>         <ludo@gnu.org>:
>         >         Hi!
>         >
>         >         nalaginrut <nalaginrut@gmail.com> skribis:
>         >
>         >         > I switch to lua branch then compiled it and try,
>         seems some
>         >         bugs there,
>         >         > it can't run successfully:
>         >         > -------------------cut--------------------
>         >         > scheme@(guile-user)> ,L lua
>         >         > Happy hacking with Lua!  To switch back, type `,L
>         scheme'.
>         >         > lua@(guile-user)> x=1
>         >
>         >         Maybe you need a semicolon here?
>         >
>         >         > And I checked the code, it doen't use Guile inner
>         LALR
>         >         parser.
>         >         > Anybody point me out what is the suggested parser
>         >         implementation?
>         >
>         >         (system base lalr).
>         >
>         >         > And is there anyone ever evaluated the efficiency
>         about the
>         >         non-scheme
>         >         > language implemented within Guile?
>         >
>         >         I don’t think so.  Only the Scheme and Emacs Lisp
>         front-end
>         >         are
>         >         reasonably mature, anyway.
>         >
>         >         > Anyway, this wouldn't be a big problem, since
>         Guile could be
>         >         the
>         >         > future dynamic language compiler collection, it
>         could be
>         >         optimized
>         >         > later.
>         >
>         >         FWIW, I don’t quite buy the “dynamic language
>         compiler
>         >         collection”.
>         >         Others tried this before (Parrot), with some success
>         in terms
>         >         of
>         >         supported languages, but not much beyond that.
>         >
>         >         In terms of strategy, I think Guile’s focus should
>         remain
>         >         primarily on
>         >         Scheme variants, and ELisp.  Other language
>         front-ends are of
>         >         course
>         >         welcome, but we must keep an eye on what the demand
>         is.
>         >
>         >         Thanks,
>         >         Ludo’.
>         >
>         
>         
>         
>         
> 
> 

Re: Guile Lua

[Ian Price]

Nala Ginrut <nalaginrut@gmail.com> writes:

>> What about common lisp is scheme a lisp or is CL a scheme :-)
>> 
>
> IIRC， someone raised the topic that emerge Clisp into Guile in 2011,
> but what's the status now?
>
>> Anyway to support CL I would think that we need to support placing
>> properties
>> on symbols, e,g. currently a symbol slot is a variable, but to
>> effectively support CL I would go for 
>> /Stefan

I don't think we should get ahead of ourselves, but emacs has had some
minor CL emulation in things like cl.el and cl-lib. I think these could
be good test cases for the elisp support.

-- 
Ian Price -- shift-reset.com

"Programming is like pinball. The reward for doing it well is
the opportunity to do it again" - from "The Wizardy Compiled"

Re: Guile Lua

[Stefan Israelsson Tampe]

[-- Attachment #1: Type: text/plain, Size: 1228 bytes --]

Hi,

To note is that in order to implement common lisp one need to bypass tree-il
and generate directly to glil, the reason is that tagbody is poorly
represented
by tree-il. If we intend to be multilingual it would be nice to be able to
effectively
represent those ideoms. Any thoughts on it?

/Stefan


On Sun, Jan 13, 2013 at 4:13 PM, Ian Price <ianprice90@googlemail.com>wrote:

> Nala Ginrut <nalaginrut@gmail.com> writes:
>
> >> What about common lisp is scheme a lisp or is CL a scheme :-)
> >>
> >
> > IIRC， someone raised the topic that emerge Clisp into Guile in 2011,
> > but what's the status now?
> >
> >> Anyway to support CL I would think that we need to support placing
> >> properties
> >> on symbols, e,g. currently a symbol slot is a variable, but to
> >> effectively support CL I would go for
> >> /Stefan
>
> I don't think we should get ahead of ourselves, but emacs has had some
> minor CL emulation in things like cl.el and cl-lib. I think these could
> be good test cases for the elisp support.
>
> --
> Ian Price -- shift-reset.com
>
> "Programming is like pinball. The reward for doing it well is
> the opportunity to do it again" - from "The Wizardy Compiled"
>

[-- Attachment #2: Type: text/html, Size: 1953 bytes --]

Re: Guile Lua

[Ian Price]

[-- Attachment #1: Type: text/plain, Size: 734 bytes --]

Stefan Israelsson Tampe <stefan.itampe@gmail.com> writes:

> To note is that in order to implement common lisp one need to bypass tree-il
> and generate directly to glil, the reason is that tagbody is poorly
> represented
> by tree-il. If we intend to be multilingual it would be nice to be able to
> effectively
> represent those ideoms. Any thoughts on it?

At one point I implemented tagbody for a laugh using call/cc. I've
attached the code, but it's kinda lame. I was much less experienced with
continuations and macros then, and I could certainly write it better now.

-- 
Ian Price -- shift-reset.com

"Programming is like pinball. The reward for doing it well is
the opportunity to do it again" - from "The Wizardy Compiled"


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

(library (tagbody)
(export tagbody go)         
(import (rnrs)
        (for (tagbody utils) expand)
        (for (srfi :8 receive) expand))

(define (go tag)
  (tag #f))

(define-syntax tagbody
  (lambda (stx)
    (define (make-group tag statements next)
      #`(call/cc
         (lambda (escape)
           (call/cc
            (lambda (k)
              (set! #,tag k)
              (escape k)))
           #,@statements
           #,(if next
                 #`(go #,next)
                 #'#f))))
    (define (exprs->groups first-tag list)
      (unzip (plist->alist identifier?
                           (cons first-tag list))))
    (syntax-case stx ()
      [(tagbody tags-or-statements ...)
       (let ((init #'init))
         (receive (tags groups) (exprs->groups
                                 init
                                 (syntax->list #'(tags-or-statements ...)))
           (with-syntax (((entry-point ...) (generate-temporaries tags))
                         ((tag ...) tags)
                         ((group ...)
                          (map make-group tags groups (shift-left tags #f))))
             #`(let ((tag #f) ... (done #f))
                 (let ((entry-point group) ...)
                   (unless done
                     (set! done #t)
                     (go #,init)))))))])))

)

[-- Attachment #3: various utilities --]
[-- Type: text/plain, Size: 1434 bytes --]

(library (tagbody utils)
(export plist->alist
        shift-left
        unzip
        syntax->list
        )
(import (rnrs))

(define (syntax->list stxobj)
  (define (inner stx)
    (syntax-case stx ()
      [() '()]
      [(x . rest)
       (cons #'x (inner #'rest))]))
  (assert (list? (syntax->datum stxobj)))
  (inner stxobj))

(define (plist->alist car? plist)
  ;; assumes head of (car? plist) is true
  (define (rcons a b)
    (cons (reverse a) b))
  (if (null? plist)
      '()
      (let loop ((plist (cdr plist))
                 (current-field (list (car plist)))
                 (return-list '()))
        (cond ((null? plist)
               (reverse
                (if (null? current-field)
                    return-list
                    (rcons current-field return-list))))
              ((car? (car plist))
               (loop (cdr plist)
                     (list (car plist))
                     (rcons current-field return-list)))
              (else
               (loop (cdr plist)
                     (cons (car plist) current-field)
                     return-list))))))

(define (unzip list-of-pairs)
  (let loop ((pairs list-of-pairs) (cars '()) (cdrs '()))
    (if (null? pairs)
        (values (reverse cars) (reverse cdrs))
        (loop (cdr pairs) (cons (caar pairs) cars)
              (cons (cdar pairs) cdrs)))))

(define (shift-left old-list end)
  (append (cdr old-list) (list end)))

)