4 ms·

It is interesting to consider how much the lower abstraction influences the higher abstraction. If you are building on a existing language/runtime/framework the

It 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 ago
Very 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 ago
totally. 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 ago
  You 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 ago
    I'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.
    - jacobr1 3y ago
      Right - in theory any turning-complete-language can bootstrap any other turning-complete-language. But in practice some of the convections and approaches are going to be mixed via some combinations of cognitive load, laziness/inertia, ease of development, etc ...

couchand 3y ago

Very 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 ago

totally. 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 ago
You 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 ago
  I'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.
  - jacobr1 3y ago
    Right - in theory any turning-complete-language can bootstrap any other turning-complete-language. But in practice some of the convections and approaches are going to be mixed via some combinations of cognitive load, laziness/inertia, ease of development, etc ...