31–40 of 41 posts
Earlier quoted context omitted.
Regexes are at least useful for parsing numbers and symbols. But yeah, that shouldn't be where you get stuck.
[\s,] (~@|[\[\]{}()'`~^@]|"(?:\\.|[^\\"]) "?|;. |[^\s\[\]{}('"`,;)] ) Step 0, so I didn't get very far. https://github.com/kanaka/mal/blob/master/process/guide.md#s...
I went through this a while ago (in Prolog). It was interesting, but with a lot of room for improvement. My criticisms as I remember them: - Error messages about output being different from the expected use some sort of very explicit printing mode with lots of quotes and escaping. A message saying that one got "\\\'\\\'" where "\'\\\\'" was expected is needlessly hard to parse when the actual difference is \'\' vs. '…
- Do you have some specific examples? The test cases are marked as either deferrable or optional. You shouldn't ever have to implement optional (and if so that's a bug in the tests or the guide). I think the deferrable items are marked pretty clearly in the guide where they become mandatory in later steps. If it's not clear, then that's a bug.
- This is one of the tensions that exists with trying to make the guide incremental; later features may require re-work of earlier functionality. I do try and minimize that as much as possible although I've found it can really vary depending on the nature of the target language. Note that the primary goal of mal/make-a-lisp is pedagogical (as opposed to say "the easiest way to make your own Lisp"). So sometimes the need to go back and re-work something is in line with that goal.
If you have any concrete guide text or test driver improvements (especially that further the pedagogic goals of mal), I'm always happy to review pull requests! :-)
Earlier quoted context omitted.
Regexes are at least useful for parsing numbers and symbols. But yeah, that shouldn't be where you get stuck.
[\s,] (~@|[\[\]{}()'`~^@]|"(?:\\.|[^\\"]) "?|;. |[^\s\[\]{}('"`,;)] ) Step 0, so I didn't get very far. https://github.com/kanaka/mal/blob/master/process/guide.md#s...
There are online tools to help visualize regex's. Here is a recent tweet including a visualization of mal's tokenizer regex: https://twitter.com/Mehulwastaken/status/1382292764834996230
Earlier quoted context omitted.
Regex to parse lisp expressions?
Yeah little weird since regexes can’t parse context free languages. I suppose most so-called regexes aren’t actually regular expressions, but it still feels like driving screws with a hammer.
This is unintentional given the history of the name of the project explained in another comment on this page, but "mal" in French means "evil", tying into the famous aphorism.
I went through this a while ago (in Prolog). It was interesting, but with a lot of room for improvement. My criticisms as I remember them: - Error messages about output being different from the expected use some sort of very explicit printing mode with lots of quotes and escaping. A message saying that one got "\\\'\\\'" where "\'\\\\'" was expected is needlessly hard to parse when the actual difference is \'\' vs. '…
- There are several reasons for the weird way that the output and expected messages are printed. One of the main reasons is that in order to enable more flexible test case results, the expected output is a regex rather than a plain string, while the output is just a plain string. There is probably a way this could be made clearer. I'll add it to my TODO list to look at. - Do you have some specific examples? The test…
Interesting languages that aren't on the list of implementations: APL/J/Kx Verilog Fortran LISP 1.5
Interesting languages that aren't on the list of implementations: APL/J/Kx Verilog Fortran LISP 1.5
I have a Dyalog APL implementation since 1 year or more on my fork, but still haven't released it because for reasons related to the input/output handling it cannot pass the self hosting tests :( To make the other tests pass, i wrapped the interpreter in a shell scripts that merges stdout and street, and that did the job for all bit the last step (self hosting). The self hosting interpreter (albeit very slow), appear…
This is unintentional given the history of the name of the project explained in another comment on this page, but "mal" in French means "evil", tying into the famous aphorism.
I wouldn't say it was entirely unintentional :-). I was definitely aware that "mal" could mean "evil" when I named it. It was a bit more apropos when mal only had a single implementation in GNU Make macro language.
I did this a while back. I documented my experience in several blog posts, the last of which is [0]. These describe the process, the gotchas and how I got round them. I was working on C# on a Windows box so the result isn't quite the same as the vanilla MAL. I was massively pleased when I got MAL to self-host. [0] https://www.non-kinetic-effects.co.uk/blog/2019/04/28/MAL-5