search

olus2000 / toki-pi-ilo-nanpa

Interpreter for my esolang
MIT License
8 stars 0 forks source link

First off, really cool thing #1

Open IgNaCy07 opened 2 years ago

IgNaCy07 commented 2 years ago

Second off, some things I personally find missing:

  1. [certainly the biggest one] a way to find out what keys are present in a table. Right now, you can only look up a specific key in a kulupu once you know it, but there's no way to find out what the object you're given contains. Something that'd work is an insa verb that takes in a table and returns an array of keys, in no particular order.
  2. a mechanism to split a program into multiple files. Could be at compile time or at run-time - depending on what suits best.
  3. multithreading (or coroutines) would be nice :).
olus2000 commented 2 years ago

Ha! Glad to see you're enjoying the language. This is just an old project of mine, an exercise in creating parsers and compilation. I'm not planning any changes to it as it is not supposed to be a good general purpose language. It has a lot of ugly features that should not be present in a good language, like returning ala on type errors and dynamically scoped variables. It served its role as a fun challenge to make a language that resembles toki pona grammar, and I don't intend to develop it further in a significant way.

That being said, your interest have sparked some will to improve the language in me. I cannot say I will work on it in the upcoming months as I am just starting the semester, but I have some thoughts about the issues you brought up:

Regarding 1: That's a reasonable idea and it should be easy to implement. It's probably going to be the first one I will tackle if I get to doing any of these.

Regarding 2: Programs are just functions in tin, so I could add a new expression like lanpan "program.tin" that would return the function described in the file program.tin. It could then be called just as any other function and it would work well with compilation.

Regarding 3: This is a complicated one. There is a way to implement this nicely on the parser/interpreter side, but distinguishing coroutines from normal functions is never clean. I will have to get another verb to represent yield, maybe pana awen, and either go the python way and make pali that include pana awen behave differently or go the lua way and make them be called with some special constructs like coroutine.create and coroutine.resume. In the former case parsing is way more complicated, in the latter I have to get two more words and handle what happens when pana awen is called in a function not started as a coroutine.

No promises, but I will not close this just yet in case I really find time to work on this again.