Live data from Hacker News

Om is a novel, maximally-simple concatenative language

om-language.org

51–53 of 53 posts

Re: Om is a novel, maximally-simple concatenative language

#51
post #49

Has anyone seen use of a concatenative language, to build vocabulary for broader programming language implementation? So vocabulary for linkage and PICs and stacks and gc and threads and so much else. Not merely "I have this language, so I'll implement and tool it in itself", but moonshot "here's a vocabulary to start implementing other languages... all other languages". Aspiring to implement a C, a V8, an OCaml, and…

Well, there is LLVM. Of course, LLIR isn't concatenative, but if you wrote a LLIR interpreter in your language of choice, you could at least compile a ton of other languages into your language of choice. Which isn't exactly what you're looking for, but you said remotely...

Nod. VAST[1] for LLVM MLIR was mentioned in recent discussion[2]. Hmm, so perhaps with a "degree of absorption" axis, from say idiomatic-reimplementation to might-as-well-be-a-shell-call, with also transliterated-port and c-library-api, perhaps one key threshold might be sufficiently-digested-to-permit-refactoring? Puzzlement. With the pain of dealing with LLIR on one end, to an imaginary scraping of LLVM to a non-C++ knowledge representation sufficient for emitting native implementations... I'm unclear on the space's cost/benefit transitions.

Or consider large-scale code analysis and refactoring tooling - perhaps having that should be a bootstrap target, a unit of absorption is app repo, and a key threshold is ability to refactor source? Or not repo, but arbitrary scale. So Language Server Protocol blended with dynamic loading and calling convention? Smalltalkish "live" image environment with piles of mutating forked repos? That sort of cross-checks - ask a "programmer apprentice" ai, err, or simply a programming team, "I'd like capabilities foo with characteristics bar", a set of forked repos might be an unremarkable outcome. So that might suggest a language bootstrap target of ffi plus refactoring-LSP client?

FFI is an unremarkable bootstrap target, and a refactoring-LSP client gives control over both sides, so maybe next, how to move code across the line? AST scraping and transliteration? Polyglot direct memory access to data types? Suggesting as targets maybe high-end "can exercise and analyze compiler output" ffi, and rich AST tooling? Language implementation, with its specs and test suites, can be a nice context for such work. Which might bring us back around to an emphasis on early implementation of other languages, but with maybe an increased focus on interoperation with existing implementations? Control of config, build, and linkage, might also need emphasis?

Hmm, fun, tnx! [1] https://github.com/trailofbits/vast [2] https://news.ycombinator.com/item?id=33387149

Re: Om is a novel, maximally-simple concatenative language

#52
post #42
post #13

Could someone explain this bit from the intro to me? > Recursion is very efficient in the Om language, due to (a) the "eager" evaluation model enabled by prefix concatenative syntax... How is the syntax of any relevance for the evaluation model? Once the AST is parsed, the syntax is gone and we're just left with pairs of 'operator' and 'operand'.

The syntax allows to describe structures in a way that makes the evaluation model efficient, or even possible. Look at what lengths one has to go constructing a Y combinator when syntax does not allow to refer to the current expression to simply describe recursion.

[deleted]
Post reply on HN