[HN Gopher] LunarML - Standard ML compiler that produces Lua/Jav...
___________________________________________________________________
LunarML - Standard ML compiler that produces Lua/JavaScript
Author : injuly
Score : 94 points
Date : 2024-05-22 13:03 UTC (2 days ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| humzashahid98 wrote:
| This is a very cool project.
|
| There is also MLKit's SMLtoJs which compiles to Javascript, but
| not to Lua.
|
| https://github.com/melsman/mlkit/blob/master/README_SMLTOJS....
| dybber wrote:
| Which in turn compiles itself into Javascript, such that you
| can run the SMLtoJS compiler in the browser, e.g. it should be
| possible to make it accept <script> tags with SML code.
| programjames wrote:
| I got tricked up by the acronym. This compiles the programming
| language "Standard ML [Meta Language]" to the programming
| languages Lua or JavaScript. It's not a machine learning
| compiler.
| hayley-patton wrote:
| I can no longer google "ML Kit" and find the ML compiler,
| instead I find Google's ML library. You win some, you lose
| some.
| zem wrote:
| those of us interested in the ML language family have been
| disappointed for years every time a headline turns out to be
| yet another machine learning thing, so I'm glad to see this one
| was actually an ML (:
| fortyseven wrote:
| That's okay, I thought it was machine language at first.
| _delirium wrote:
| Blog post announcing it:
| https://minoki.github.io/posts/2023-12-17-lunarml-release.ht...
| sgt_bilko wrote:
| On work laptop (Windows) at the moment. Will get to it in the
| weekend, but can some kind soul tell me: is the lua and js
| generated code readable?
|
| (Standard for readable for me is ReScript)
| weatherlight wrote:
| I've always loved Standard ML and feel it's never gotten the love
| that it deserved.
|
| It was my introduction to typed FP concepts via this course (Part
| A) https://www.coursera.org/learn/programming-languages
| mattpallissard wrote:
| Agreed! But OCaml is close enough that I don't despair.
|
| Chris okasaki's purely functional data structures is an
| excellent intro to SML if your familiar with FP already.
| weatherlight wrote:
| I've heard good things about this book, I didn't realize the
| examples were in SML. :)
| Hirrolot wrote:
| Is there any reason to use SML instead of OCaml in 2024?
| SassyBird wrote:
| Multicore programming that isn't covered in stickers about
| being bleeding edge and not fully integrated with the rest of
| stdlib(s?). Since the 90s. :)
|
| And a minor point: operator arguments (as well as curried
| arguments) are evaluated left-to-right, not right-to-left
| like in OCaml.
| someplaceguy wrote:
| > Is there any reason to use SML instead of OCaml in 2024?
|
| * Many compilers and transpilers available. Don't like
| LunarML? Maybe try Poly/ML. Or MLton. Or MLKit. Or SML/NJ.
| Etc. All of the above are pretty much complete and production
| quality, and there are quite a few more.
|
| * The language has a formal specification which means there's
| a document formally specifying what all the constructs in the
| language should do. In contrast, if you wanted to build your
| own OCaml compiler/transpiler/interpreter, you'd basically
| have to follow whatever the main OCaml implementation does,
| which changes from one version to the next, so you'd always
| be playing catch-up.
|
| * The formal specification hasn't changed since 1997. This
| means that once written, your SML code should work the same
| forever. You no longer have to worry about your programs (or
| their dependencies) breaking when you upgrade to a new
| version of OCaml.
|
| * Compared to OCaml, your single-threaded programs will
| usually run faster if you compile them with MLton, mostly due
| to whole-program optimization / monomorphization and unboxed
| native integers, reals and arrays.
|
| * Some SML implementations have interesting extensions, which
| you can use (at the cost of being tied to that
| implementation). For example, MLKit supports memory regions
| (i.e. more efficient memory management in some cases). SML#
| (which is _not_ related to .NET) supports seamless
| integration with SQL and other interesting features. Some
| implementations support multi-threading natively and /or
| different forms of parallelism. Most of them also support
| some form of FFI to interface with C or other languages.
|
| * SML programs are easier to port to CakeML than any other
| language, since CakeML is mostly an SML subset. CakeML not
| only allows you to formally verify that your program is
| correct (or that it has certain desirable properties), but it
| also has a compiler that is formally proven to be correct, so
| your compiled CakeML programs are (mostly) guaranteed to be
| free of miscompilation bugs as well.
| hajile wrote:
| StandardML is the most practical functional programming
| language IMO. It concedes that mutation improves performance,
| laziness is hard for humans to optimize, and side effects
| exist. At the same time, it has avoided the weirdness of Ocaml
| or the unnecessary complexity of F#.
|
| It's use of structural typing (like Typescript) rather than
| nominal typing is great. It winds up feeling a lot like a
| scripting language, but with better type safety than most non-
| scripting languages. The CML (concurrent ML) proposals are also
| much more mathematically grounded, consistent, and nice to use
| compared to most other languages.
| psd1 wrote:
| I've had a great time discovering Fable, which compiles F# to JS
| or TS.
|
| The cost of moving from VSCode to neovim has always put me off,
| but if I could write the config in F# it would tempt me more.
|
| How far is standard ML from F#?
|
| Is there any existing compiler for F# => Lua?
| lysecret wrote:
| Have you been using Fable? What has been your experience?
| psd1 wrote:
| Not in production.
|
| As an F# newbie, I hit some incompatibility early on with my
| initial library choices. Not everything works in fable. When
| I found Safe Stack, that went away.
|
| Then it was great. Hot reload; generated js is passable; I'm
| doing front end in F# with zero JS and almost no html.
| JaggerJo wrote:
| I've used Fable in production. It just works most of the
| time, but it's not seamless.
| humzashahid98 wrote:
| Standard ML is pretty simple and easy to pick up, but a weak
| point is the lack of { record with updatedValue } syntax to
| create a new record which is the same as an existing one but
| with some value changed. You have to specify every field in the
| record which can be a pain depending on how large your record
| is.
|
| Standard ML has some nice features though and I think what I
| mentioned is the only serious shortcoming (except for ecosystem
| if that's important to you).
|
| Standard ML is also structurally (but strongly) typed, unlike
| F# and the vast majority of nominally typed languages, which is
| rare but nice.
|
| type person = { age : int, name : string }
|
| is the same as the type
|
| type animal = { age : int, name = string }
|
| but this hasn't been an issue foe me, and structural typing
| means you can avoid defining the type at all which is
| convenient for small records.
|
| For example, a function to increment age has no need for you to
| define the type.
|
| fun grow { name, age } = { name = name, age = age + 1 }
|
| I think Standard ML helps you understand the origin of some
| common FP idioms. Like tuples are really just records and SML
| treats them as such. The empty record {} is the same as the
| empty tuple (): both are the unit type. And a record like { 1 :
| "a", 2 : "b" } is exactly the same as the tuple ("a", "b").
| sshine wrote:
| > _How far is standard ML from F#?_
|
| There was a time when F# was just an OCaml extension for .NET,
| but it has developed a lot since.
|
| You may not find a lot of in-depth comparisons between F# and
| Standard ML, because Standard ML isn't widely mentioned outside
| of academic research. But you do find comparisons between F#
| and OCaml, and that may paint a very similar picture:
|
| https://jkone27-3876.medium.com/comparing-ocaml-to-f-f75e4ab...
|
| The most significant differences I can think of are:
|
| 1) Standard ML and OCaml have a higher-order module system, and
| F# has interfaces that you can parameterise over generics.
|
| 2) The OCaml ecosystem is functional code on top of functional
| code, and F# is made to interact with non-functional code on
| .NET. (As for Standard ML, there isn't much of an ecosystem.)
| neonsunset wrote:
| Unless you are targeting browser, _not_ using .NET as back-end
| for F# seems like a poor idea as you really are sacrificing the
| tooling and _a lot_ of performance.
| ihumanable wrote:
| If you haven't taken a plunge into Standard ML or OCaml and are
| interested, I can't suggest this playlist enough
| https://youtu.be/MUcka_SvhLw?si=rc4ele_0WcjwLFR3
|
| It's such a lovely introduction to Ocaml and programming in
| general and has a free online textbook. It's a lot of videos but
| each one is 5-10 minutes so it's very easy to hop in and out.
___________________________________________________________________
(page generated 2024-05-24 23:02 UTC)