Live data from Hacker News

APL Interpreter – An implementation of APL, written in Haskell (2024)

scharenbroch.dev

1–10 of 75 posts

Re: APL Interpreter – An implementation of APL, written in Haskell (2024)

#4
My favorite language used to interpret my most hated language (used both professionally).

There are several things I disagree with regarding Haskell but it's understandable given that this is OP's first time using the language (like a "monad's internal state"), but I want to highlight one particular observation:

> This uncertainty of time of evaluation also makes catching errors difficult, because calling catch on the function that throws the error will not necessarily catch that error

It's important to distinguish between imprecise exceptions (ex. calls to `error `, `undefined`, and the like) and synchronous exceptions (async exceptions are not important for the article).

> Catch must be called on the function that forces evaluation on that error. This is something that is hard to trace, and something that types don’t help much with.

The types are actually the most important part here! Synchronous exceptions cannot be thrown by pure code (as long as we're not dealing with escape hatches like `unsafePerformIO`), while IO code can throw and catch all kind of exceptions .

Re: APL Interpreter – An implementation of APL, written in Haskell (2024)

#6
> 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.

Re: APL Interpreter – An implementation of APL, written in Haskell (2024)

#10
post #8

Earlier 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.

Regarding that link

>GNU is free but pretty much abandoned. Support for Windows was (is?) nonexistent.

GNU APL was never abandoned, dev just went a long time without doing a proper release. I believe the Windows issue is just with cygwin, never looked into it since I don't use Windows.

Post reply on HN