4 ms·

This is an impressive effort! It seems that Gluon has taken inspiration from Haskell right down to the monadic solution to mutable state: https://github.com/Ma

by cfallin 10y ago

This is an impressive effort! 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 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!

Marwes 10y ago
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).
- cfallin 10y ago
  Ah hah -- I had missed your `Ref` and channel types. Thanks for the detailed explanation!

by cfallin 10y ago

Marwes 10y ago

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).

cfallin 10y ago
Ah hah -- I had missed your `Ref` and channel types. Thanks for the detailed explanation!