

Tcl/Tk 8.6 released (now stackless, w/coroutines, tailcalls, and more) - anoved
http://www.tcl.tk/software/tcltk/8.6.html

======
rikthevik
Tcl Rule 1: Everything is a string. Tcl Rule 2: See rule 1. Tcl Rule 3: Not
joking.

~~~
iso-8859-1
It's not a problem in Bash, why is it a problem here? Right tool for the
job...

~~~
cageface
Because most people have enough sense to keep bash scripts to a few hundred
lines at most and switch to a saner language for anything more complex. In a
language like TCL intended for larger-scale development it's just a bugfest
waiting to happen.

It's kind of a moot point though. Javascript is unstoppable in the extension
language space now.

~~~
oddthink
Really? I've never seen it used as an actual extension language. I've seen
Lua, I've seen Scheme, at work we do everything in Python (but that's more
extending than embedding), but I've never seen JavaScript as a "extend this C
or C++ application" language.

I'm not counting node, because it only exists to run JavaScript. Nor am I
counting web browsers, for similar reasons.

Can you give some examples? PDF is the only one I can think of. Most of the
existing JavaScript engines seem too heavy-weight to be used as extensions.

Since I'm not in the web-developer bubble, I just don't see JavaScript all
that often.

~~~
wreckimnaked
Embedding Javascript is fairly easy with Qt[1], so I assume that many
applications built on top of it may use it.

1: <http://doc.qt.digia.com/qt/qdeclarativejavascript.html>

~~~
oddthink
Thanks for the link; I'd forgotten about Qt and JavaScript, which is funny,
since I was just thinking about learning it.

------
to3m
The explicit tail calls look pretty neat. All languages should include this,
or something like it, I think; tail calls come in handy for all sorts of
things. Making it explicit sidesteps complaints about how it will impede
debugging, and ensures programmers will definitely get it where they
want/expect.

I think this would be a chance to rehabilitate the much-maligned GOTO keyword.
But "tailcall" is probably just as good.

~~~
michaelhoffman
Python language creator Guido von Rossum prevents CPython from having tail
call optimization because he doesn't want people to use it.

[http://neopythonic.blogspot.com/2009/04/tail-recursion-
elimi...](http://neopythonic.blogspot.com/2009/04/tail-recursion-
elimination.html)

~~~
yfyf
I wonder if he would claim the same argument today as he does in this[1]
comment, in particular the paragraph "On side effects being bad <..>".

I would dare to claim that there's some trend to do things more side-
effectlessly not only in programming, but also in general, people in IT are
finally realizing* that the more isolated, light-weight and modular things are
(think of increased interest in functional programming (pure functions),
dominance of cloud-based/inspired solutions (spinning up small instances of
VMs)) the better. Somehow this particular mindset helps at all levels.

Hah, there's actually a term for what I'm trying to describe: Shared nothing
architecture[2]. Allowing side-effects on any level implies "sharing" to me.

[*]: of course you could say "this has always been the case", but somehow some
years ago Java and the friends seemed like the only "enterprise level"
solution to most businesses and the general fat-stack+vertical-scaling seemed
somewhat reasonable.

[1]: [http://neopythonic.blogspot.nl/2009/04/tail-recursion-
elimin...](http://neopythonic.blogspot.nl/2009/04/tail-recursion-
elimination.html?showComment=1240451280000#c1726520516547497765) [2]:
<http://en.wikipedia.org/wiki/Shared_nothing_architecture>

~~~
mahmud
I don't think the world of software development changed at all since 2009. It
takes about 15 years to see noticable shifts in practices.

Also, shared-nothing "architecture" goes back to the 60s with the first
investigations into concurrency. In fact, if I were being pedantic, I would
say it predates computing itself: logic is all side-effect free.

~~~
yfyf
Sure, theoretical investigations on things begin many years earlier than
anyone starts actually using them, but somehow "concurrency" wasn't something
available to your everyday Joe back in 60s, right? Multi-core wasn't the norm,
there was no elastic cloud, what so on.

And I am not really claiming that software development changed much in 3
years, but I think people's mindsets are changing faster than that, especially
of those who are actively involved in thinking about these things.

~~~
mahmud
Fair point.

------
ademirar
Congrats, Tcl/Tk team! A long wait, but it seems to be worth.

------
andrewcooke
that's an impressive set of changes for a minor release! :o)

is there a paper that describes the underlying implementation (with the new
stackless stuff)?

~~~
anoved
I don't know of a paper, but on the Tcl wiki there is some discussion of the
"non-recursive evaluation" (NRE) engine that enables these features [1]. More
formal descriptions of the new coroutine [2] and tailcall [3] commands are
listed, among others, here [4].

1\. <http://wiki.tcl.tk/37253#pagetocbefb5a57>

2\. <http://www.tcl.tk/cgi-bin/tct/tip/328>

3\. <http://www.tcl.tk/cgi-bin/tct/tip/327>

4\. <http://wiki.tcl.tk/21276>

Update: more details on the NRE implementation are available here [5] at the
contributing author's site; anonymous login required.

5\. <http://msofer.com:8080/wiki?name=NRE>

------
mitchi
Is this the programming language that works without a lexer/parser and a
grammar? Why aren't there more programming languages written this way? Seems
easier to implement.

~~~
gnachman
The parser's behavior is not specified except in the implementation, which is
messy C. I was once loosely involved in a project that tried to reimplement
it, which turns out to be extremely difficult, and was laughed at by Brent
Welch. Indeed, it failed on countless edge cases. lex and yacc (or whatever)
at least isolate this part of the language, making it much easier to have more
than one implementation.

~~~
asnarb
Tcl's syntax is completely specified in the man page:
<http://www.tcl.tk/man/tcl8.5/TclCmd/Tcl.htm> (well, nearly completely --
there are couple of minor details left out -- but the man page is complete
enough to fully understand the syntax. More people should read it.)

Messy C? Most people who've worked on it seem to think it's rather clean. (Not
the bytecode compiler though -- that is indeed a mess. But most of the
implementation is solid, readable code.)

------
eiji
The TIP#257[1] (Tcl Improvement Proposal) explains how rich and thought-out
the TclOO component is. Endless possibilities. It's a nice read to learn more
about OO-concepts like filters, mixins and meta-classes.

Some might ask how TclOO compares to iTcl's. For one the performance is in
another league.[2](Version 0.3)

[1] <http://www.tcl.tk/cgi-bin/tct/tip/257>

[2] <http://wiki.tcl.tk/18152#pagetoc16f40cc9>

------
sigzero
I lurk on the core list so I got to watch discussions relating to 8.6 stuff.
It was pretty cool. There was a lot of thought about what went in and what
needed to to be tweaked.

