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!
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.
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.
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.).
I haven't tested use from Elixir yet, but in theory it should Just Work™ (e.g. by calling :otpcl.eval/1). This will be even easier once I do publish it on hex.pm, since (again: in theory) it should just be a matter of including it as a dependency in your app's mix.exs. One of my first Elixir-specific goals will probably be to integrate this with Plug (and particularly Plug.Router, producing a cool hybrid between Plug and OpenBSD's pf/httpd/relayd config files).
But yeah, OTPCL/Tk would be pretty sweet, even if it has to be emulated through wxWidgets (or even through something HTML/JS-friendly; I've always dreamed of being able to generate web pages via a Tk-like API and programming style).
I was going to mentioned Scenic...
The only dependency Scenic needs is OpenGL driver.
I was never able to build Erlang's wx app on my Ubuntu laptop, but with Scenic it just works out of the box.
IMO Tk's canvas widget can be relatively easily ported to Scenic as both based on retained mode graphics, only in Scenic each item on the canvas will be represented by a gen_server.
Yeah, a one(-or-more)-process-per-widget approach is exactly how I'd envision an Erlangy GUI framework (and is effectively how ordinary Tk works, except with tasks/events processed by an event loop instead of Erlang's preemptive multitasking). Scenic looks like a great starting point in that direction.
I wonder how Wings3D does things? I'd imagine it uses wxWidgets, but I never actually thought to check...
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!