• Untyped thoughts, and design thoughts

    Wed, 05 Mar 2008 23:23:38 +0000

    Today, I met in London the fellow guys from Untyped in a pub near Queen Mary University, London, where they gave a talk on a project they've been working on for a department. I had first met them at the ICFP and Scheme Workshop 2007 and it's been a pleasure to see them again (though timing made the encounter brief). I hope to see them again, and wish the best for their company.


    This brings me to my personal wish for the evolution of Scheme. Many have argued that R6RS is bad, others that it is great, and a one even told me once "you know, I was already against the idea of R4RS". Which sums up well how fragmented our community is. I think that Scheme (or its potential successor) could tend to an agreement that would make both major groups feel happy, especially me. For the sake of ease, I will use the name Scheme, though it refers to my desired descendant of it.


    Scheme is simple, and has to stay simple.

    I really enjoy the minimal set defined by R4RS and R5RS, and would base the kernel of our language on this design. All implementation that would provide this kernel would be said to be kernel compatible, and this would be the condition sine qua none to be called Scheme.


    Scheme is powerful

    Because the kernel is, by design, very minimal, many things that one would definitely expect from a language to use daily have to be implemented, in what I would call the extended part of Scheme. Implementers would be advised to add to the language features like the full numerical tower, hash table, sets, various sorts on various data structures (that is, lists and vectors), not forgetting unicode (which is to text what the numerical tower is to numbers). With Scheme-extended, the point is to have immediately all the algorithmic tools to easily solve any problem, without having to load libraries, or even write them for the SRFIs are not always implemented.


    Scheme is usable

    Scheme isn't very useful when it comes to side effects. I would appreciate that the interaction layer was recommended too. This layer would provide everything needed to have programs that effectively do something else than pure computation. Here, we shall find functions to handle files and streams (open, read, close, but also append, prepend, seek, pipes, STDIN/OUT/ERR, etc.), network with sockets, time, command line (arguments, own name...), OS primitives with respect to the host (fork, PID, list directory...). All this should give the programmer the possibility to fully interact with the operating system and to manipulate some data easily.


    Scheme is reusable

    Let's face it, a nice module system is helpful. Following the modular recommendations would provide a Scheme where this module system is present.


    Scheme is unlimited

    Even given all the previously (not exhaustive) enumerated principles, many tasks remain unpleasant for most nowadays programmers. The SRFI's or (a modified) Snow should become the repository of choice à la CPAN, where programmers would upload their handy tools, like a regular expressions engine, a syntactical analyser, a calendar converter... But, in the spirit of the original SRFI, the could upload design addenda, as new primitives that can only be added by modifying the interpreter or the compiler, such as non blocking I/Os (which I would place in the interaction part, but this is an example of what can't be written as a Scheme userland program).


    Scheme is above all your own language

    Apart from the kernel, no part would be compulsory. Just enough recommended, in order to have a real portability between implementations. However, one should not consider those parts as layers stacked on top of each other, and should be free to provide only interaction without extended, or modular and extended without interaction. One could immediately know what Scheme suits him well by looking at which of the aforementioned design features are supported. And this is what, to me, keeps the legitimacy of the implementer in his choices of design, and lets him write and use the Scheme he needs, as it is one of the greatest powers of our beloved Scheme.


    Is it too late to make ERR5RS be like that? Do you appreciate these suggestions? Let me know.