Menu
▾
▴
tinyscheme-issues
|
From: Peter M. <pet...@gm...> - 2009-06-13 03:37:17
|
Hi, I've been reading the Tiny Scheme code in detail. At about 40% though it, it has been a fun read so far. I'm curious about the status of the project. I have found some things in the code that either I misunderstand or that are errors. I'd be willing to type up the issues if there is a chance of discussion and perhaps changes to the code base. I see in the archives of this mailing list that there haven't been many messages so I'll hold my fingers steady until it is worth starting them. Peter |
|
From: Tom B. (Tehom) <te...@pa...> - 2009-06-13 20:54:25
|
Peter's message made me think about this: Where are we going with TinyScheme? Some suggested goals: * Complete the R5RS compliance, wrt reusable continuations, unwind-protect, etc. * Begin R6RS compliance. * Create a test suite. * Streamline existing code. * Shrink it further if possible. * Make it faster. Comments, questions? Tom Breton (Tehom) |
|
From: Peter M. <pet...@gm...> - 2009-06-13 21:10:04
|
Hi Tom, Thanks for your replies. On Sat, Jun 13, 2009 at 1:54 PM, Tom Breton (Tehom)<te...@pa...> wrote: > Peter's message made me think about this: > > Where are we going with TinyScheme? Some suggested goals: I was going to ask for a list just like this. > * Complete the R5RS compliance, wrt reusable continuations, > unwind-protect, etc. Complete R5RS support makes sense. > * Begin R6RS compliance. It seems R6RS was still born. I believe R7RS will take R5RS as its starting point. > * Create a test suite. Yes that would be great. > * Streamline existing code. > > * Shrink it further if possible. I think this is the easiest place to start. I think some of the old compilation targets could be dropped to simplify the code. Personally I think requiring an ANSI C compliant compiler and the ANSI C standard library available would be a perfect target. It seems to me Tiny Scheme only needs the ANSI C standard library. Tiny Scheme could be platform independent. > * Make it faster. Yes. I haven't done any speed tests but Tiny Scheme has a reputation on irc.freenode.net#scheme of being slow. I think the following are worthwhile. * a "namespaced" api for easier embedding. Something like a "scm_" prefix on all names in the scheme.h header. * detangle the repl from the Scheme engine. The engine could be shrunk this way and a stronger embedding api on the engine could be created. * line and column numbers in error messages. * documentation in the code. * format the code per K&R style. The use of whitespace in the Tiny Scheme code is widely varied. Peter |
|
From: Kevin C. <ke...@ve...> - 2009-06-14 04:21:00
|
Peter Michaux wrote: > I've been reading the Tiny Scheme code in detail. At about 40% though > it, it has been a fun read so far. > > I'm curious about the status of the project. I have found some things > in the code that either I misunderstand or that are errors. Hello, Peter. The project isn't dead. It just hasn't been very active of late. I haven't spent much time delving in to the innards of TinyScheme but I would be interested to know what you have found. |
|
From: Kevin C. <ke...@ve...> - 2009-06-14 04:35:50
|
Tom Breton (Tehom) wrote: > * Complete the R5RS compliance, wrt reusable continuations, > unwind-protect, etc. > > * Create a test suite. > Regarding the above two points, I have a pair of files which perform R4RS and R5RS compliance tests. TinyScheme does not successfully pass all the R4RS tests. The R5RS test suite will not run with TinyScheme as it uses features (e.g. define-syntax, IIRC) of R5RS which are unimplemented in TinyScheme. > * Streamline existing code. > > * Shrink it further if possible. > > * Make it faster. > > Not sure the difference meant here by streamlining the code vs. making it faster. It could definitely use some changes to make it run faster. When tracing code execution of TinyScheme, I see it wasting a lot of time going through a certain portion of the code repeatedly with nothing to show for it before finally doing something productive. > Comments, questions? > > It would be very helpful to be able to report file/line/character position when giving error messages. This would probably require extra memory to track the information, so it should probably be made a compile time option. |
|
From: Tom B. (Tehom) <te...@pa...> - 2009-06-15 02:11:11
|
> Tom Breton (Tehom) wrote: >> * Complete the R5RS compliance, wrt reusable continuations, >> unwind-protect, etc. >> >> * Create a test suite. >> > Regarding the above two points, I have a pair of files which perform > R4RS and R5RS compliance tests. TinyScheme does not successfully pass > all the R4RS tests. The R5RS test suite will not run with TinyScheme as > it uses features (e.g. define-syntax, IIRC) of R5RS which are > unimplemented in TinyScheme. So define-syntax is a major piece we're missing. Do you want to add it? >> * Streamline existing code. >> >> * Shrink it further if possible. >> >> * Make it faster. >> >> > Not sure the difference meant here by streamlining the code vs. making > it faster. It could definitely use some changes to make it run faster. > When tracing code execution of TinyScheme, I see it wasting a lot of > time going through a certain portion of the code repeatedly with nothing > to show for it before finally doing something productive. What it's mostly doing is evaluating macros over and over again. As I posted, I'll add *compile-hook* to deal with that. > It would be very helpful to be able to report file/line/character > position when giving error messages. This would probably require extra > memory to track the information, so it should probably be made a compile > time option. Yes. Do you want to add that too? Tom Breton (Tehom) |
|
From: Tom B. (Tehom) <te...@pa...> - 2009-06-15 01:25:26
|
> Hi Tom, > > Thanks for your replies. > > On Sat, Jun 13, 2009 at 1:54 PM, Tom Breton (Tehom)<te...@pa...> > wrote: >> Peter's message made me think about this: >> >> Where are we going with TinyScheme? Some suggested goals: > > I was going to ask for a list just like this. > >> * Complete the R5RS compliance, wrt reusable continuations, >> unwind-protect, etc. > > Complete R5RS support makes sense. I'll add unwind-protect. Reusable continuations will take longer. >> * Begin R6RS compliance. > > It seems R6RS was still born. I believe R7RS will take R5RS as its > starting point. I did not know that. I've been following it peripherally, but I was under the impression that R6RS was ratified a few months ago. >> * Create a test suite. > > Yes that would be great. > >> * Streamline existing code. >> >> * Shrink it further if possible. > > I think this is the easiest place to start. > > I think some of the old compilation targets could be dropped to > simplify the code. Personally I think requiring an ANSI C compliant > compiler and the ANSI C standard library available would be a perfect > target. It seems to me Tiny Scheme only needs the ANSI C standard > library. Tiny Scheme could be platform independent. > >> * Make it faster. > > Yes. I haven't done any speed tests but Tiny Scheme has a reputation > on irc.freenode.net#scheme of being slow. Yes, it is quite slow. I have a few ideas for making it faster. IMO the easiest right now is to add a *compile-hook* and call it when evalling a lambda. It could be defined in init.scm. It would at least expand macros so we don't re-expand the macro every time thru, which is what we do now and what takes the most time (from following it by eyeball in the tracer, since a C profiler just tells us that Eval_Cycle is called a lot) > I think the following are worthwhile. > > * a "namespaced" api for easier embedding. Something like a "scm_" > prefix on all names in the scheme.h header. We do use scheme_* for some things, but not as consistently as it might be IIRC. > * detangle the repl from the Scheme engine. The engine could be shrunk > this way and a stronger embedding api on the engine could be created. Maybe. But it also does the file loading. File loading is done almost as a REPL but without printing. It's all done thru OP_TOPLEVEL. About a year ago, I went thru that code and made file loading and true top level stop stepping on each others' toes. Now the special interactive behavior is all inside a single "if". I'm not sure it needs more disentanglement than that. > * line and column numbers in error messages. > > * documentation in the code. > > * format the code per K&R style. The use of whitespace in the Tiny > Scheme code is widely varied. I've added a file variable for style control that emacs understands. I don't know enough about other editors to do anything similar for them. One problem is that to emacs, K&R implies 5 space indentation. Tom Breton (Tehom) |
|
From: Peter M. <pet...@gm...> - 2009-06-15 02:09:40
|
On Sun, Jun 14, 2009 at 6:25 PM, Tom Breton (Tehom)<te...@pa...> wrote: >>> * Begin R6RS compliance. >> >> It seems R6RS was still born. I believe R7RS will take R5RS as its >> starting point. > > I did not know that. I've been following it peripherally, but I was under > the impression that R6RS was ratified a few months ago. It was ratified but it seems that it is not sticking the way one might think a ratified spec would be. I suppose this is hearsay. >>> * Make it faster. >> >> Yes. I haven't done any speed tests but Tiny Scheme has a reputation >> on irc.freenode.net#scheme of being slow. > > Yes, it is quite slow. I have a few ideas for making it faster. > > IMO the easiest right now is to add a *compile-hook* and call it when > evalling a lambda. It could be defined in init.scm. It would at least > expand macros so we don't re-expand the macro every time thru, which is > what we do now and what takes the most time (from following it by eyeball > in the tracer, since a C profiler just tells us that Eval_Cycle is called > a lot) I'm also looking at Chibi Scheme from Alex Shinn which is touted to be very fast. http://synthcode.com/wiki/chibi-scheme He claims on a little Fibonacci test he was 100x faster than Tiny Scheme and 2-3x faster than Guile. He also claims he has almost complete R5RS support and that the source is smaller than Tiny Scheme. I've just started reading the v0.1 code now and it is very impressive so far. He was using the Boehm garbage collector which adds a big mess but is changing to a custom precise garbage collector for the v0.2 release that he claims will be out next week. > One problem is that to emacs, K&R implies 5 space indentation. That is odd. Looking in K&R, for a line with one indent, I see four spaces and then the first character in the fifth column. Peter |
|
From: Tom B. (Tehom) <te...@pa...> - 2009-06-15 22:30:38
|
I wrote and committed dynamic-wind. Would've liked to have more tests for it - some of the ones I borrowed from R6RS wanted re-enterable continuations and values. But it passes the others. Tom Breton (Tehom) |
|
From: Kevin C. <ke...@ve...> - 2009-06-15 14:39:16
|
Peter Michaux wrote: > It seems R6RS was still born. I believe R7RS will take R5RS as its > starting point. Are you sure about that? Doesn't seem that long ago that R6RS was accepted. It would seem quite a waste of effort to go back to R5RS. > * line and column numbers in error messages. > I have had comments about the lack of this in relation to the use of TinyScheme in GIMP. > * documentation in the code. > Adding some extra information about how the code operates would be good. There are (or were) some outstanding issues relating to parsing of input code that I was interested in fixing. I like working with parsers but I don't understand the code well enough to get a handle on how to fix the issue. I've had too many other projects on my plate so I haven't gone through the code in any great detail. > * format the code per K&R style. The use of whitespace in the Tiny > Scheme code is widely varied. > Reformatting the code so it is consistent throughout would be good. I wouldn't suggest using K&R as a format. There are better ways, IMO, to format code. For one thing, I don't like the placement of braces in if blocks. Due to my involvement with the GIMP project I find myself having adopted their code formatting. Even running the code through indent with its default parameters would be a first good step. I don't mine having an emacs command added to the TS code. I use vi, and not emacs so it won't make any difference to me. Regarding number of spaces of indent, eliminating tabs in favour of spaces would also avoid some issues about how the code looks in different editors. BTW, I'm just wondering what operating system Peter is using when working on TinyScheme. Be careful in taking out too many casts, and other checks. Some things may seem ok when using Windows but can cause problems in a Linux environment. Eliminating casts in assignments involving mallocs can result in compile time warnings. |
|
From: Tom B. (Tehom) <te...@pa...> - 2009-06-15 22:20:32
|
> Peter Michaux wrote: >> * format the code per K&R style. The use of whitespace in the Tiny >> Scheme code is widely varied. >> > Reformatting the code so it is consistent throughout would be good. I > wouldn't suggest using K&R as a format. OK, it's certainly still open for discussion. What is your preference? Tom Breton (Tehom) |
|
From: Peter M. <pet...@gm...> - 2009-06-15 15:06:07
|
On Mon, Jun 15, 2009 at 7:39 AM, Kevin Cozens<ke...@ve...> wrote: > BTW, I'm just wondering what operating system Peter is using when > working on TinyScheme. I'm using OS X. More importantly, I think Tiny Scheme could require an ANSI C compliant system and that wouldn't be too high a requirement. Peter |
|
From: Tom B. (Tehom) <te...@pa...> - 2009-06-15 22:13:21
|
> On Mon, Jun 15, 2009 at 7:39 AM, Kevin Cozens<ke...@ve...> wrote: > >> BTW, I'm just wondering what operating system Peter is using when >> working on TinyScheme. > > I'm using OS X. More importantly, I think Tiny Scheme could require an > ANSI C compliant system and that wouldn't be too high a requirement. Well, I'm not sure that should be a priority. The benefit, I assume, is to get rid of the little nest of #ifdef __APPLE__ etc. The risk, introducing errors that only show up on some platforms. It would be a shame to make any working systems unsupported. But I have no data on whether any non-ANSI systems are being used to compile TS. Tom Breton (Tehom) |
|
From: Tom B. (Tehom) <te...@pa...> - 2009-06-17 19:41:01
|
> > I'm also looking at Chibi Scheme from Alex Shinn which is touted to be > very fast. > > http://synthcode.com/wiki/chibi-scheme > That is pretty amazing. Here, I was wondering if I dare suggest a major change like adding a virtual-machine and compiling to that - and this guy's already coded the whole thing, on top of something that looks like the Tinyscheme code base. > He claims on a little Fibonacci test he was 100x faster than Tiny > Scheme and 2-3x faster than Guile. He also claims he has almost > complete R5RS support and that the source is smaller than Tiny Scheme. The source is not smaller. But most of his is in the gc and cords, and a fair bit in reading and writing sexps. Still, it makes me question what I'm doing. Tom Breton (Tehom) |
|
From: Peter M. <pet...@gm...> - 2009-06-17 20:09:10
|
On Wed, Jun 17, 2009 at 12:40 PM, Tom Breton (Tehom)<te...@pa...> wrote: > That is pretty amazing. Here, I was wondering if I dare suggest a major > change like adding a virtual-machine and compiling I was thinking of suggesting this for Tiny Scheme also but then I found out about Chibi. > to that - and this > guy's already coded the whole thing, on top of something that looks like > the Tinyscheme code base. > >> He claims on a little Fibonacci test he was 100x faster than Tiny >> Scheme and 2-3x faster than Guile. He also claims he has almost >> complete R5RS support and that the source is smaller than Tiny Scheme. > > The source is not smaller. But most of his is in the gc and cords, and a > fair bit in reading and writing sexps. He is replacing the Boehm conservative gc with a custom precise gc. The 0.2 release should be out this week. I think the code base for Chibi and Tiny Scheme will be about the same size. Peter |
Thanks for helping keep SourceForge clean.
X