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

Goal

Main design concepts and objectives

• Minimal core
• Extensions
• Bootstrapping code, even in the core, with dual implementation of code
  1. in the scripting language core
  2. optionally implementation in native code for efficiency
• Fast
• Small
• Multiple platforms and implementation languages : should be doable efficiently in C and Java. (Having several implementations should/might help portability. Now obviously it will be much faster with today C compilers than with today VM technology but it should be usable in both, and once you discount the vm overhead, the Java should not be much less efficient. This is for sure not applicable for the PalmPilot version but just a way to potentially have a(nother) cool scripting language for java. This might be asking too much contortions with the other goals though, that's why it's almost the last one in the list (read might be dropped first))
• Compatibility (with Tcl...) is desirable but not at the expense of making complex, ugly,.... system.

Coding 'rules'

• No code duplicate
  • If you write something twice, start asking yourself about generalization and taking common part (or re-thinking the design).
  • Never write something 3 times. Generalize, re-think.
• Beauty and simplicity of the code whenever possible
• Try to avoid overkill design or over generalized but prefer overkill to ugly!

Questions, issues

• Object system :
  • explicit destruction or garbage collection ?
  • multiple types simultaneously ?
  • avoid shimmering ?
    (An artifact of the current Tcl 8.x object system where object shimmers between 2 (or more) internal types depending on their use. Example :
    set a 3
expr {$a+1} ; # a's internal rep is now int
lindex $a 0 ; # a's internal rep is now a list, int is lost
(obviously this might be a semantic error, but you can (too) easily construct semantically valid tcl scripts which will involve repeated objects internal rep shimmering (in loops...)))
• Object oriented methods/callbacks instead of traces ?
  • events
• Typed ? (should)
• Closures ?
• Time needed ? Man power ?

Interested ?

Q & A

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.