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!
Author here, thanks for the kind words :D. The language used to be completely pure and the state type is a remnant from that time (as well as to show and test that higher kinded types such as monads works). I started to allow impure functions a while back though for a few reasons.
* 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).
Agreed, it's a very good overview of the language. In case the author is here, I think there is some confusion in the section about indenting:
> 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.
Rhai [1] and Ketos [2] also exist. I know I have seen one more lisp (which had come further than initial experimentation) but I can't remember what it is called.
How does this interoperate with the Rust program it's embedded in? Is making functions or values available to it as tedious and verbose as in Lua? Or is there some way of calling Rust functions or accessing Rust values automatically from inside embed_lang neé Gluon? I'm assuming it's just as tedious as in Lua, since otherwise it would need powerful runtime reflection, which seems like a feature that Rust wouldn't really have or want.
Lua has one of the cleanest no_magic c-apis of any scripting language. LuaJIT has the cleanest with_magic c-apis of any scripting language. So clean that it has been copied by PyPy [0], Guile [1] and others.
Magic in the LuaJIT sense is automatically parsing C declarations and constructing shims from LuaJIT into native code without having to interact with a C compiler.
Very unfortunate name since "Gluon" is already a commercial entity, sort of a Java counterpart to Xamarin, and almost certainly has trademarks that would overlap. Even if they didn't, it's still a pretty uncool move.
Very unfortunate that a corporate entity chose the name Gluon, as it's already the name that was assigned fifty years ago to a fundamental particle. At least, that's what I get when I do a simple google search.
An "Apple" is a fruit, an "Oracle" is a mythological being, "Yahoo!" has been a slang exclamation for a century, etc, etc, etc.
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.
> It's about one party at a time being able to use the same word as a brand within the same field.
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.
Trademarks aren't domain names. If you're not actively using it, you lose the legal protection.
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.
Trademarks are fairly narrow in what they restrict other people from using. While not a "fundamental particle", is it uncool for Intel to have processors called "Atom", so now no one else can release an "Atom" processor?
Thank you, I shouldn't have reused the incorrect terminology here (it matters). Thanks for bringing this point up, I completely agree with you, because there is no chance of consumer confusion between these products, which is a reasonable standard to adhere to.
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).
Nobody is prevented from using anything. Can you not talk about gluons (or apples, or atoms, or whatever) just because the word has been overloaded with the name of a business?
Um... are you responding to a different thread? I believe that we're in agreement here. It's the original poster who thinks that once a corporate entity has laid claim to a word, other people should feel obligated to avoiding using it.
Calling Gluon the "Java counterpart to Xamarin" is a bit of a stretch. They are a fraction of the size of Codename One which itself is a fraction of the size of Xamarin.
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.
> Is it still a trademark infringement if the repository is under the user's namespace?
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.
If it's an infringement [a matter for lawyers], I doubt there was any malintent. To me, it looks like some developer in Stockholm just picked a name for an open source project.
In the sources there's a component called VM, despite Gluon being statically compiled. Is that more akin to a runtime system or is it a separate VM for the REPL?
The latest LLVM releases have major regressions regarsing JIT performance. Compilation via LLVM has essentially become to time consuming for use in a JIT. Bit of a bummer really.
Embedded languages are not for replacing the outer language with better syntax or whatever. They are for embedding; which in this context means allowing for extensibility using an often-dynamic language which can still talk to the main one. It's a common technique used for creating game modding APIs and such. Lua is historically the language of choice here, and sometimes python. I believe rust has an embedding api for lua somewhere, but having new Rust-specific projects like gluon and rhai is always nice.
The existance of gluon tells you that people like Rust enough that they want to use it for something requiring embedding (these are generally large applications). Or they just want to have fun inventing a language and chose rust as the implementation lang. Neither reflect poorly on rust.
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!