* Guile Lua @ 2012-11-17 16:30 Ian Price 2012-11-19 2:30 ` nalaginrut 0 siblings, 1 reply; 19+ messages in thread From: Ian Price @ 2012-11-17 16:30 UTC (permalink / raw) To: guile-devel 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" ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Guile Lua 2012-11-17 16:30 Guile Lua Ian Price @ 2012-11-19 2:30 ` nalaginrut 2012-11-19 21:07 ` Ludovic Courtès 2012-11-20 0:24 ` Ian Price 0 siblings, 2 replies; 19+ messages in thread From: nalaginrut @ 2012-11-19 2:30 UTC (permalink / raw) To: Ian Price; +Cc: guile-devel 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. > ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Guile Lua 2012-11-19 2:30 ` nalaginrut @ 2012-11-19 21:07 ` Ludovic Courtès 2012-11-20 4:50 ` nalaginrut 2012-11-21 3:20 ` nalaginrut 2012-11-20 0:24 ` Ian Price 1 sibling, 2 replies; 19+ messages in thread From: Ludovic Courtès @ 2012-11-19 21:07 UTC (permalink / raw) To: guile-devel 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’. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Guile Lua 2012-11-19 21:07 ` Ludovic Courtès @ 2012-11-20 4:50 ` nalaginrut 2012-11-20 11:25 ` Ian Price 2012-11-20 17:04 ` Ludovic Courtès 2012-11-21 3:20 ` nalaginrut 1 sibling, 2 replies; 19+ messages in thread From: nalaginrut @ 2012-11-20 4:50 UTC (permalink / raw) To: Ludovic Courtès, Ian Price; +Cc: guile-devel 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. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Guile Lua 2012-11-20 4:50 ` nalaginrut @ 2012-11-20 11:25 ` Ian Price 2012-11-20 17:04 ` Ludovic Courtès 1 sibling, 0 replies; 19+ messages in thread From: Ian Price @ 2012-11-20 11:25 UTC (permalink / raw) To: nalaginrut; +Cc: Ludovic Courtès, guile-devel 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" ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Guile Lua 2012-11-20 4:50 ` nalaginrut 2012-11-20 11:25 ` Ian Price @ 2012-11-20 17:04 ` Ludovic Courtès 2012-11-21 2:40 ` nalaginrut 1 sibling, 1 reply; 19+ messages in thread From: Ludovic Courtès @ 2012-11-20 17:04 UTC (permalink / raw) To: nalaginrut; +Cc: Ian Price, guile-devel 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’. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Guile Lua 2012-11-20 17:04 ` Ludovic Courtès @ 2012-11-21 2:40 ` nalaginrut 0 siblings, 0 replies; 19+ messages in thread From: nalaginrut @ 2012-11-21 2:40 UTC (permalink / raw) To: Ludovic Courtès; +Cc: Ian Price, guile-devel 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’. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Guile Lua 2012-11-19 21:07 ` Ludovic Courtès 2012-11-20 4:50 ` nalaginrut @ 2012-11-21 3:20 ` nalaginrut 2012-11-21 13:25 ` Ludovic Courtès 1 sibling, 1 reply; 19+ messages in thread From: nalaginrut @ 2012-11-21 3:20 UTC (permalink / raw) To: Ludovic Courtès; +Cc: guile-devel 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’. > > ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Guile Lua 2012-11-21 3:20 ` nalaginrut @ 2012-11-21 13:25 ` Ludovic Courtès 2012-11-21 15:51 ` Stefan Israelsson Tampe 2012-11-23 3:45 ` nalaginrut 0 siblings, 2 replies; 19+ messages in thread From: Ludovic Courtès @ 2012-11-21 13:25 UTC (permalink / raw) To: nalaginrut; +Cc: guile-devel 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’. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Guile Lua 2012-11-21 13:25 ` Ludovic Courtès @ 2012-11-21 15:51 ` Stefan Israelsson Tampe 2013-01-12 8:43 ` Nala Ginrut 2012-11-23 3:45 ` nalaginrut 1 sibling, 1 reply; 19+ messages in thread From: Stefan Israelsson Tampe @ 2012-11-21 15:51 UTC (permalink / raw) To: Ludovic Courtès; +Cc: guile-devel [-- 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 --] ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Guile Lua 2012-11-21 15:51 ` Stefan Israelsson Tampe @ 2013-01-12 8:43 ` Nala Ginrut 2013-01-12 14:37 ` Noah Lavine 2013-01-13 15:13 ` Ian Price 0 siblings, 2 replies; 19+ messages in thread From: Nala Ginrut @ 2013-01-12 8:43 UTC (permalink / raw) To: Stefan Israelsson Tampe; +Cc: Ludovic Courtès, guile-devel 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’. > ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Guile Lua 2013-01-12 8:43 ` Nala Ginrut @ 2013-01-12 14:37 ` Noah Lavine 2013-01-12 15:25 ` Nala Ginrut 2013-01-13 15:13 ` Ian Price 1 sibling, 1 reply; 19+ messages in thread From: Noah Lavine @ 2013-01-12 14:37 UTC (permalink / raw) To: Nala Ginrut; +Cc: Ludovic Courtès, guile-devel [-- 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 --] ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Guile Lua 2013-01-12 14:37 ` Noah Lavine @ 2013-01-12 15:25 ` Nala Ginrut 0 siblings, 0 replies; 19+ messages in thread From: Nala Ginrut @ 2013-01-12 15:25 UTC (permalink / raw) To: Noah Lavine; +Cc: Ludovic Courtès, guile-devel 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’. > > > > > > > > ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Guile Lua 2013-01-12 8:43 ` Nala Ginrut 2013-01-12 14:37 ` Noah Lavine @ 2013-01-13 15:13 ` Ian Price 2013-01-14 20:51 ` Stefan Israelsson Tampe 1 sibling, 1 reply; 19+ messages in thread From: Ian Price @ 2013-01-13 15:13 UTC (permalink / raw) To: Nala Ginrut; +Cc: guile-devel 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" ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Guile Lua 2013-01-13 15:13 ` Ian Price @ 2013-01-14 20:51 ` Stefan Israelsson Tampe 2013-01-14 21:02 ` Ian Price 0 siblings, 1 reply; 19+ messages in thread From: Stefan Israelsson Tampe @ 2013-01-14 20:51 UTC (permalink / raw) To: Ian Price; +Cc: guile-devel [-- 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 --] ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Guile Lua 2013-01-14 20:51 ` Stefan Israelsson Tampe @ 2013-01-14 21:02 ` Ian Price 0 siblings, 0 replies; 19+ messages in thread From: Ian Price @ 2013-01-14 21:02 UTC (permalink / raw) To: Stefan Israelsson Tampe; +Cc: guile-devel [-- 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))) ) ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Guile Lua 2012-11-21 13:25 ` Ludovic Courtès 2012-11-21 15:51 ` Stefan Israelsson Tampe @ 2012-11-23 3:45 ` nalaginrut 1 sibling, 0 replies; 19+ messages in thread From: nalaginrut @ 2012-11-23 3:45 UTC (permalink / raw) To: Ludovic Courtès; +Cc: guile-devel 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’. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Guile Lua 2012-11-19 2:30 ` nalaginrut 2012-11-19 21:07 ` Ludovic Courtès @ 2012-11-20 0:24 ` Ian Price 2012-11-20 6:12 ` Daniel Hartwig 1 sibling, 1 reply; 19+ messages in thread From: Ian Price @ 2012-11-20 0:24 UTC (permalink / raw) To: nalaginrut; +Cc: guile-devel 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" ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Guile Lua 2012-11-20 0:24 ` Ian Price @ 2012-11-20 6:12 ` Daniel Hartwig 0 siblings, 0 replies; 19+ messages in thread From: Daniel Hartwig @ 2012-11-20 6:12 UTC (permalink / raw) To: guile-devel 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> ^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2013-01-14 21:02 UTC | newest] Thread overview: 19+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2012-11-17 16:30 Guile Lua Ian Price 2012-11-19 2:30 ` nalaginrut 2012-11-19 21:07 ` Ludovic Courtès 2012-11-20 4:50 ` nalaginrut 2012-11-20 11:25 ` Ian Price 2012-11-20 17:04 ` Ludovic Courtès 2012-11-21 2:40 ` nalaginrut 2012-11-21 3:20 ` nalaginrut 2012-11-21 13:25 ` Ludovic Courtès 2012-11-21 15:51 ` Stefan Israelsson Tampe 2013-01-12 8:43 ` Nala Ginrut 2013-01-12 14:37 ` Noah Lavine 2013-01-12 15:25 ` Nala Ginrut 2013-01-13 15:13 ` Ian Price 2013-01-14 20:51 ` Stefan Israelsson Tampe 2013-01-14 21:02 ` Ian Price 2012-11-23 3:45 ` nalaginrut 2012-11-20 0:24 ` Ian Price 2012-11-20 6:12 ` Daniel Hartwig
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).