9 ms·

And after forth, there's Tcl. And lisp. These three are the most easily implementable, for which we have so many dialects of them. What other languages are so s

by smlckz 6y ago

And after forth, there's Tcl. And lisp. These three are the most easily implementable, for which we have so many dialects of them. What other languages are so small, simple and easy to implement?

qart 6y ago
Probably APL/K/J/Q/Kona.
- notagoodidea 6y ago
  mandatory One page Thing[1] for J. [1]:https://code.jsoftware.com/wiki/Essays/Incunabulum https://code.jsoftware.com/wiki/Essays/Incunabulum
Cieplak 6y ago
Might enjoy browsing through A Bestiary of Single-File Implementations of Programming Languages [1]. [1] https://github.com/marcpaq/b1fipl https://github.com/marcpaq/b1fipl
- mumblemumble 6y ago
  It's slightly interesting to me that neither object-oriented nor functional-in-the-Backus-sense languages are represented here. FP, I suppose I can understand, since ML started off with a plethora of discrete features, and things have only grown from there. Great paradigm, but not exactly something you'd want to even try to cram into a single file. But I might have expected to see some sort of Smalltalk- or Io-inspired language in the list.
stevekemp 6y ago
BASIC is another simple-to-implement language, especially if you go for something like tinybasic. I had fun recently writing something like forth. I'd probably like to try doing it properly next time - using a proper return-stack so that `if` and similar primitives can be implemented in the language itself, rather than in the hardcoded fashion I have at the moment.
greggman3 6y ago
sidtran, which Sid Meier used to use in the 8bit days (and maybe 16 bit). I don't know if there is any spec or sample anywhere on the net but was forth like stack based with DUP, SWAP, POP, etc. It had to be small since it ran on machines with 32k-64k https://www.google.com/search?q=%22sidtran%22+sid+meier https://www.google.com/search?q=%22sidtran%22+sid+meier
z29LiTp5qUC30n 6y ago
I'd argue the easiest to implement language is macro-assembly then the C subset known as cc_x86 https://github.com/oriansj/mescc-tools-seed https://github.com/oriansj/mescc-tools-seed
Twisol 6y ago
The core of Prolog (Horn clause resolution) is not terribly difficult to implement, IMO. Learning how to implement unification with backtracking is an edifying experience!
- carapace 6y ago
  I did that, and it was. :) I wrote some (incomplete) type inference code for Joy (a Forth-like functional language) and that (among other things) led me to Prolog. I was surprised how simple it is both syntax and semantics. ( https://joypy.osdn.io/notebooks/Types.html https://joypy.osdn.io/notebooks/Types.html ) I eventually reimplemented Joy in Prolog and discovered that the type inference code was identical to the interpreter code! ( https://git.sr.ht/~sforman/Thun/tree/master/source/thun.pl https://git.sr.ht/~sforman/Thun/tree/master/source/thun.pl ) For anyone looking to implement a Prolog Paul Tarau has an interesting approach: "A Hitchhiker’s Guide to Reinventing a Prolog Machine" https://www.cse.unt.edu/~tarau/research/2017/eng.pdf https://www.cse.unt.edu/~tarau/research/2017/eng.pdf
  - Twisol 6y ago
    > For anyone looking to implement a Prolog Paul Tarau has an interesting approach: Fascinating! I ended up designing my own Prolog virtual machine rather than mimicking the WAM, using a union-find address space to represent unified terms, with hopes to make it a persistent data structure and so implement backtracking over unification by cheap checkpointing. I never got around to it, but it left me with a fascination with Prolog internals.
    - carapace 6y ago
      That sounds cool and promising, did you write it up anywhere?
      - Twisol 6y ago
        No, but I should! It's pretty low-hanging fruit as far as write-ups go...
progre 6y ago
The language core of SmallTalk seems pretty straightforward and lots of people have built their own. But then there is all those standard objects to implements...
- scroot 6y ago
  This is true. However, the language, the core objects, and the virtual machine implementation are described in the Blue Book well enough for someone to implement all of it. Like Oberon it's a description of a complete computing system that fits in a single book
  - jecel 6y ago
    Another book from back then was "A Little Smalltalk" by Tim Budd. http://web.engr.oregonstate.edu/~budd/Books/little/ http://web.engr.oregonstate.edu/~budd/Books/little/ http://rmod-files.lille.inria.fr/FreeBooks/LittleSmalltalk/ALittleSmalltalk.pdf http://rmod-files.lille.inria.fr/FreeBooks/LittleSmalltalk/A... It was a bit different than the Blue Book, though version 3 was a lot closer to Smalltalk-76 and version 4 to Smalltalk-80. The number of classes and methods remained very small and the C code for the virtual machine is still simple and easy to understand. Several projects forked Little Smalltalk
- i_don_t_know 6y ago
  Lars Bak (and others) founded a startup that tried to use a Smalltalk VM for embedded systems: OOVM. See for example: http://esug.org/data/ESUG2003/lars@2bbak@2besug.pdf http://esug.org/data/ESUG2003/lars@2bbak@2besug.pdf There‘s also a Master‘s thesis about the implementation: https://verdich.dk/kasper/thesis.html https://verdich.dk/kasper/thesis.html And another overview: https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.84.7354&rep=rep1&type=pdf https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.84... Among other things, Lars Bak worked on the StrongTalk VM that became the Java VM. And he is/was behind the V8 JavaScript engine.
kumarsw 6y ago
With the current proliferation of structured file formats (xml, json, yaml, toml, protobuf, messagepack) I got wondering if there is room for a format based on one of these stack/list based languages that could be easily implemented even on microcontrollers or on some locked-down corporate machine with only a decade-old IDE and no third-party libraries. My original thought was something that was a subset of Forth, though I get the impression that vanilla Forth is a headache dealing with data types other than ints and the result would be sufficiently custom that it wouldn't be worth it. Something based on TCL or S-expressions sounds like it would give the needed flexibility, though maybe at the expense of being able to implement on microcontrollers. Has anyone played with parsing either of those? I know that the PCB designer tool in KiCAD uses S-expressions so it's been done before.
- DennisP 6y ago
  Postscript is a stack language, with strong typing and Lisp-inspired data structures. Maybe that could be a model for what you're talking about. https://en.wikipedia.org/wiki/PostScript#The_language https://en.wikipedia.org/wiki/PostScript#The_language
- blacksqr 6y ago
  Forth implemented in Tcl: https://github.com/wejgaard/TclForth https://github.com/wejgaard/TclForth
- megameter 6y ago
  The limitation in crossing the boundary from a data language to an executable language is mostly down to contrasts between "divisions" within and "bindings" across data. Some Forths include an additional floating point stack, and many implement types on top, but the basic nature of the thing is not to address division of data into sizes, fields and regions of memory directly, and instead to let the user define those things. Where Forth is powerful is in allowing layers of binding to build up, since the language can flip-flop between execution and compilation easily - that's why basic control flow words like IF - THEN - ENDIF can be bootstrapped, as can any desired type checker. But in the process, the binding format - the Forth dictionary - becomes one of the core dependencies. The "just data" formats like JSON only approach the topic of binding in limited ways like key-value structures or a defined schema. The types are static during parsing, so the data is less tangled and context-driven and more approachable through a simple divide-and-conquer.

by smlckz 6y ago

And after forth, there's Tcl. And lisp. These three are the most easily implementable, for which we have so many dialects of them. What other languages are so small, simple and easy to implement?

qart 6y ago

Probably APL/K/J/Q/Kona.

notagoodidea 6y ago
mandatory One page Thing[1] for J. [1]:https://code.jsoftware.com/wiki/Essays/Incunabulum https://code.jsoftware.com/wiki/Essays/Incunabulum

Cieplak 6y ago

Might enjoy browsing through A Bestiary of Single-File Implementations of Programming Languages [1]. [1] https://github.com/marcpaq/b1fipl https://github.com/marcpaq/b1fipl

mumblemumble 6y ago
It's slightly interesting to me that neither object-oriented nor functional-in-the-Backus-sense languages are represented here. FP, I suppose I can understand, since ML started off with a plethora of discrete features, and things have only grown from there. Great paradigm, but not exactly something you'd want to even try to cram into a single file. But I might have expected to see some sort of Smalltalk- or Io-inspired language in the list.

stevekemp 6y ago

BASIC is another simple-to-implement language, especially if you go for something like tinybasic. I had fun recently writing something like forth. I'd probably like to try doing it properly next time - using a proper return-stack so that `if` and similar primitives can be implemented in the language itself, rather than in the hardcoded fashion I have at the moment.

greggman3 6y ago

sidtran, which Sid Meier used to use in the 8bit days (and maybe 16 bit). I don't know if there is any spec or sample anywhere on the net but was forth like stack based with DUP, SWAP, POP, etc. It had to be small since it ran on machines with 32k-64k https://www.google.com/search?q=%22sidtran%22+sid+meier https://www.google.com/search?q=%22sidtran%22+sid+meier

z29LiTp5qUC30n 6y ago

I'd argue the easiest to implement language is macro-assembly then the C subset known as cc_x86 https://github.com/oriansj/mescc-tools-seed https://github.com/oriansj/mescc-tools-seed

Twisol 6y ago

The core of Prolog (Horn clause resolution) is not terribly difficult to implement, IMO. Learning how to implement unification with backtracking is an edifying experience!

carapace 6y ago
I did that, and it was. :) I wrote some (incomplete) type inference code for Joy (a Forth-like functional language) and that (among other things) led me to Prolog. I was surprised how simple it is both syntax and semantics. ( https://joypy.osdn.io/notebooks/Types.html https://joypy.osdn.io/notebooks/Types.html ) I eventually reimplemented Joy in Prolog and discovered that the type inference code was identical to the interpreter code! ( https://git.sr.ht/~sforman/Thun/tree/master/source/thun.pl https://git.sr.ht/~sforman/Thun/tree/master/source/thun.pl ) For anyone looking to implement a Prolog Paul Tarau has an interesting approach: "A Hitchhiker’s Guide to Reinventing a Prolog Machine" https://www.cse.unt.edu/~tarau/research/2017/eng.pdf https://www.cse.unt.edu/~tarau/research/2017/eng.pdf
- Twisol 6y ago
  > For anyone looking to implement a Prolog Paul Tarau has an interesting approach: Fascinating! I ended up designing my own Prolog virtual machine rather than mimicking the WAM, using a union-find address space to represent unified terms, with hopes to make it a persistent data structure and so implement backtracking over unification by cheap checkpointing. I never got around to it, but it left me with a fascination with Prolog internals.
  - carapace 6y ago
    That sounds cool and promising, did you write it up anywhere?
    - Twisol 6y ago
      No, but I should! It's pretty low-hanging fruit as far as write-ups go...

progre 6y ago

The language core of SmallTalk seems pretty straightforward and lots of people have built their own. But then there is all those standard objects to implements...

scroot 6y ago
This is true. However, the language, the core objects, and the virtual machine implementation are described in the Blue Book well enough for someone to implement all of it. Like Oberon it's a description of a complete computing system that fits in a single book
- jecel 6y ago
  Another book from back then was "A Little Smalltalk" by Tim Budd. http://web.engr.oregonstate.edu/~budd/Books/little/ http://web.engr.oregonstate.edu/~budd/Books/little/ http://rmod-files.lille.inria.fr/FreeBooks/LittleSmalltalk/ALittleSmalltalk.pdf http://rmod-files.lille.inria.fr/FreeBooks/LittleSmalltalk/A... It was a bit different than the Blue Book, though version 3 was a lot closer to Smalltalk-76 and version 4 to Smalltalk-80. The number of classes and methods remained very small and the C code for the virtual machine is still simple and easy to understand. Several projects forked Little Smalltalk
i_don_t_know 6y ago
Lars Bak (and others) founded a startup that tried to use a Smalltalk VM for embedded systems: OOVM. See for example: http://esug.org/data/ESUG2003/lars@2bbak@2besug.pdf http://esug.org/data/ESUG2003/lars@2bbak@2besug.pdf There‘s also a Master‘s thesis about the implementation: https://verdich.dk/kasper/thesis.html https://verdich.dk/kasper/thesis.html And another overview: https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.84.7354&rep=rep1&type=pdf https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.84... Among other things, Lars Bak worked on the StrongTalk VM that became the Java VM. And he is/was behind the V8 JavaScript engine.

kumarsw 6y ago

With the current proliferation of structured file formats (xml, json, yaml, toml, protobuf, messagepack) I got wondering if there is room for a format based on one of these stack/list based languages that could be easily implemented even on microcontrollers or on some locked-down corporate machine with only a decade-old IDE and no third-party libraries. My original thought was something that was a subset of Forth, though I get the impression that vanilla Forth is a headache dealing with data types other than ints and the result would be sufficiently custom that it wouldn't be worth it. Something based on TCL or S-expressions sounds like it would give the needed flexibility, though maybe at the expense of being able to implement on microcontrollers. Has anyone played with parsing either of those? I know that the PCB designer tool in KiCAD uses S-expressions so it's been done before.

DennisP 6y ago
Postscript is a stack language, with strong typing and Lisp-inspired data structures. Maybe that could be a model for what you're talking about. https://en.wikipedia.org/wiki/PostScript#The_language https://en.wikipedia.org/wiki/PostScript#The_language
blacksqr 6y ago
Forth implemented in Tcl: https://github.com/wejgaard/TclForth https://github.com/wejgaard/TclForth
megameter 6y ago
The limitation in crossing the boundary from a data language to an executable language is mostly down to contrasts between "divisions" within and "bindings" across data. Some Forths include an additional floating point stack, and many implement types on top, but the basic nature of the thing is not to address division of data into sizes, fields and regions of memory directly, and instead to let the user define those things. Where Forth is powerful is in allowing layers of binding to build up, since the language can flip-flop between execution and compilation easily - that's why basic control flow words like IF - THEN - ENDIF can be bootstrapped, as can any desired type checker. But in the process, the binding format - the Forth dictionary - becomes one of the core dependencies. The "just data" formats like JSON only approach the topic of binding in limited ways like key-value structures or a defined schema. The types are static during parsing, so the data is less tangled and context-driven and more approachable through a simple divide-and-conquer.