
Show HN: OTPCL – Tcl-Flavored Erlang - yellowapple
https://bitbucket.org/YellowApple/otpcl
======
yellowapple
This is in a very early stage of development, but it _is_ technically usable
(at least in theory, and for the very limited purpose of simple
script/configuration files), so I think it's ready for the Show HN (thus being
the first time I actually fulfilled a New Years' Resolution!).

Documentation is nonexistent, and the interpreter currently has no test suite
(the parser does, though it ain't exactly comprehensive). There's also no
compiler or REPL yet (only way to use it is to fire up 'rebar3 shell' and call
otpcl:eval/1 or or otpcl:eval/2 repeatedly). However, per README.md, it should
be straightforward to use nonetheless (feed OTPCL programs into otpcl:eval/1
to use the standard library as-is or otpcl:eval/2 to provide a custom one with
your own functions). Evaluation will return the value returned by the last-
executed command in the passed program, plus the final state of that program's
execution, giving two reasonably-useful ways to extract data from program
evaluation (whether for simple scripts or configuration files that are at
least slightly prettier than full-blown Erlang terms).

Next steps:

* Add support to actually eval a file directly (though it should be possible to separately read a file and shove the text contents into otpcl:eval/1 as a stopgap)

* Build the REPL (what good is a scripting language if you can't turn it into an ad-hoc shell language, too? ;) )

* Flesh out the standard library functions (notably, there's no way to define functions from within an OTPCL script at the moment)

* Docs, tests, etc.

* Actually publish on hex.pm (the infrastructure's there; but it's a wee bit too barebones for me to be ready to pull that trigger)

Feedback is welcome. There is certainly a _lot_ of room for improvement, but
hey, at least it (approximately) works!

~~~
nivertech
Too bad Tk was replaced by wx-widgets, otherwise it could be OTPCL/Tk ;)

My main usecase for Tcl/Tk was gluing some legacy and adding some GUI on top
of it. With Erlang/OTP one can easily glue and orchestrate distributed code,
GUI is not as easy as in Tk, since Erlang is much more verbose and wx is more
complex than Tk.

Any plans to support Elixir too?

~~~
kazinator
In a nutshell, the Tk GUI, to my understanding, is basically a C GUI library.
A lot of its widget code is written in Tcl, so that using Tk in an application
requires embedding the Tcl interpreter.

Using Tk, but replacing that Tcl interpreter with one's own is likely
possible, but almost certainly a big project, possibly resulting in a
complicated fork of Tk.

So simply bringing back Tk wouldn't do anything without a lot of additional
work. One simpler possibility, though, would be to have a delegating API in
the OTPCL which just forwards down to the Tcl/Tk, so that it would _look_ like
OTPCL is integrated with Tk.

~~~
yellowapple
Indeed; OTPCL already diverges significantly from Tcl in very important ways
that would be very hard to change while still maintaining some semblance of
compatibility with Erlang and the broader ecosystem thereof; if I were to
literally integrate Tk itself, that would indeed be... involved.

I do like the idea of delegating to actual Tcl for a Tcl/Tk bridge, at least
for something quick-and-dirty; a run-of-the-mill Erlang "port" written in Tcl
ought to be an effective first pass at going about that. It should be easy to
do.

In the longer term, a toolkit geared specifically toward Erlang's strengths
(e.g. each widget having its own process, message passing instead of
callbacks, etc.) seems like it'd be a more valuable contribution to the Erlang
ecosystem, even if it'd be harder than even trying to bridge OTPCL with Tk
directly. Ideally OTPCL/$TOOLKIT should be as dead-simple to use as Tcl/Tk
(and should be straightforward even if you swap out the "OTPCL" part of that
with Erlang/Elixir/LFE/Joxa/LuErl/ErLog/etc.).

