News for hackers. Stuff that matters.
Re:The Idea of Lisp by mroll on Friday December 16, 2016 @09:45AM (#13193526)
Yeah the level of dynamicness (dynamism?) you can get in tcl is unparalleled as far as I can see. Having no types or syntax and access to the entire runtime at any point in the program opens up all kinds of crazy doors. But you're right, that slows it down.

But you might be interested to know there is currently an effort to get Tcl to compile to native/near-native code. Here is a paper on the new techniques being developed and a link to a talk given by one of the lead tcl core team members.

http://www.tcl-lang.org/community/tcl2015/assets/talk14/TheT...

https://www.youtube.com/watch?v=RcrqmZV88PY&t=38s

Re:The Idea of Lisp by goatlover on Friday December 16, 2016 @01:42PM (#13195585)
I believe IO lets you do the same. Everything is a prototype with slots, communicating via messages.

I guess Self was the same way. Self & Smalltalk also give you access to the entire runtime.

Re:The Idea of Lisp by qwertyuiop924 on Friday December 16, 2016 @02:03PM (#13195774)
But TCL actually goes beyond that.

Most languages of this sort, like Smalltalk, Lisp, and especially slower, more liberal implementations like PicoLisp, allow for compile-time and/or runtime AST transformation, and other sorts of metaprogramming.

in TCL, everything is a string. Or at least, everything behaves like a string in the proper context. When you pass code blocks into a command (like if, or while, or whatever), you're not passing code objects: you're passing unevaled strings. This is why expr works in TCL: there's nothing special about expr, it's just actually implementing a DSL (sort of) rather than evaling your code straight up.

The practical upshot of this is that unlike smalltalk (I think: Can an ST user actually answer this?), and to a greater degree than LISP and FORTH (;immediate and readtables are a lot more painful to wrangle), you can not only modify the semantics of the language: you can modify the syntax.

Re:The Idea of Lisp by pjmlp on Friday December 16, 2016 @02:18PM (#13195908)
Smalltalk just like Lisp has very little syntax, almost everything is built on messages, including data type creation, conditionals and loops, among other things.

Also you can at any time just completely replace one object by other via the becomes: message.

There are also some cool tricks when metaclasses are used, many of each one can see in Python as well.

Re:The Idea of Lisp by qwertyuiop924 on Friday December 16, 2016 @02:37PM (#13196081)
However, IIRC, unlike Lisp, ST doesn't have any AST transformation or parsing hooks (macros and readtables, in Lisp parlance), so while ST has a lot of the semantic extension capabilities of Lisp (indeed, it's more semantically extensible than some of the less Object Oriented Lisps), it lacks the syntactic capabilities for extension.

However, you know ST better than me. Am I right?

Re:The Idea of Lisp by pjmlp on Friday December 16, 2016 @03:01PM (#13196255)
As far as I can remember no (Smalltalk was long time ago for me, 1995).

But I think there is already quite a few things possible via messages and metaclasses, even if one cannot do actual AST transformations.

After all, the whole image is accessible, so you can dynamically ask any object for its definition, or even compiled code (bytecode or JIT) and change them.

Re:The Idea of Lisp by qwertyuiop924 on Friday December 16, 2016 @04:19PM (#13196949)
>But I think there is already quite a few things possible via messages and metaclasses, even if one cannot do actual AST transformations.

That's true. In fact, there are things that messages and metaclasses can do that you can't do with AST transformations without implementing those abstractions.

>After all, the whole image is accessible, so you can dynamically ask any object for its definition, or even compiled code (bytecode or JIT) and change them.

I still miss this in Lisp. Some Lisps had that, once, but it's uncommon nowadays. it happens in the commercial CLs, but those are expensive. OS CL implementations rarely have good image support (in SBCL, image saving actually corrupts the RAM state to the point of nonrecoverability, and the docs recomend fork(2)ing if you want to save an image and continue your app).

Aside from the proprietary CLs, PicoLisp is the only modern lisp environment that has this kind of dynamic capability AFAICT (and while it does sort of have images, in the form of external symbols, the language doesn't encourage using them like this. Also, calling it modern is a stretch: it has more in common with LISP 1.5 than, say, CL). And the Schemes? Don't make me laugh. Scheme has many strengths, but reflection isn't one of them. It's something that I really wish the Lisps had.

One of the reasons I want to try my hand at implementing Lisp on the Spur VM at some point.

Re:The Idea of Lisp by qwertyuiop924 on Friday December 16, 2016 @10:28AM (#13193871)
Picolisp can match it in dynamism.

Seriously, Picolisp is absolutely insane.

Re:The Idea of Lisp by mroll on Friday December 16, 2016 @10:38AM (#13193949)
I just read a bit of documentation from the Picolisp page. It looks really cool, but can it reach arbitrarily far up the call stack? That's the quality of tcl that I don't see other places. The capabilities of 'upvar' and 'uplevel'.

[Edit] I should say "one of the qualities." The other important one is that Tcl has no types. Even all the lisps I know have types.

Re:The Idea of Lisp by qwertyuiop924 on Friday December 16, 2016 @12:42PM (#13195086)
The functions you're looking for are called `up` and `run` in picolisp.

And before you ask, yes, picolisp has list interpolation (or quasiquoting, in lisp parlance), so you can control which parts of a certain chunk of code will be run when, and in which contexts. It also includes the `macro` fexpr, which makes interpolation more convenient.

Re:The Idea of Lisp by mroll on Friday December 16, 2016 @12:50PM (#13195157)
Wow, very interesting. Thanks for pointing out picolisp!
Re:The Idea of Lisp by vram22 on Friday December 16, 2016 @11:40AM (#13194471)
>The other important one is that Tcl has no types.

Is it that it has no types or that everything is a string? asking, not stating.

Re:The Idea of Lisp by mroll on Friday December 16, 2016 @11:56AM (#13194640)
Yes, everything is a string. But you can pass data around anywhere you like without worrying about coercing. A command will receive its data in string representation and treat it however it likes. So when you go to do math with the 'expr' command, 'expr' will treat its arguments as numbers.

    set x 5
    expr { $x + 3 }
'expr' receives x as the string 5 but knows to treat it as an int.

I'm not sure that's a great explanation. Maybe a decent summary of the concept of 'no types' is "the language does not presume to tell you how you can or cannot use your data."

Re:The Idea of Lisp by vram22 on Friday December 16, 2016 @12:32PM (#13194980)
Thanks. Yes, I get it. I had read part of the Ousterhout book. And also Don Libes' Expect book uses Tcl, since Expect is written in it. Had read a lot of that too. Both very good ones. Didn't get to use Tcl in projects though. I'd read some years ago that Tcl was used heavily in the electronics / EDA industry.