Hacker News new | ask | show | jobs
by vitriol83 2923 days ago
Can anyone suggest a good embedded language with static or at least optional typing ? I feel this is a gap in the market for embedded languages.
4 comments

Lily looked pretty interesting, discussed here a couple years ago

https://github.com/FascinatedBox/lily https://news.ycombinator.com/item?id=12015158

Dyon https://github.com/PistonDevelopers/dyon

(Interesting and very easy to modify, maybe not "production ready")

Thanks for this!

This is by far the most what the fuck language that I've seen in a long while. It displays an astonishing amount of creativity and novel (at least to me) ideas, most of which are probably bad and won't survive for long, but some of them are really cool! Things like "packed loops"

    for i, j { println(list[i][j]) }
or using `return` as a variable without exiting

    return = 8
Really cool!
> or using `return` as a variable without exiting

Also found in the Nim language (no affiliation/loyalty, just in case anyone is curious to see an existing use of this)

https://nim-lang.org/0.18.0/tut1.html#procedures-result-vari...

Many languages have return variables (e.g. Matlab far predates Nim), but this is the first time I saw the name/keyword return itself be used.
The name is 'result' not 'return'.
I seem to recall something similar in an old language (maybe Pascal?) where the way to return something was to assign it to the name of the function.
Fortran does this (still does in F2008). But usually I end up using subroutines instead, since I want the code in question to modify more than one object. Functions can only return one object, and the overhead of packing/unpacking to a struct is annoying.

What Fortran really needs to get is first-class string handling and saner IO. Apart from that being a pain, modern Fortran is a nice language to use.

Pascal you can set and return the "result" variable in a function without declaring it. You can also use the functions name to do the same
Julia also does loops with two indexes.
I think the point of packed loops is that the compiler/runtime figures out the bounds/ranges for each variable automatically.
I wonder if the lack of strongly statically typed embeddable languages is due to an accident or a fundamental limitation of implementations of such languages. Is the type checker code too big? Is it too complex?
Writing a type checker is conceptually much more specialised than just a scripting language. Certainly I have no idea how to write one!
Moreover, designing the actual type system is at least as hard as implementing the type checker. Coming up with a static type system that is flexible/ergonomic, expressive/powerful, sound, easy to use, and also a good match for mutable state and imperative code is really, really difficult, as demonstrated by C, C++, and Java.

A flexible/ergonomic dynamic type system is trivial in comparison. Soundness is handled at runtime when the exact value of each expression is known, and ease of use is almost a given.

Not really. You just need to walk up both types until you find a match. It's similar to a simple eval matcher, which is about 10 lines in lisp.

https://github.com/perl11/Bla has typically the smallest and easiest to understand type inferencer and checker.

It's actually extremely easy, particularly if you're familiar with Prolog (the core algorithm is a couple lines in Prolog, so knowing how that works is useful for implementing it in other languages).

I suspect the lack of statically typed scripting languages is more of a historical accident than anything.