Wacl: Tcl distro customized for WebAssembly | Hacker News Reader

Wacl: Tcl distro customized for WebAssembly

fossil.e-lehmann.de

91 pointsblacksqr65 comments

Of interesting historical note, the W3C HTML 4 standard alludes to TCL as a possible scripting language when describing the script tag, albeit just as an example:

https://www.w3.org/TR/html4/interact/scripts.html

At one point, very early in the web's infancy, before Javascript became "the one" web language, Sun was considering Tcl for the role that Javascript took over in the <script> tag.

Why do people like Tcl? I've never tried diving in to using the language, but I have debugged MacPorts now and then, which is all Tcl, and I've seen that Tcl UI library used in other scripting languages.

What's the draw, other than having some existing code written in the language? Gems like the `upvar` command? (http://wiki.tcl.tk/1508)

Is there something special about Tcl that makes it a joy to use?

It's an elegant, lightweight language, with a design thoroughly optimized for interactive use. http://yosefk.com/blog/i-cant-believe-im-praising-tcl.html .

Thanks, this blog post was exactly the sort of discussion I was looking for!

The TL;DR:

- easy to write interactively because there's no fiddling with the parens, quoting, or commas you find in JS, Ruby, or Python

- uses [ and ] for subexpressions instead of ( and ), which makes typing easier

- "command" oriented, instead of "expression" oriented

- saner than shell while having many of the same advantages

> - uses [ and ] for subexpressions instead of ( and ), which makes typing easier

I would like to point out that in several non-US keyboard layouts, [ and ] are harder to type, not easier. For instance, on German keyboards, they are mapped to Right-Alt (AltGr) + 8/9, which is quite annoying to type compared to normal parentheses (which are mapped to Shift+8/9, with Shift being better placed and available on both the left and right side of the keyboard).

As a German I haven't use a German keyboard layout in years because the US layout easier in most cases (for examole all those curly braces in TeX).

All my colleagues would agree and did the same. I don't. I want äöü quickly available for chatting and other "quick" writing, while coding typing is usually not the bottleneck.

Is there a German keyboard layout such as?:

AltGr + a -> ä

AltGr + o -> ö

AltGr + u -> ü

I'm Polish and I'm very glad that our most common layout is like that for ąćęłńóśźż (with AltGr + x for ź). Currently I'm in Germany and I wonder if there is similar layout for German umlauts.

There seems to be a layout called "US international" which might help: https://en.m.wikipedia.org/wiki/File:KB_US-International.svg

As a Swede, I can echo this. I'm so used to the US layout by now that I have to do a double take whenever I switch to the SE layout, or type on someone else's keyboard.

I used to get laptops and keyboards with the US layout on them, but stopped since the resale value in Sweden drops sharply because of it. Thankfully, I've touch typed since forever so I rarely look at the keyboard anyway. (Unless, of course, I have to type with the Swedish layout.)

Pragmatically it is actually a giant pain to use. Its bizarre text substitution semantics are hugely unintuitive compared to modern languages.

I would also add that the "Everything is a String" paradigm makes it simple to reason about somewhat complex concepts. You don't have to try to teach beginners about objects and pointers. Just plain old text strings. Everything else is under the hood.

I miss some features of more modern languages though. TclOO (object-oriented extension) is minimally useful but lacks GC, so you have to keep track of all objects to manually destroy them when you are done. I miss easily passing around functions (procs), and saner local namespacing for functions (ie like in python). Exception handling is also a bit of a pain.

A lot of these things are addressed in Jim Tcl, but it hasn't seen much adoption.

http://jim.tcl.tk/index.html/doc/www/www/index.html

A fair amount of the popularity was being the first scripting language with a reasonably complete, cross platform, UI widget toolkit.

It was also very easy to embed inside a C application for a user facing scripting capability.

> A fair amount of the popularity was being the first scripting language with a reasonably complete, cross platform, UI widget toolkit.

That wasn't my experience. At least in tcl/tk 8.5 things like zooming in/out of a tk canvas or updating a progress bar were a real pain.

For example, tk canvas has this nice, seemingly simple subcommand called "scale" that looks like it does exactly what it's called with a tag and two double-precision floats. Apply it and all the relevant tk items are scaled accordingly. It even has a predefined tag called "all" that applies to all current tk canvas items. Trivial. Awesome.

Except text items don't get scaled. And font sizes are limited to integer pixel/point sizes. So zooming is actually non-trivial. Not awesome.

There are a sufficient number of such idiosyncracies that if you want to make a clear, usable interface you end up battling the toolkit.

Also, on the tcl language level I felt the "everything is a string" feature gets in the way. I'd much rather have implicit expressions and explicit string declarations.

All fair, but you have to take the time period in context. There wasn't the plethora of choice we have today.

It's the "reasonably complete" phrase that I'm responding to.

For example: Qt was released around the same time. Do you know if the first version included QGraphicsView? Because it has features we still associate with a modern 2d graphics API-- affine transforms, opacity, grouping of primitives, arbitrarily complex paths, and decent performance even with event handlers and many items being animated on the canvas.

Yes, qt is a better toolkit. But it wasn't embedded in a cross platform scripting language at the time.

And that was quite obviously a reason many developers chose tcl/tk at the time, in spite of tk not being a "reasonably complete" GUI toolkit.

Tcl 8.5 is a recent release though, around 2007.

When GP says "one of the first scripting languages with a GUI toolkit", he is talking about the early 1990s. Before even python's first release. In fact, python ended up with Tk as it's stdlb GUI package because that was what was available.

Sure, Tk will never live up to Qt, but in 1991, I bet it was quite impressive to have a relatively simple yet expressive language like Tcl that shipped with a cross platform GUI toolkit, all under a very permissive license.

This. For a period of time in the 1990-1999 range, Tcl/Tk was often the only way to have a cross platform program with a GUI that did not require the language equivalent of #ifdef WINDOWS/#ifdef UNIX everywhere. Which while providing "one code base, two platforms" really meant writing the platform specific code twice.

For most Tcl/Tk usage at the time the same, unchanged, no "ifdef"'s present Tcl/Tk script would run identically on the various environments that it supported.

There's a situation that springs up sometimes that is perfect for Tcl/Tk: when you need to write a small app with a GUI and you would like it to be multiplatform.

Say you want to write an app to rename files in batch, or a wrapper for Ghostscript that automates certain tasks. With Tcl/Tk you can immediately run it on most Linux distros and with Freewrap you get a Windows executable that's a few MB+your source (it's a lot better than having your users install Java).

My usual solution for this is C++/Qt. Runs well on Linux, and on Windows you can statically link Qt into the single .exe if your small app is FOSS (at least LGPL-compatible), otherwise you should ship a few extra .dll files.

Compared to Tcl/tk you get (A) catch errors at compile time, and (B) Qt apps usually look better than Tk apps.

With mxe+qmake it's one command to cross-compile from Linux to a Windows binary.

I am now looking at the Red programming language [1] for exactly this, but it does not have the libraries of C++ or Tcl. Still it is under 1 meg complete with libraries and it is homoiconic, cross-platform, and has a REPL and a systems language Red/System for going low level. The GUI and UI DSL and drawing DSL work on Windows and Mac for now, with Linux close behind.

  [1]  http://www.red-lang.org/p/about.html

There's also Lazarus in this category.

The default download didn't have GUI support on my Mac when I just tried it, and the documentation seems to indicate it's Windows only so far?

I think it is in 0.63 or the latest binary now available. I'll check on my iMac later and get back to you. I use it on my Windows box for now.

@mappu above (no reply link by his reply):

I like Lazarus a lot. I am not a fan of Pascal though, and Red is under 1 MB batteries included. I like how it seems a cross between Lisp, Forth and other languages.

Back in the day a big mistake from Tk devs was how it just looked like Motif everywhere.

Eventually that got fixed, but we were already busy with other languages.

well, for me, when i used to like Tcl, it was

    * the everything is a string, mantra
    * meta-programming possibilities 
    * tcl wiki ( http://wiki.tcl.tk/ )

the tcl wiki is the reason i fell in love with wikis, my first wiki experience, and in my opinion when it was very active, it was home of a really nice community

I think if someone can rewrite tcl or a tcl like language, as the top level language, using a more modern low level language, like Rust or Go ... it will be a very nice combo, I think Tcl can serve as a really nice declarative language

If you look at Sqlite, it really is the perfect example of an offspring of the tcl community, a declarative solution for a complex problem , written in C ... a perfect tcl

I stopped following Tcl a long time ago, so I have no clue where it is at now ... but i hope it is still being used, for the super nice community .. it had/has

"I think if someone can rewrite tcl or a tcl like language, as the top level language, using a more modern low level language, like Rust or Go ... it will be a very nice combo, I think Tcl can serve as a really nice declarative language"

Why would someone rewrite Tcl in another language? That is just an immense amount of work and would (re)introduce bugs that have been found and fixed in Tcl over the last 3 decades.

Just the fact that Tcl is old doesn't mean that it is dead. It is actively developed and used, although mostly hidden (its not that kind of hype around as with Python or Ruby). That Tcl is old does in fact imply that the code base is mature and reliable, its well documented and doesn't come with surprises. Which in turn means that your code is almost never broken with a new Tcl version. In fact, scripts and extensions written for 8.4, 15 yrs ago, are mostly still functional in 8.6 without modifications. Yet Tcl does come with pleasant surprises that don't break old programs, as can be seen with the new features in 8.6 (TclOO, coroutines, tailcall, try/trap ...)

well .. i am a big believer in the two layer separation

we program at two layers, high level, and low level

features needed or preferred in low level programming, may not be required in high level programming and vice versa

there are several ways to work like this, and many people do for example, many developers use lua or python with c/c++

the effort needed to make the two language interact vary

another approach is to use one language with optional features, like optional typing or optional garbage collection, a language i believe is adopting this approach is red

have a programming framework, where two languages optimized for the two different layer use each others entities (names, objects, values, interfaces) seamlessly is in my opinion a super good approach for most programming

tcl + c .. are not exactly that and i believe a more modern combo will be better

"well .. i am a big believer in the two layer separation"

I believe in this too. Not only two layers, if necessary there can be more.

For that to work, well designed interfaces are quite necessary.

"tcl + c .. are not exactly that and i believe a more modern combo will be better"

You don't necessarily need to reinvent Tcl in another "more modern" language to achieve that. You can compile Rust crates to dynamic libraries (.dll, .so) and use c types, or ffidl in Tcl (http://elf.org/ffidl/) to call the functions in your DLL-crates. Or write a small Tcl C extension to wrap function calls in the Rust code. That will do, without rewriting Tcl in Rust. For the other way around you can always call the Tcl library via its DLL interface in the same manner (which is the way to embed Tcl interpreters in other programs).

I do think we need a richer ABI than C offers (in particular, one with native support for sum types). .net was intended to be that (sort of) but people don't write low - level libraries in it because it ties you to GC.

By the time you outgrow TCL you are a really good programmer. You choose and advocate appropriately.

I think you are a really good programmer by the time you use Tcl again: as a complementary language for test automation, or to integrate it in your software as DSL...

First you use it because it is simple to learn. Then you outgrow it and blame its weaknesses. Then you remember its strengths from a different perspective and pick it up again :)

I'm a Perl fan and as such it saddens me to see other languages targeting wasm. I've been convinced for a while that webassembly is the next big thing in computing and so far the Perl community as far as I know has shown close to no interest whatsoever.

Sounds like an opportunity to step up to the plate!

I've tried. It's just hard, frankly. I'm just not that good a coder :(

Ehh I don't think so. I'm certain that you are a good coder. You just need to learn more about the techniques needed to implement a Perl to WASM compiler, and obviously, a ton of time.

You can do it man.

The stuff which makes perl really awesome are the distributions on CPAN.

Many (though not all) of these distributions contain XS, which is a type of glue between perl and C. Most of these XS distributions are there to link to some library -- Math::GMP, for example, lets perl code use the GNU gmp multi precision math library.

Without some way to make use of distributions with XS parts, then a perl to $other_language_here transpiler is not going to be very interesting.

That makes sense. Library compatibility is a tough issue to deal with. Scala.js faces the same issue when it comes to libraries that depend on the Java stdlib. I believe their goal is to port the entire stdlib, but I'm not sure tbh. It might just be an insurmountable problem.

Actually quite few are XS and XS is painful/a terrible way to plug C code inside of the Perl interpreter's guts. For this reason Perl6 aims to rewrite most of the stuff in Perl6/NQP and use NativeCall to call on external libraries.

I know you're being encouraging, but I think you're underestimating the complexity of Perl parser. From what I remember, there were three subsystems that voted for each expression what programmer meant.

You are right, I'm completely ignorant on the topic haha. Could you clarify what you mean by "vote"?

Perl has some syntax that can be ambiguous. To the point that some code can't be parsed without running it.

See this for more on that: http://www.perlmonks.org/?node_id=663393

Wasm has no facility for GC, polymorphic inline cache, or direct DOM integration. They are on the roadmap, but probably far off.

So there isn't a direct path to WASM for many dynamically typed languages. Tcl can get by without all that because it's small enough to just port the whole C interpreter instead of trying to have tcl compile down to wasm. That would be very large, slow, and tricky for Perl, Python, etc.

> Wasm has no facility for GC

It shouldn't, GC is a level above Wasm and would complicate languages that don't use it.

> or direct DOM integration

You mean like this: https://github.com/tcr/rust-webplatform ?

The problem with most dynamic langauges you listed is they do things that the web doesn't allow or do them in ways that aren't friendly to a browser.

On GC, maybe you should let them know. They seem to be headed down that path: https://github.com/WebAssembly/design/blob/master/GC.md

Oh, and on direct DOM access. You presented a link to an implementation of indirect DOM access. They have an open issue you might find interesting: https://github.com/tcr/rust-webplatform/issues/20

GC is not as far off as you might think. A markdown overview has been merged and there is a PR for impl in the interpreter. See PRs at https://github.com/WebAssembly/gc

Assembly language also doesn't have GC or polymorphic inline cache. I imagine that direct DOM integration would end up just being some kind of shared memory thing.

I don't get this kind of complaint. It seems to completely miss the point that webassembly is a compile target, like arm or x86.

It is not a complaint. It is in their plans. They describe it sometimes in VM terms, versus ASM terms.

Without those things, languages like Perl or Python aren't practical, because you would have to download the whole interpeter runtime. That's not a complaint, it is an observation.

Well sure, but a runtime isn't going to change all that much. It's exactly the kind of thing that caches well. I mean a re-usable garbage collector sounds alright, but I don't think it will be used that much. I mean, I presume that you could implement a garbage collector as a shared library, but nobody actually does that.

You have to come at it from the perspective of people that want languages like Perl or Python to run well in WASM. They are thinking of it being used the same way that javascript is today. If WASM has some of the features of a virtual machine (meaning the JVM type, not the hypervisor type), and direct DOM access, that would be possible. Downloading all of the runtime would put them at a disadvantage.

Those things are on the WASM roadmap. So this isn't just me going off on a tangent. https://github.com/WebAssembly/design/blob/master/GC.md

There would be several options I think.

  - translate MoarVM bytecode to WASM
  - add WASM as a Rakudo target
  - write yet another Perl6 compiler that targets the WASM just as niecza targets the CLR

Perl5 will probably end up as a Perl6 slang.

I'd be interested to see a Tk implementation.

It would be neat if there were credible alternatives to the DOM.

At long, overdue, too late last...

In the very early days of the web, I used to fantasize - naively - about the whole undignified html hodgepodge never having happened, and the entire web just running on served-up tcl/tk.

If you've ever placed a sports bet anywhere in the world online, chances are your bet went through Tcl code front and back. I spent 15 years writing it.

I didn't ever. But nice to know.

I learned Tcl back in the day just so I could customize Eggdrop [1].

[1] https://www.eggheads.org/

>> tDOM for parsing and creating XML and HTML content

How is tDOM supposed to work if WebAssembly doesn't have access to the DOM?

tDOM is an XML parser based on expat that provides both a SAX and a DOM parser. It parses into its own DOM that one can then run XPATH expressions against or manipulate as one sees fit with tDOM's interface methods.

Unfortunately the DOM for tDOM is not the web browser DOM that Javascript interfaces with. Same term, so very confusing, but not the same DOM's.

tDOM is just for parsing and generating XML or, more interrestingly, HTML. Once you have that, you can use the ::wacl::dom command to inject it into the browser dom. Or use the wacl::dom command to get HTML which then can be parsed via tDOM.

To clarify: this is the Tcl interpreter compiled to webassembly. Not a Tcl program or the language.

Guys. Stay away. Tcl is awful if you want to write software that doesn't waste hours and hours and hours of your precious time hunting down simple bugs that would not have been an issue in most other languages.

- guy who used Tcl in like 1992 and helped write a 'compiler' for it, etc.

Reply on news.ycombinator.com