3 ms·
> actually creating a working language is a big overhead Languages, with first class values, pattern matching, rich types, type inference and even fancy RTS, o
by thesz 3y ago
> actually creating a working language is a big overhead
Languages, with first class values, pattern matching, rich types, type inference and even fancy RTS, often can be embedded in Haskell.
For one example, it is very much possible to embed into Haskell a Rust-like language, even with borrow checking (which is type-checking time environment handling, much like linear logic). See [1], [2] and [3].
[1] http://blog.sigfpe.com/2009/02/beyond-monads.html
[2] https://www.cs.tufts.edu/comp/150FP/archive/oleg-kiselyov/overlooked-objects.pdf
[3] http://functorial.com/Embedding-a-Full-Linear-Lambda-Calculus-in-Haskell/linearlam.pdf
Work in [3] can be expressed using results from [1] and [2], I cited [3] as an example of what proper type system can do.
These results were available even before the work on Rust began. But, instead of embedding Rust-DSL into Haskell, authors of Rust preferred to implement Rust in OCaml.
They do the same again.
- pas 3y ago> instead of embedding Rust-DSL into Haskell, authors of Rust preferred to implement Rust in OCaml why? and how much does it matter, if the goal is to have a compiler/interpreter? (as I assume is the case with Dada, and was with Rust)
- argiopetech 3y agoR&D. Bootstrapping.
- ericyd 3y agoAre you suggesting that creating a new programming language from scratch is a trivial exercise? If yes, wow. If no, I think the intention of your comment could be more clear, particularly regarding the quote you took from the original comment.
- couchand 3y agoI suspect the GP was merely suggesting a less-costly alternative. Perhaps building a complete standalone compiler or interpreter is hard, but we're all designing APIs in our programming languange of choice day in and day out. Both strategies are very hard, but one of then is "build a prototype in a weekend" hard and one of them is "build a prototype is a month" hard.
- jacobr1 3y agoIt is interesting to consider how much the lower abstraction influences the higher abstraction. If you are building on a existing language/runtime/framework then you can inherit more functionality and move faster, but also you implicitly will inherent many of the design decisions and tradeoffs.
- couchand 3y agoVery good point. See, for instance Kiselyov's embedding of his tagless final form: https://www.okmij.org/ftp/tagless-final/course/lecture.pdf https://www.okmij.org/ftp/tagless-final/course/lecture.pdf
- convolvatron 3y agototally. for me the interplay between the host language and the target language is hardest thing for me to manage when bringing up a new environment. it really doesn't seem like it should be a big deal, but it comes down to the sad reality that we operate by rote alot of the time, and completely switching semantic modes when going between one world and the other is confusing and imposes a real cost. I'm still not that good at it, but my best strategy to date is to try to work in a restricted environment of both the host and the target that are nearly the same.
- thesz 3y agoYou can have target language to be as far fom host language as you like. For one example, again, borrowed fom Haskell universe, is Atom [1]. It is a embedded language to design control programs for hard real-time systems, something that is as far from Haskell area of application as... I don't know, Sun and Pluto? [1] https://hackage.haskell.org/package/atom-1.0.13 https://hackage.haskell.org/package/atom-1.0.13
- convolvatron 3y agoI'm sorry - of course you can. my problem is that switching back and forth I internally get them confused. and I start moving the target language to be closer to the host. while this might be my failing alone, I've seen this happen quite a bit in other language design projects.
- arethuza 3y agoCreating a "new" programming language isn't that difficult - creating something that is interesting, elegant and/or powerful requires a lot of thought and that is difficult.
- ericyd 3y agoFor me, creating a new programming language which is suitable for general purpose programming would be extremely hard, regardless of how novel or good it is. But, fair point that "hard" is always subjective.
- arethuza 3y agoI think I was being over literal about the "language" part - it's certainly possible to create a very simple language in a short time but actual productivity would require a lot of libraries and tooling and I suspect that is much more work than the core language.
- thesz 3y agoQuite the contrary. You need to use existing facilities (type checking, pattern matching combinators, etc) of a good implementation language as much as possible before even going to touch yacc or something like that.