Gluon: A static, type inferred and embeddable language written in Rust
github.com
github.com
It seems that Gluon has taken inspiration from Haskell right down to the monadic solution to mutable state: https://github.com/Marwes/gluon/blob/master/std/state.glu
I wasn't able to find any 'cell' type or mutable records like in OCaml, so this does seem to be a pure language -- is that right? I wonder how that works in practice for small embedded scripts/logic -- my intuition is that the discipline enforced by monadic types and purity is really great at large scale but can be frustrating when you just want to hack something together.
Anyway, it would be interesting to see typical use-cases for Gluon!
* It is intended to easily work with a host language which are likely to be impure. Any functions and types which that host language extend gluon with would also have to be pure which is likely to present awkward or impossible APIs. I also cannot check that the functions are pure so it would be really easy for the host language to make a mistake and accidentally pass in an impure function.
* Pure languages require, at least as I understand, more optimization to perform well and I don't expect to spend much time on an optimizer for the foreseeable future.
* An extension language is more likely to be used by less experienced developers and regardless of my personal preferences, impure languages are what most people are used it.
That being said, I do encourage pure programming as the main paradigm inside the language. The only mutable types which currently exists are the `Ref` type (atomic cell taken from Clojure) and a channel type (`Sender`/`Receiver`) which are used to send values between threads. I might add mutable records at some point if I feel they make sense but currently I am leaning towards keeping them out.
(From my own forays into embedding Lua in a C++ game I found it troublesome to mix state in Lua and C++. This makes me believe (though I don't have any good example of this as of yet) that it is a better pattern to keep all state in the host language and keep the embedded language as pure as possible, keeping mutation to only be "update host state".)
This turned out to be rather lengthy which I didn't expect. To finish it of I would love to find some way to keep the language completely pure if the problems mentioned above could be fixed or worked around. In embedded languages there is already a notion of limiting what the embedded language can do which could map really well to monads (ie in a game you might have Draw monad, Update monad, Sound monad, etc).
> When a token starts on the same line as a token on an earlier line, gluon implicitly adds inserts a block expression
I think this means that lines where tokens start on the same column are part of an implicitly inserted block. The comment on the code snippet is similarly confusing (and seems to have missed a refactor from `id` to `add1`).
Hope that is helpful! Looks like a really nice language.
It's a partial Haskell compiler written in Rust.
Are there any more open source languages of similar nature, using Rust?
I'll need to compare and see if Gluon can be leveraged in any way.
1. https://github.com/jonathandturner/rhai 2. https://github.com/murarth/ketos
[0] http://www.freelists.org/post/luajit/LuaJIT-FFI-Python-CFFI
[1] https://www.gnu.org/software/guile/manual/html_node/Dynamic-...
And yes, Gluon appears have to an extremely low friction interface to Rust. See my comment above.
Did nobody run a simple Google search before picking the name?
Also, this project
https://github.com/freifunk-gluon/gluon
predates GluonHQ by several years.
Now, if Intel were to go after the Atom Text editor, we would agree that'd be pretty silly, no? Obviously they wouldn't, because there is no confusion. Now, if AMD were to start selling ATOMe processors, I'd also agree that Intel would have a reasonable complaint.
There is no reasonable confusion (for the target markets) between this gluon project, gluonhq, and the router gluon project (linked to above).
Trademarks are scoped by product category.
Trademark isn't about inventing new words. It's about one party at a time being able to use the same word as a brand within the same field. It's one of the few aspects of IP law that actually makes good sense.
Moreover, if you allow your trademark to become "public vocabulary", then you lose it. "Aspirin" used to be a Bayer trademark. "Xerox" and "Kleenex" have to work really hard to discourage writers from using those brand names in a generic way, etc.
That may be how it shakes out practically, but it's important to remember the motivation behind trademarks isn't to protect companies, it's to protect consumers from the confusion that ensues when two different entities use the same name. That may seem like a trivial distinction, but it can be important when evaluating a situation based on the spirit of the law. In this case, while the commercial entity may not want an open source project using the same name, that reuse is unlikely to cause confusion for consumers. However the merits of the case are largely irrelevant since a C&D on the part of the commercial entity would likely force a name change long before the courts were ever involved.
The username is about the least interesting part of the url. What persists between forks? What happens if you reupload the project to an alternative host? What's it look like on-disk? What's it called in all the docs?
Not "Marwes's gluon", not "Marwes's github hosted gluon", just "gluon".
In context, the URL is hosting minutiae, not part of the mark.
while http://gluonhq.com/ does not.
In fact, for me, it's the last link on the first page. The rest are all about physics.
Since they are clearly so tiny any claim to trademark might be problematic. Furthermore, the domain is different. They can't assert computers as a domain (gluon gun from Quake if I remember correctly). It is used as a sort of umbrella name for a lot of different products they have but none of them is a programming language.