Examples of some pleasant little syntax tricks for working with range and sequence objects in the Groovy language, which runs on top of Java and its class library.
Interesting reference material: it seems obvious in retrospect, but it had never occurred to me that the process of rendering a floating-point number into a string was the sort of project people might write papers about.
Here’s something I bet you never think about, and for good reason: how are floating-point numbers rendered as text strings? This is a surprisingly tough problem, but it’s been regarded as essentially solved since about 1990.
References to the “Dragon4″ algorithm, and to a recent improvement, “Grisu3″.
Comparing language performance and memory usage in C and Python, using a simple program to remove duplicate lines from a text file.
Radian’s current feature set ought to be enough to build this test; I wonder how it would stack up.
Multicore Garbage Collection with Local Heaps, by Simon Marlow and Simon Peyton-Jones:
In a parallel, shared-memory, language with a garbage collected heap, it is desirable for each processor to perform minor garbage collections independently. Although obvious, it is difficult to make this idea pay off in practice, especially in languages where muta- tion is common. We present several techniques that substantially improve the state of the art. We describe these techniques in the context of a full-scale implementation of Haskell, and demonstrate that our local-heap collector substantially improves scaling, peak performance, and robustness.
Bruno Jouhler’s Yield – Resume vs. Asynchronous Callbacks – An Equivalence continues a series of interesting explorations on asynchronous behavior using JavaScript.
Y-R Javascript is a small extension to Javascript. It introduces a new operator that can be applied to function definitions and function calls. The @ sign is the yield and resume operator. When present in a function definition, it means that the function executes asynchonously. Somewhere in its body, the function yields to the system and the system calls it back with a result or an error. It may actually yield and resume more than once before returning to its caller. I will call such a function an asynchronous function, in contrast with normal Javascript functions (defined without @) that I will naturally call synchronous functions.
In this post I want to investigate the relationship between this fictional Y-R Javascript language on one side and Javascript with asynchronous callbacks on the other side.
I will show that any program written in Y-R Javascript can be mechanically translated into an equivalent Javascript program with asynchronous callbacks, and vice versa.
PEP 3151 takes a look at the organization of exception classes in the Python library and suggests a new, more useful arrangement.
While Radian has an exception mechanism, I have thought very little about an organization of exception objects yet. Radian doesn’t really have a class hierarchy, so it’s not clear how I would replicate the Python approach, much less a system like Java. It seems like exception values ought to have a type identifier as well as some data chunk; perhaps I’ll define an “exception” object with those two fields, then use a set of well-known symbols for the type identifiers.
Not sure why I have never noticed the ooc language before, but its buzzword list is well chosen: “Object-Oriented, Functional, Concurrent, Modular, Portable – Awesome!”. The syntax is a trifle funky but not hard to pick up. Looks like the language is developed to the point that they have written a self-hosting compiler, which is a pretty neat milestone.
P4P is an alternate syntax for Racket, a descendant of PLT Scheme. The Lisp-derived S-expression syntax is notoriously inaccessible to the uninitiated, and there have been many attempts to devise equivalents which demand less mental decoding. This one is noteworthy because the author’s prose is clear and reasoning sensible; there are some interesting points which apply to syntax design in general. Specifics that caught my eye:
Racket has a excellent language design, a great implementation, a superb programming environment, and terrific tools. Mainstream adoption will, however, always be curtailed by the syntax. Racket could benefit from liposuction, stomach stapling, or just plain getting off the couch and getting out for a ride, to reduce the layers of parenthetical adipose that – as this document argues, needlessly – engird it. P4P is a proposal for how to do this without losing the essential nature of the Lisp syntactic heritage (and, indeed, bringing to the surface the streaming nature that has always been hidden within).
I increasingly view emphasizing good indentation as critical. In some languages, however, indentation controls semantics. I view this as a mistake.
In P4P, instead, the semantics controls indentation: that is, each construct has indentation rules, and the parser enforces them. However, changing the indentation of a term either leaves the program’s meaning unchanged or results in a syntax error; it cannot change the meaning of the program. I believe this delivers the advantages of enforced indentation while curbing its worst excesses.
P4P does not have any optional syntax. I believe this makes it easier to teach people to program: they want clear instructions, not “You can do this, or you can do that…you can do whatever you want!” (If they were ready to do whatever they wanted, they wouldn’t be asking you.) These trade-offs are best left to semantic and design levels, not syntax.
I suppose I like this essay in no small part because the author’s preferences agree with mine. It is a careful, regular transliteration of syntax only, with no semantic consequences, and thus its value exists solely in the realm of aesthetics. I care a lot about aesthetics, so this looks like a good thing to me.
Radian takes the same attitude toward indentation, incidentally: instead of using indentation to drive structure, as in Python, the compiler uses structure to validate indentation. The result is similar, in that one’s programs must always be indented correctly, but the meaning comes from the code and not the whitespace. Among other things this means that automatic reindentation is possible.
A number of web sites offer comparisons of the same task implemented in different programming languages: