Lambda the Ultimate

Virgin symbols in muSE have the property that they evaluate to themselves. Therefore when creating the closure "f" in your example, the symbol "y", which is undefined, evaluates to itself.

So yes, you're right in that undefined symbols are considered dynamically scoped. This allows muSE to accept named forward references, which include recursive functions.

For the large part of muSE, I've used the cheapest, simplest, easiest technique I could think of ... and now and then the coolest :) ... and a general principle is "never really prevent anyone from doing anything unless you absolutely can't satisfy them". For example, you can use an expression like -
(1 2 3 4 5)
It'll simply treat it like
(list 1 2 3 4 5)
though it'll warn you about it. I've found this feature useful when using muSE as a file format.

muSE, in general, bares its internals unless it doesn't make sense. You can use (print f) or (write f) to see what f actually does. You can then compare it with a definition using fn:.

Nice idea with the and it. I hope you find a way to speed it up by 8x! :)

I think that would be nice in scripting languages like Applescript, going to suggest it to Apple.

I like the way AppleScript code looks and you're right in that this way of looking at the and it might add to its current elegance. I find it very handy in the REPL to recall earlier results rather than use $0, $1 or some warts like that :) Here is one particular form I've taken a liking to -

> (open-file "somefile.scm" 'for-reading)
> (read (the open-file))
.....do something with (the read)
> (close (the open-file))

dynamic-wind might help ;-)

i'm going to keep this trick in mind :) interesting perspective - wonder what other natural language cues (contextual or not) make sense. for example, declension in russian allows arbitrary ordering of terms, which shows up in ways to show infix vs prefix operators. then again, connotation does change depending on ordering...

Another trick from Russian (and many other languages, old forms of English included) is to have personal pronouns of different genders applicable to inanimate objects - thus, instead of just "it", one can have "it", "she" and "he" (in some languages more). Even in modern English, boats and other objects can be "she" :)

This trick gives you more short forms, but in a quite ad hoc way - quick, is "find" he or she? One may replace genders by types - but this is essentially another form of "the", or kinds - Perl funny characters come to mind. @it anyone? :)

Returning to the general idea of borrowing ideas from natural languages - I think isolating languages are closer to what is feasible for a PL given the state of art (and the expectations of the community). Next are agglutinative languages, which only involve a bit more lexing. Modeling a syntax of a PL on a fusional language (Russian being quite typical representative) is a controversial idea, though (refactoring without a specialized tool becomes close to impossible - you cannot search and replace, for example).

I remember programming in BASIC with cyrillic keywords, but that was definitely far from Russian language :)

Declension might just be a special case of keyword arguments, no? For example -

; pseudo code
(open a:file called:"blah.txt" for:reading)
(print on:stdout (expr 3 of:(the open file)))
(close (the open file))

As for dynamic-wind, it will be nicer in muSE once I implement capturing (the ..) expressions within closures. You can write it the following way -

(try
 (do (open-file "blah.txt" 'for-reading)
     (finally (close (the open-file)))
     (read (the open-file))
     ; ... do something with (the read)
     ))

and the close will be evaluated when the try block completes - normally or exceptionally.

edit: ExceptionHandling in muSE - try, raise, retry and finally.
edit: The above (try ...) code will work in v454.

Looks nice! Did anyone look at the tutorials and has opinions to share?

Btw, I posted about this on the PLT mailing list too, it being a Scheme-specific community.

.. and a big yes to comments! I'm looking for feedback to improve the DSL itself and the documentation and tutorials, and suggestions for tools built atop the DSL to make this kind of "programming" more accessible to artists. Pointers to other work of this kind are also welcome. Even for newbies, it is just plain fun to write scheme code for visual effects in a 3D environment as opposed to, say, the fibonacci function ;)