10 ms·

coroutines, tailcalls, and more)

144 points by anoved 14y ago

andrewcooke 14y ago
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 14y ago
  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 http://wiki.tcl.tk/37253#pagetocbefb5a57 2. http://www.tcl.tk/cgi-bin/tct/tip/328 http://www.tcl.tk/cgi-bin/tct/tip/328 3. http://www.tcl.tk/cgi-bin/tct/tip/327 http://www.tcl.tk/cgi-bin/tct/tip/327 4. http://wiki.tcl.tk/21276 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 http://msofer.com:8080/wiki?name=NRE
- kevinwalzer 14y ago
  Tcl's "minor" or point releases are bigger than most languages'. 8.6 has been in development for about four years. 8.5 was also in development at least that long. Contrast Python, which does a point release every 18 months or so.
mitchi 14y ago
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.
- deleted 14y ago
  [deleted]
- acc00 14y ago
  the point is not so much ease of implementation (a parser for a reasonable grammar is usually an insignificant part of a language implementation) as is homoiconicity, and thus easy extensibility. in this regard tcl is similar to lisp and forth (despite all three having different foundations).
- gnachman 14y ago
  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 14y ago
    Tcl's syntax is completely specified in the man page: http://www.tcl.tk/man/tcl8.5/TclCmd/Tcl.htm 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.)
  - schlenk 14y ago
    Tcl's C implementation is far from messy. Its actually one of the best commented C based language code bases i have ever seen. But your project was doomed by false assumptions. (oh, and Tcl has more than one implementation, e.g. there is a version based on Parrot for example, http://code.google.com/p/partcl/ http://code.google.com/p/partcl/ or the JACL interpreter based on the JVM).
ademirar 14y ago
Congrats, Tcl/Tk team! A long wait, but it seems to be worth.
to3m 14y ago
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 14y ago
  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-elimination.html http://neopythonic.blogspot.com/2009/04/tail-recursion-elimi...
  - sigzero 14y ago
    His choice, he is the BDFL after all.
  - yfyf 14y ago
    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-elimination.html?showComment=1240451280000#c1726520516547497765 http://neopythonic.blogspot.nl/2009/04/tail-recursion-elimin... [2]: http://en.wikipedia.org/wiki/Shared_nothing_architecture http://en.wikipedia.org/wiki/Shared_nothing_architecture
rikthevik 14y ago
Tcl Rule 1: Everything is a string. Tcl Rule 2: See rule 1. Tcl Rule 3: Not joking.
- jeffh 14y ago
  While the EIAS philosophy is true in Tcl, at the real guts level, the actuality is "Everything must be representable as a string". EMBRAAS it! There is an object system underneath which handles native or user defined types.
  - sreque 14y ago
    It's worse than that, unfortunately. Everything is implicitly convertible to a string, and every string is implicitly convertible to any other type. So, if you pass a dictionary into your function that expects a list, it will happily convert between types for you. I do not like this sort of behavior in my dynamic type system.
    - jjr 14y ago
      But a dict is a list of paired elements? I do like the fact that you can convert freely between string/list/dict. It removes a lot of boilerplate type conversion. Want to serialize a dict? In most languages that's boring code. In Tcl it's so easy you do it all the time.
      - keypusher 14y ago
        Depends on the language, but I prefer the Python approach here. Python is a dynamically (but strongly) typed language. If you want a list from a dict, get a new list via casting ie. list(the_dict), or get a list from either side via the_dict.keys() or the_dict.values(). Weakly typed languages that will do implicit type conversion for you such as TCL and Perl seems prone to mistakes and confusion from this stuff as code complexity of the project grows. I don't think Python gets it right here either though really, as in the end explicit types save so much headache and stupid bugs by finding problems for you at lint or compile time.
sigzero 14y ago
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.
eiji 14y ago
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 http://www.tcl.tk/cgi-bin/tct/tip/257 [2] http://wiki.tcl.tk/18152#pagetoc16f40cc9 http://wiki.tcl.tk/18152#pagetoc16f40cc9

144 points by anoved 14y ago

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 14y ago
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 http://wiki.tcl.tk/37253#pagetocbefb5a57 2. http://www.tcl.tk/cgi-bin/tct/tip/328 http://www.tcl.tk/cgi-bin/tct/tip/328 3. http://www.tcl.tk/cgi-bin/tct/tip/327 http://www.tcl.tk/cgi-bin/tct/tip/327 4. http://wiki.tcl.tk/21276 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 http://msofer.com:8080/wiki?name=NRE
kevinwalzer 14y ago
Tcl's "minor" or point releases are bigger than most languages'. 8.6 has been in development for about four years. 8.5 was also in development at least that long. Contrast Python, which does a point release every 18 months or so.

mitchi 14y ago

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.

deleted 14y ago
[deleted]
acc00 14y ago
the point is not so much ease of implementation (a parser for a reasonable grammar is usually an insignificant part of a language implementation) as is homoiconicity, and thus easy extensibility. in this regard tcl is similar to lisp and forth (despite all three having different foundations).
gnachman 14y ago
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 14y ago
  Tcl's syntax is completely specified in the man page: http://www.tcl.tk/man/tcl8.5/TclCmd/Tcl.htm 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.)
- schlenk 14y ago
  Tcl's C implementation is far from messy. Its actually one of the best commented C based language code bases i have ever seen. But your project was doomed by false assumptions. (oh, and Tcl has more than one implementation, e.g. there is a version based on Parrot for example, http://code.google.com/p/partcl/ http://code.google.com/p/partcl/ or the JACL interpreter based on the JVM).

ademirar 14y ago

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

to3m 14y ago

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 14y ago
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-elimination.html http://neopythonic.blogspot.com/2009/04/tail-recursion-elimi...
- sigzero 14y ago
  His choice, he is the BDFL after all.
- yfyf 14y ago
  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-elimination.html?showComment=1240451280000#c1726520516547497765 http://neopythonic.blogspot.nl/2009/04/tail-recursion-elimin... [2]: http://en.wikipedia.org/wiki/Shared_nothing_architecture http://en.wikipedia.org/wiki/Shared_nothing_architecture

rikthevik 14y ago

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

jeffh 14y ago
While the EIAS philosophy is true in Tcl, at the real guts level, the actuality is "Everything must be representable as a string". EMBRAAS it! There is an object system underneath which handles native or user defined types.
- sreque 14y ago
  It's worse than that, unfortunately. Everything is implicitly convertible to a string, and every string is implicitly convertible to any other type. So, if you pass a dictionary into your function that expects a list, it will happily convert between types for you. I do not like this sort of behavior in my dynamic type system.
  - jjr 14y ago
    But a dict is a list of paired elements? I do like the fact that you can convert freely between string/list/dict. It removes a lot of boilerplate type conversion. Want to serialize a dict? In most languages that's boring code. In Tcl it's so easy you do it all the time.
    - keypusher 14y ago
      Depends on the language, but I prefer the Python approach here. Python is a dynamically (but strongly) typed language. If you want a list from a dict, get a new list via casting ie. list(the_dict), or get a list from either side via the_dict.keys() or the_dict.values(). Weakly typed languages that will do implicit type conversion for you such as TCL and Perl seems prone to mistakes and confusion from this stuff as code complexity of the project grows. I don't think Python gets it right here either though really, as in the end explicit types save so much headache and stupid bugs by finding problems for you at lint or compile time.

sigzero 14y ago

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.

eiji 14y ago

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 http://www.tcl.tk/cgi-bin/tct/tip/257 [2] http://wiki.tcl.tk/18152#pagetoc16f40cc9 http://wiki.tcl.tk/18152#pagetoc16f40cc9