Let's build a simple interpreter for APL, part 2 (2020)
mathspp.comOP here, thanks for sharing!
Feel free to ask any questions you might have in here or in the comments of the blog articles.
The series is not complete yet but rest assured that I haven't given up on it :)
I missed the first part, but will check it out. I'm on sick leave and can't do anything anyway.
My main question so far is: Can you make use of the speed of Array-based languages, but save computation time, by compiling it into a solution-graph-assembly? Sorry, if my wording is to amateurish.
EDIT: What's the difference between symbolic computation, graph computation and array-based symbolic computation? I mean they have different internal representations due to semantics, but look alike mostly.
Would it be possible to "generate" an "optimal" internal structure for an array-based symbolic language like APL, based on the input?
For your convenience, part 1: https://mathspp.com/blog/lsbasi-apl-part1
I don't know if your wording is too amateurish because you are using lingo outside of my knowledge. Does "make use of the speed of array-based language, but save computation time by compiling" refer to using an array language that is compiled? [Co-dfns](https://github.com/co-dfns/co-dfns) compiles a dialect of APL, so that might be interesting to you.
Looks interesting. I see you're implementing in python - did you consider rpython/pypy?
See eg:
https://rpython.readthedocs.io/en/latest/getting-started.htm...
https://morepypy.blogspot.com/2011/04/tutorial-writing-inter...
APL is not at all a symbolic language. It's more like an imperative language with fancy builtins and pretty syntax.
My searches for "graph computation" lead me to think that's just another name for an AST (a very simple one, but one nonetheless), which is what the blog is creating. An implementation could certainly make optimized code for AST subtrees, but it's a lot of complexity.
Regarding your EDIT, I'd love to be able to answer, but alas, that is way out of my depth.
Something that's bothering me is your pairing of "symbolic" and "APL". As far as my (limited) knowledge goes, symbolic languages are those like Mathematica, where you can perform symbolic substitutions, for example. APL is not symbolic, it only uses "weird" characters as its primitives (its built-in functions).
Awesome work, OP. I'm a really fan of your work, you make solid stuff!
How many more parts do you plan to do?
Thanks :D I'm glad you enjoy my work!
For this particular series, I have _no idea_ how many articles it will take to cover enough APL syntax for me to be satisfied with the state of the interpreter. This is mostly a hobby project to help me learn APL and to help me learn about interpreters and related materials, so I feel the need to write about every major step I take, which might actually look like a minor step from the point of view of number of features that get added.
Does my reply make sense?
Arguably modern Fortran, with its array operations is an array language. Some Google Summer of Code projects involve completing LFortran, an interactive Fortran compiler built on top of LLVM. Blog posts are at https://czgdp1807.github.io/2021/07/02/week_7.html and https://rgoswami.me/posts/gsoc21-w4/