Category talk:Tcl: Difference between revisions

From Rosetta Code
Content added Content deleted
(→‎Language features: Revise/refresh reasoning)
(Link to non-implemented tasks list for efficiency)
Line 1: Line 1:
'''Temporary:''' Just so this is easy to find for now. [[Reports:Tasks not implemented in Tcl]]
==Tasks Unlikely to get Implemented==
==Tasks Unlikely to get Implemented==
This is a short discussion of the tasks that are marked with the omit template. —[[User:Dkf|Dkf]] 09:14, 21 May 2009 (UTC)
This is a short discussion of the tasks that are marked with the omit template. —[[User:Dkf|Dkf]] 09:14, 21 May 2009 (UTC)

Revision as of 23:58, 9 December 2009

Temporary: Just so this is easy to find for now. Reports:Tasks not implemented in Tcl

Tasks Unlikely to get Implemented

This is a short discussion of the tasks that are marked with the omit template. —Dkf 09:14, 21 May 2009 (UTC)

Parametric Polymorphism
Tcl doesn't have static typing, making this task ridiculously trivial/non-applicable. Note also that the task itself states that it only applies to languages with static typing.
Constrained Genericity
This is a specialization of the Parametric Polymorphism task, so all comments there apply here too.

Language features

Tcl uses a mixture of pass-by-value and pass-by-reference, and is very good at simulating pass-by-name too. The base language semantics are strictly pass-by-value; this was how everything was done up to Tcl 7.6, and when combined with the fact that it was also string based, it gave the language a (deserved) reputation for being slow. In Tcl 8.0 the language implementation was switched to pass-by-reference, with the entities being semantically immutable objects (the actual code is more nuanced than that, of course); that was a major part of why Tcl sped up with that version. The pass-by-name support is through the upvar command, which allows the looking-up of a variable in one scope and aliasing it to another variable in the current scope. —Dkf 10:16, 31 May 2009 (UTC)

I've selected these features:

exec=bytecode
Tcl's used a bytecode engine (with occasional interpretation) since 8.0, i.e., 1996.
OK, we've been discussing compiling to native code for a while now, but we've not got the effort to make that viable across lots of platforms, and going to a common bytecode format like JVM, CIL or LLVM is awkward as they are much more low-level than Tcl; for example, Tcl's variables aren't just simple bits of memory but also have a lot of other things that can be attached off them. —Donal Fellows 08:23, 6 August 2009 (UTC)
expression=dynamic
We use dynamic typing in expr.
compat=duck
We say it's a ducklist if it supports the operations of a ducklist.
checking=dynamic
Our type checks are applied at runtime only. That's when they are enforced strictly.
parampass=value
We always pass parameters by value. We simulate pass-by-reference by passing handles/names and pass-by-name with the help of upvar.
safety=safe
The language, especially in a safe interpreter, has no unsafe operations at all.
paradigms=Imperative, Object-oriented, Event-driven, Reflective, Concurrent
Tcl supports all of these handily enough. With more detail/justification:
Concurrent
The Thread extension is long-established.
Event-driven
While Tk has always been event driven, Tcl has been since 7.5 or 7.6 when it gained the event loop from Tk.
Imperative
Tcl is definitely an imperative language.
OO
Tcl supports this through many extensions, and natively from 8.6.
Reflective
Tcl's had introspection for ages; it's vital for the language's self-tests.

We need to check whether these features are enough; if not, we should update the Language template... —Donal Fellows 12:26, 1 June 2009 (UTC)