[flagged]
Care to elaborate?
You built a CPU simulator in APL? Bloody legend! What drove that choice?
APL Interpreter – An implementation of APL, written in Haskell (2024)
21–30 of 75 posts
Re: APL Interpreter – An implementation of APL, written in Haskell (2024)
#22Is there an implementation of an APL language (or other any other array language) written in * readable* C that is around 1000 LoC? There are for LISP, FORTH, Prolog, TCL and the like.
What, you don't like Arthur's style?
https://www.jsoftware.com/ioj/iojATW.htm
https://github.com/kparc/ksimple/blob/main/ref/a.c
Slightly less factiously, the ksimple repository has a version with comments.
https://github.com/kparc/ksimple
https://github.com/kparc/ksimple/blob/main/a.c
Note, these aren't APL, but they are in the same family of array languages.
Re: APL Interpreter – An implementation of APL, written in Haskell (2024)
#23> Apparently Haskell’s performance isn’t that bad, but I don’t plan on using Haskell for anything that is remotely performance-sensitive. Trying to optimize Haskell code does sound like an interesting problem, but it might be a lost cause. When the dude uses `foldl` over lists and `foldr` with `(*)` (numeric product) it is not the language that's the lost cause.
In case anyone who doesn't know Haskell: both of these are beginner level mistakes. Using `foldl` causes space leaks and turns your O(1) space algorithm to O(N) space for no good reason. And using `foldr` over lists is good when you are dealing with unevaluated lists and want list fusion, but not when they already exist in memory and will continue to do so. And that doesn't even include the obviously wrong choice of…
> And using `foldr` over lists is good when you are dealing with unevaluated lists and want list fusion, but not when they already exist in memory and will continue to do so.
What's the preffered approach?
Re: APL Interpreter – An implementation of APL, written in Haskell (2024)
#24Earlier quoted context omitted.
Care to elaborate?
Well, you've said you used APL professionally, but judging by https://news.ycombinator.com/item?id=31368299 it was in a university project.
So you go through my profile and assume that you know my professional background? What makes you think that that's the only project where I've used APL?
Such poor quality comment.
Re: APL Interpreter – An implementation of APL, written in Haskell (2024)
#25Earlier quoted context omitted.
Care to elaborate?
You built a CPU simulator in APL? Bloody legend! What drove that choice?
Thanks! I didn't actually build it myself but a professor and other student were also involved. When I joined the project the decision was already made: the professor wanted to use APL and we were using an old CPU architecture book as reference that used APL (Gerritt A. Blaauw, Frederick P. Brooks Jr. Frend, Computer Architecture: Concepts and Evolution 1st Edition).
We almost got the PDP-11 working albeit some extensions like floating point arithmetic.
Re: APL Interpreter – An implementation of APL, written in Haskell (2024)
#26Earlier quoted context omitted.
Well, you've said you used APL professionally, but judging by https://news.ycombinator.com/item?id=31368299 it was in a university project.
So you go through my profile and assume that you know my professional background? What makes you think that that's the only project where I've used APL? Such poor quality comment.
I don't think he went through your profile, suspect he just remembered the discussion he had with you in the linked thread. But how about we end this? it is not productive or interesting.
Re: APL Interpreter – An implementation of APL, written in Haskell (2024)
#27Earlier quoted context omitted.
Well, you've said you used APL professionally, but judging by https://news.ycombinator.com/item?id=31368299 it was in a university project.
So you go through my profile and assume that you know my professional background? What makes you think that that's the only project where I've used APL? Such poor quality comment.
I remembered it, and it seems like a reasonable assumption that your first experience of APL being so bad would put you off doing any more in the future.
Re: APL Interpreter – An implementation of APL, written in Haskell (2024)
#28Earlier quoted context omitted.
In case anyone who doesn't know Haskell: both of these are beginner level mistakes. Using `foldl` causes space leaks and turns your O(1) space algorithm to O(N) space for no good reason. And using `foldr` over lists is good when you are dealing with unevaluated lists and want list fusion, but not when they already exist in memory and will continue to do so. And that doesn't even include the obviously wrong choice of…
> And using `foldr` over lists is good when you are dealing with unevaluated lists and want list fusion, but not when they already exist in memory and will continue to do so. What's the preffered approach?
Usually you want `foldl'` (with ' at the end), the strict version of `foldl`. It prevents the creation of intermediate thunks, so effectively a tail recursive iteration over the list in constant space.
`foldr` I almost never use, but it would be for: the return value is a lazy list and I will only need to evaluate a prefix.
Re: APL Interpreter – An implementation of APL, written in Haskell (2024)
#29Seeing "all built-in functions and operators are single unicode symbols" stood out to me, given that APL existed well before Unicode did. It's not that it's wrong today, but that wasn't always the case. My father used APL back in high school, and that was before the earliest year mentioned in the "History" section of the Unicode Wikipedia article.
Re: APL Interpreter – An implementation of APL, written in Haskell (2024)
#30> Array programming is similar to functional programming – the primary way to control execution involves composition of functions – but APL tends to encourage the reliance on global properties and sweeping operations rather than low-level recursion4.
This AoC solution is, indeed, quite the functionista! Better yet, it leans heavily into point-free expressions. The style is pretty popular amongst APL language enthusiasts and puzzlers.
That said, you actually see quite different APL styles in the wild:
- Pointed declarative style, also a popular with functional programmers (e.g. anything like this[0] from the dfns workspace)
- Imperative, structured programming, very common in legacy production systems (e.g. this[1] OpenAI API interface)
- Object-oriented, also common in somewhat newer production environments (e.g. the HTTP interface[2])
- Data-parallel style (e.g. Co-dfns[3])
Heck, APL even has lexical and dynamic scope coexisting together. IMHO, it's truly underrated as a language innovator.
[0]:https://dfns.dyalog.com/c_match.htm
[1]:https://github.com/Dyalog/OpenAI/blob/main/source/OpenAI.apl...
[2]:https://github.com/Dyalog/HttpCommand/blob/master/source/Htt...
[3]:https://github.com/Co-dfns/Co-dfns/blob/master/cmp/PS.apl