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

31–40 of 42 posts

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

#31

Post by asnarb »

gnachman wrote: post #23
mitchi wrote: post #3

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.

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.

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

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

#32

Post by cageface »

iso-8859-1 wrote: post #18
rikthevik wrote: post #9

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

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

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.

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

#33

Post by xnxn »

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

I clicked that link ready to laugh, but he makes a persuasive argument. I feel like I've been tricked.

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

#34

Post by draegtun »

btilly wrote: post #15
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.

And there are a few CPAN modules for those who are squeamish about using goto :)

- https://metacpan.org/module/Sub::Call::Tail

- https://metacpan.org/module/Sub::Call::Recur

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

#35

Post by mahmud »

yfyf wrote: post #28
mahmud wrote: post #24

Earlier quoted context omitted.

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.

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, especiall…

Fair point.

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

#36

Post by masklinn »

luser001 wrote: post #20
sreque wrote: post #16

Earlier quoted context omitted.

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…

> Why? [Other than for performance reasons]

Because it becomes very hard to reason with what you have at hand, and in my experience the "helpful" conversions, rather than actually help, mostly hides errors and bugs in the code and delays there effect, making them much harder to diagnose than a stricter handling.

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

#37

Post by oddthink »

cageface wrote: post #32
iso-8859-1 wrote: post #18

Earlier quoted context omitted.

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

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.

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.

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

#38

Post by wreckimnaked »

oddthink wrote: post #37
cageface wrote: post #32

Earlier quoted context omitted.

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.

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…

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

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

#39

Post by rikthevik »

iso-8859-1 wrote: post #18
rikthevik wrote: post #9

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

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

It's not a problem - it lets you do some really neat things that you just can't do in other languages easily. But it is a very very true thing about Tcl.

I was generating functions procedurally, and I was having a scoping problem with one of the inner variables. Naturally, the suggested solution was to do a string replace on your newly created function. Seems obvious in retrospect. :)

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

#40

Post by schlenk »

skoob wrote: post #25
jjr wrote: post #17

Earlier quoted context omitted.

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.

> But a dict is a list of paired elements? Not really. A dict is an unordered set of keys where each key has a value associated with it. If you try to access a dict as a list, you might expect to get a list of key-value pairs or a list of values or possibly a list of keys. And in what order will the elements in the list be?

Tcl dicts are ordered, so you have a defined order for this. http://www.tcl.tk/man/tcl/TclCmd/dict.htm#M27
Post reply on HN