Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

scharenbroch.dev

Post reply on HN
Print view View original

51–60 of 75 posts

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

#51

Post by tome »

itishappy wrote: post #23
kccqzy wrote: post #12

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

I have the definitive answer to this question in my article “foldl traverses with State, foldr traverses with anything”

https://h2.jaguarpaw.co.uk/posts/foldl-traverses-state-foldr...

In short: use foldl’ when you’re iterating through a list with state. foldr can be used for anything else, but I recommend it for experts only. For non-experts I expect it’s easier to use for_. For more details about that see my article “Scrap your iteration combinators”.

https://h2.jaguarpaw.co.uk/posts/scrap-your-iteration-combin...

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

#52

Post by tome »

valcron1000 wrote: post #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 th…

Regarding catch, yes, I agree types help, but they can help even more! I suggest an IO-wrapper effect system (mine is called Bluefin; effectful is also a good choice). Then there is absolutely no ambiguity about where an exception can be handled. There is exactly one place -- no more, no less. It makes dealing with exceptions very easy.

https://hackage.haskell.org/package/bluefin-0.0.16.0/docs/Bl...

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

#53

Post by tome »

pierrebeaucamp wrote: post #46
instig007 wrote: post #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.

> When the dude uses `foldl` over lists and `foldr` with `(*)` (numeric product) it is not the language that's the lost cause. This is a great example of Haskell's community being toxic. The author clearly mentioned they're new to the language, so calling them a "lost cause" for making a beginner mistake is elitist snobbery. I usually don't point these things out and just move on with my life, but I went to a Haskell…

Can I ask which conference? Did people behave towards you in that way at that conference, or are you referring to behaviour online? I will try to use whatever authority I have in the Haskell community to improve the situation.

(Still, hopefully in this case it's clear from instig007's reply that it's not a member of the Haskell community behaving in that way.)

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

#54

Post by _glass »

librasteve wrote: post #36

this is pretty cool i think the first raku (perl6) parser (pugs) was written in Haskell, certainly all the team learned Haskell before they started

Done by Audrey Tang who later on became Minister of Digital Affairs of Taiwan.

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

#55

Post by kccqzy »

tome wrote: post #51
itishappy wrote: post #23

Earlier quoted context omitted.

> 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?

I have the definitive answer to this question in my article “foldl traverses with State, foldr traverses with anything” https://h2.jaguarpaw.co.uk/posts/foldl-traverses-state-foldr... In short: use foldl’ when you’re iterating through a list with state. foldr can be used for anything else, but I recommend it for experts only. For non-experts I expect it’s easier to use for_. For more details about that see my article…

Is it really easier to use for_? It forces you to think about effects rather than pure data. So you end up packaging data into effects through State or similar monads. So is it really easier if you force people to use Monad (well technically Applicative)?

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

#56

Post by xelxebar »

ofalkaed wrote: post #40
xelxebar wrote: post #34

Earlier quoted context omitted.

Not that I know of, unfortunately. This is, IMHO, the biggest pain point of APL pedagogy at the moment. I'm actually working on some resources, but they're still gestating. For non-event driven systems, the short story is to organize application state as a global database of inverted tables and progressively normalize them such that short APL expressions carry the domain semantics you want. For event driven systems,…

>IMHO, the biggest pain point of APL pedagogy at the moment It is the one that always trips me up. I just started in on my third attempt at learning APL/array languages, both previous times I got to the same point where I was mostly at a loss of how to apply it all. So I move on and forget all that I learned until the next time and have to start over. Thankfully the last attempt seems to have mostly stuck as far as k…

Yes, I'm one of the few regularly in the Orchard. There's also the APL Farm discord, which is chattier.

In the off chance you've not see this: https://aplwiki.com/wiki/Chat_rooms_and_forums

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

#57

Post by kccqzy »

pierrebeaucamp wrote: post #46
instig007 wrote: post #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.

> When the dude uses `foldl` over lists and `foldr` with `(*)` (numeric product) it is not the language that's the lost cause. This is a great example of Haskell's community being toxic. The author clearly mentioned they're new to the language, so calling them a "lost cause" for making a beginner mistake is elitist snobbery. I usually don't point these things out and just move on with my life, but I went to a Haskell…

Newcomers need the self-awareness to understand that they are newcomers and that their opinions are more often than not wrong. This author doesn't have that humility.

It is simply aggravating to see newcomers without humility speak with an authoritative tone on subjects they barely know.

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

#58

Post by nickzelei »

itishappy wrote: post #17
nickzelei wrote: post #16

Interesting read! On a semi-related topic: I tried learning Haskell this past weekend out of curiosity that I last tried it some 10+ years ago while still in college. I found resources for it scant. Coming from more modern languages/tooling like Go/Rust, I also struggled quite a bit with installation and the build/package system. I tried the stack template generator for yesod/sqlite and after some 15 minutes of it in…

My understanding is that Cabal has more or less supplanted Stack. Use GHCup to install everything, then use `cabal init`, `cabal run`, or `cabal repl` like you would in Go/Rust. Stack builds on top of Cabal, and used to solve a bunch of problems, but the reasons for it's existence are no longer super relevant. It still works totally fine if that's your thing though.

That is so interesting and is a point where GPT has failed me if this is true. My understanding was the stack was the choice due to having better ergonomics over cabal. Apparently that isn't true? I Found that stack init was pretty decent at setting up a project structure, but can't say I tried cabal init.

I initially installed ghcup via homebrew but found that did not set things up correctly and had to follow the install from their site, which made things work more smoothly.

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

#59

Post by nickzelei »

cosmic_quanta wrote: post #35
nickzelei wrote: post #16

Interesting read! On a semi-related topic: I tried learning Haskell this past weekend out of curiosity that I last tried it some 10+ years ago while still in college. I found resources for it scant. Coming from more modern languages/tooling like Go/Rust, I also struggled quite a bit with installation and the build/package system. I tried the stack template generator for yesod/sqlite and after some 15 minutes of it in…

I learned using the Haskell Programming from First Principles book (haskellbook.com). I don't think it goes into web development, but it certainly goes through the basic project setup. Do you think you would have benefitted from a resource like the Rust book? I've been toying with the idea of writing something similar and donating it to the Haskell Foundation

I've seen this book referenced a few times and is quite large from what I've seen.

Not opposed to checking it out, but to your question: I really like the Rust book and how easy it is to find and read. It feels modern, up to date, and the standard for how to learn Rust.

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

#60

Post by nickzelei »

internet_points wrote: post #38
nickzelei wrote: post #16

Interesting read! On a semi-related topic: I tried learning Haskell this past weekend out of curiosity that I last tried it some 10+ years ago while still in college. I found resources for it scant. Coming from more modern languages/tooling like Go/Rust, I also struggled quite a bit with installation and the build/package system. I tried the stack template generator for yesod/sqlite and after some 15 minutes of it in…

https://typeclasses.com/phrasebook is a good resource

This is great! I like the note at the bottom of the page that it is inspired by Go/Rust by example.

After checking it out this is definitely on the way to what I"m looking for. Direct, no-nonsense examples that are easy to find and grok.

Post reply on HN