Super/Simple/Small/Safe Tool Command Language (STCL)
aka YASL: yet another scripting language
Fantasy by Laurent Demailly (

Alpha Draft 0.1.2 - Last update: Tue Sep 29 1998 - Check for updates on


Take the lessons of recent Tcl development and redesign critical aspects to get a smaller, simpler, safer scripting language, suitable for "scripting everywhere".

Main design concepts and objectives

Similar goals were probably also set at the origin of other scripting languages but I'm pretty sure that some were missing or different and that a lot of those goals, even if originally present, were lost during development and (normal) evolution of the projects (an interesting issue would be to study why and how those goals sets evolved...). I'm just wondering how realizable it would be to stick to those goals and what result it would produce. We will try to do better this time thanks to the concrete lessons learned from previous scripting languages: For instance, Tcl, though an embedded / extension language is not modular enough and does not have a small core. Why ? Partly because until recently it was built by successive improvements over a monolithic core. Also because it is very hard when you have limited resources (and who hasn't) to make cleaning up and splitting in pieces a priority versus just adding the new features everybody wants (that is until we get some magic where people can more easily add and share and interoperate the features themselves and core people can concentrate on meeting the extensibility goals and making sure that people doing extensions can do their job instead of doing (only some) of features...).

Coding 'rules'

Questions, issues

Interested ?

Send me comments, critiques, flames,... or participate or read the scripting language for small devices like the PalmPilot discussion forum, see pointers and subscribe form on my Main Tcl page.

Q & A

Questions and feedback I received so far (Thanks to J Adrian Zimmer!), and Answers:
Why use Tcl as your starting point?
Familiarity for sure, an intention to rebuild existing code rather than start anew, in the sense that if we can make it compatible, or if we have a 'translator' (more likely to avoid nasty compromises of the other goals) we could re-use a lot of code and cool stuff. Also Tcl (and extensions) code base can be a big source of inspirations.
Why not make it more like Python?
But then, why not just port python ? that's another project. On the other hand, inspiring from python's ideas is certainly a good thing.
Wouldn't a typed Tcl be an abomination ? (Don't misunderstand the question, typed languages are good but I also like Tcl for it's lack of typing and I feel to add typing would be to remove the soul of the language)
That's interesting. It is a bit hard to come up with a good example, specially with Tcl syntax and background in mind (and that's maybe your point) but I think I would be comfortable that
set f [open "x.txt"]
expr {$f+1}
would error out saying that 'f' is a "file" object which can't be evaluated as an expression (ideally at compile time); Likewise for some string<->list silent conversions. (maybe you'd want a perl'ish flag to automatically enable translation from types to types, maybe even on by default (for backward compatibility) but having built in (early) type checking would greatly improve the reliability of scripts (not counting security).

Also I don't think Incr Tcl for instance removes the soul of Tcl... I'd rather say it lifts it. © 1994-2009 Laurent Demailly, Last update: Tue Sep 29 1998