Tcl/TK is indeed dying
in [TCL]
|
Prev: www.prevayler.org anyone do an in ram data base with transactionlog in tcl?
Next: accessing GUI with TWAPI (was: Accessing GUI of CAD through Tcl/Tk)
From: Tom Poindexter on 21 Dec 2009 15:40 In article <ige407-918.ln1(a)klein-habertwedt.de>, Uwe Klein <uwe_klein_habertwedt(a)t-online.de> wrote: >I have still to see an instruction set that does >not have some form of >call some code elsewhere and return to this same place. >( with more or less state saving ) No gosub/call/balr/etc. for this cpu :-) http://en.wikipedia.org/wiki/One_instruction_set_computer -- Tom Poindexter tpoindex(a)nyx.net
From: Uwe Klein on 21 Dec 2009 15:50 Tom Poindexter wrote: > In article <ige407-918.ln1(a)klein-habertwedt.de>, > Uwe Klein <uwe_klein_habertwedt(a)t-online.de> wrote: > > >>I have still to see an instruction set that does >>not have some form of >>call some code elsewhere and return to this same place. >>( with more or less state saving ) > > > > No gosub/call/balr/etc. for this cpu :-) > > http://en.wikipedia.org/wiki/One_instruction_set_computer > invert and decide that is the equivalent of "one type only gates" logic 2 inp NOR 2 inp NAND negate, combine > > uwe
From: Rodericus on 21 Dec 2009 17:43 On 21 Dez., 18:17, "tom.rmadilo" <tom.rmad...(a)gmail.com> wrote: By the way, Knuths example 6 is something for you. The result 6c of the reduction is pretty readable and compact. Sure efficient. I like that kind of programming! Rodrigo.
From: Donal K. Fellows on 22 Dec 2009 04:51 On 21 Dec, 17:17, "tom.rmadilo" <tom.rmad...(a)gmail.com> wrote: > Both the Knuth paper and your's are great reading. Your conclusion > (part 7) is a great summary of how modern languages provide goto-like > features, or other features which obviate the need to use goto > (without adding additional computation). Reflecting on the original thought (Dijkstra's "letter") and the responses to it (Knuth's paper, KBK's commentary) I'd say that it all represented a plea for better control constructs than were available at the time. After all, goto is a very basic flow control construct. Since then, things have moved on a lot. For example, labelled loops and break/continues help with many classes (and are probably the main missing thing from Tcl now) as do exceptions and the try/trap/finally construct (also RAII-like patterns can help). Coroutines also untangle certain kinds of flows. What is more, Tcl is highly able to construct new control flow structures without language changes, which remains a fairly rare language feature even now. But back to what I noted earlier this thread about the three-way fight... My position hasn't changed. Gotos can be used to commit great sins (OK, not as bad as a longjmp() but we'll do our damnedest to forget that) but when the language does not let you make new control structures then it is better to have goto so that you can write down the control flow that you mean rather than obscuring it behind a wall of nasty little boolean variables or repeated tests. It's a bit like a sharp knife; you can do great mischief with it, but it's still a useful tool. (Tcl does not need [goto] though; it *does* have the ability to make new control structures instead which gives superior clarity.) > Tcl seems to be missing only one very useful feature (at the script > level): _ungetc_. You could try stacking on a transformation that delivers that single extra byte (careful: not a character!) and then unstacks itself. This has the advantage of allowing a multi-byte ungetc equivalent. Though to be honest, I've never personally written any code that has needed ungetc in any language; those places where I might have needed it (lexers/parsers) have been better served by using a real compiler- compiler. > In my test htclient code, about a third to one-half of the code is due > to the inability to push back one char (\r). One solution would be to > use a stack, another would be to add Tcl_Ungets to the script level. As noted, a stacked transformation might be the way to do it. Requires Tcl 8.6 though (we didn't get around to implementing them in 8.5; the C-level API is there, but the scripted was later). Curious that we have such different experiences of what parts of an API are useful. Not that I'm calling you wrong though; there's a known fact that everyone needs a different subset of the basic features of a piece of software. Indeed, the first time I can recall seeing it enunciated clearly was in relation to MS Word's feature-itis. You might also be able to do it with the scripted channels that 8.5 does provide. Alas, quite a bit of work though. Donal.
From: Rodericus on 22 Dec 2009 05:59
On 22 Dez., 10:51, "Donal K. Fellows" <donal.k.fell...(a)manchester.ac.uk> wrote: > Reflecting on the original thought (Dijkstra's "letter") and the > responses to it (Knuth's paper, KBK's commentary) I'd say that it all > represented a plea for better control constructs than were available > at the time. After all, goto is a very basic flow control construct. > Since then, things have moved on a lot. Knuth substituted an if/goto with a while in 6c for then complaining about the sinnfull goto that goes inside the iteration. If he leaves the if/goto, the program is clear a transformation of the original, it is easy to understand what it does. It is a question of semantics: when you have the while, the jump inside is disturbung. If you find the program dificult to undertand, then becuase the definition of what you want to calculate is recursive, the recursive program is the clearest one because it reflects directly the definition. A structured program will not be clearer. It is funny to see how many features must be added to a programming language only to eliminate the use of goto because it may be misused for writing unreadable programs. Why you allow Tcl write programs that modify themeselvs? Cannot be this misused for writing unreadable programs? Rodrigo. |