Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Tcl/Tk 8.6 released (now stackless, w/coroutines, tailcalls, and more)

tcl.tk

Post reply on HN
Print view View original

11–20 of 42 posts

Re: Tcl/Tk 8.6 released (now stackless, w/coroutines, tailcalls, and more)

#11

Post by michaelhoffman »

to3m wrote: post #7

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 g…

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...

Re: Tcl/Tk 8.6 released (now stackless, w/coroutines, tailcalls, and more)

#12

Post by kevinwalzer »

andrewcooke wrote: post #2

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)?

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.

Re: Tcl/Tk 8.6 released (now stackless, w/coroutines, tailcalls, and more)

#14

Post by sigzero »

michaelhoffman wrote: post #11
to3m wrote: post #7

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 g…

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...

His choice, he is the BDFL after all.

Re: Tcl/Tk 8.6 released (now stackless, w/coroutines, tailcalls, and more)

#15

Post by btilly »

to3m wrote: post #7

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 g…

I think this would be a chance to rehabilitate the much-maligned GOTO keyword.

Perl has used "goto &foo" for that exact purpose for ages. It just became yet another random feature that experts know about, regular programmers ignore, and critics use to show how terrible the language is.

Re: Tcl/Tk 8.6 released (now stackless, w/coroutines, tailcalls, and more)

#16

Post by sreque »

jeffh wrote: post #10
rikthevik wrote: post #9

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

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.

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.

Re: Tcl/Tk 8.6 released (now stackless, w/coroutines, tailcalls, and more)

#17

Post by jjr »

sreque wrote: post #16
jeffh wrote: post #10

Earlier quoted context omitted.

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.

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.

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.

Re: Tcl/Tk 8.6 released (now stackless, w/coroutines, tailcalls, and more)

#19

Post by marshray »

sreque wrote: post #16
jeffh wrote: post #10

Earlier quoted context omitted.

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.

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.

(Apologies in advance, I'm just thinking out loud here, not meaning to troll.)

So you like strong typing. I do too, but I like it even more at compile time. If you're doing without the compile time error checking, why not go all the way and do without type errors at runtime as well? Sounds like a choice between:

1. type errors at compile time,

2. data-dependent type errors at runtime, or

3. data-dependent corruption and/or non-type errors at runtime.

Re: Tcl/Tk 8.6 released (now stackless, w/coroutines, tailcalls, and more)

#20

Post by luser001 »

sreque wrote: post #16
jeffh wrote: post #10

Earlier quoted context omitted.

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.

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.

> I do not like this sort of behavior in my dynamic type system.

Why? [Other than for performance reasons]

I keep repeating this point in every Tcl thread. Tcl was meant to be used to enable command line shells for programs written in C.

Btw, being able to treat a list as a dict has been useful to me. I (developer) write a routine to be used by a non-developer, who may not be a great programmer. The list notation is easy in Tcl. I can just tell them to make a list with keys and values alternating. And for a one-time conversion cost, I get to use it as a dict.

Also works the other way around: I can return a dict. And if a Blub user is processing it, he's free to ignore my documentation that it's a dict and process it as a list (again for a one-time cost).

YMMV.

Post reply on HN