With the most recent commits (4.4.4), chicken is now consistent in the way core forms are handled. There are no hard-coded special forms and everything can be redefined, reexported and modified on import. Syntax may now also expand into module forms (if at toplevel, local or nested modules are still not available and not strictly necessary).
So, the transition to hygienic macros and a real module system is hereby complete…
— Felix
In this thread the OP discusses implementing Lua on top of Guile as an extension language. It seems that it might be eligible for Google’s SOC sponsorship. While the OP doesn’t mention wanting help, it is interesting, and who knows other folks might like to contribute.
I’ve [Joe Marshall] added `keyword’ objects to MIT Scheme in a way that I hope keeps everyone happy. A keyword is a self-evaluating symbolic token, much like a symbol, but it never needs quoting because it can never mean anything but itself.
The reading and printing of keywords is controlled by the variable *keyword-style*, which can be #f or one of these symbols: cl, dsssl, srfi-88, both
If *keyword-style* is #F (the default), then there is no way to read keywords, and they are printed as #[keyword foo].
If *keyword-style* is ‘cl, then tokens with a leading colon are considered keywords and keywords are printed with a leading colon. Symbols with a leading colon are printed with vertical-bar quotes
and you can create symbols with leading colons by using vertical-bar quotes.
If *keyword-style* is ‘srfi-88, then tokens with a trailing colon are considered keywords and keywords are printed with a trailing colon. Symbols with a trailing colon are printed with vertical-bar quotes and you can create symbols with trailing colons by using vertical-bar quotes.
‘dsssl is a synonym for ‘srfi-88
If *keyword-style* is ‘both, then either syntax is acceptable for reading, but the cl syntax will be used in printing. (Putting a colon on both ends would be weird, so don’t.)
(via MIT-Scheme-devel)
Over the weekend I needed to set up a R6RS Scheme interpreter on Cygwin. It came down to either PLT or Ikarus. Both seem to be straightforward builds but I couldn’t make PLT happy so I went with Ikarus instead. It was a very simple and straightforward configuration and took maybe a minute to build. Once things were clearly working fine I figured I would try to get some of Ed’s OpenGL (box2d-lite and agave) demos running just for the fun of it.
Both of the programs depend on the GL and GLUT libraries. At runtime the correct DLL is loaded depending on the OS type. There wasn’t a setting for Cygwin so I added one. The thing was that I specified the wrong file name: /usr/lib/libGL.dll.a and /usr/lib/libglut.dll.a.
It was an uneducated guess in the first place. I figured there would be a one to one mapping. After Marco kindly kicked my butt on the Ikarus list though, by asking some basic questions like has it ever worked and have I checked out the difference in error messages, I got me thinking that I should have read up on this.
The Cygwin documentation here and the Redhat documentation here seem to explain it… Windows DLLs need additional information to be linked against. On Cygwin, when GCC sees .dll.a files it “knows” how to get the additional data out of them in case you want to link to Win32. Reading on in the Redhat documentation, it lists the DLL search path when you specify -L argument for GCC. In that list I saw that /bin is included. That surprised me.
It turns out that on Cygwin, DLLs that are not compiled to work with Win32 are located there. At least, this is my understanding. When you link to these DLLs though, the OpenGL demos work just fine on Cygwin with Ikarus.
Is this also your understanding? I need to dig in more to this topic.
I had been trying to get so many things working this weekend that I didn’t invest the amount of the time that this deserved, or most of those things for that matter.
Here is a link to a post on plt-dev about Russian and Ukrainian localization files for DrScheme.
They live here: russian-string-constants.ss and ukrainian-string-constants.ss.
ParEdit (paredit.el) is a minor mode for performing structured editing of S-expression data. The typical example of this would be Lisp or Scheme source code.
ParEdit helps keep parentheses balanced and adds many keys for moving S-expressions and moving around in S-expressions.
That quote from EmacsWiki really undersells Paredit, though.
Paredit makes it virtually impossible to un-balance parentheses (aka round, square, and curly brackets).
This mode would be especially interesting for folks avoiding Lisp because of the nightmare of balancing parentheses is too much of an obstacle to overcome (in practice of course it really isn’t, even if you don’t use Paredit).
Here is a nice review of Scheme modes for Emacs.
In the early 2000s Sun published The Java Developers Almanac. It was a basically a listing of code snippets explaining how to perform the most common operations that developers might want to accomplish at his “day job”. You can find examples of the examples here.
It was great for the language; it made it easy for loads of developers to get productive quickly. While something like this can certainly be abused via copy-and-paste; you can also use it to learn. Hopefully a lot of developers did learn. I wonder if something like this would be interesting for the RNRS world?
The reason is that the revised reports are just that: reports. They are not standards in the sense of the Common Lisp standard. Rather they are a report of the commonalities across different Scheme implementations.
The features provided by R6RS make it is a tad more convenient to write “portable” code. In light of that, I wonder if it would be of any value to have a sort of Scheme developers almanac written only using R6RS code for example. Things like this exist today with Schemewiki, and nearly every individual distribution, but, it might be nice to see how much you can do with only what the report provides along with the libraries that folks have implemented on top of it.
Here is a collection of email lists for some popular Scheme distributions.
There are plenty of indexes of Scheme distributions out there; but all that I wanted was a convenient index to all of the active email lists.
