search

carp-lang / Carp

A statically typed lisp, without a GC, for real-time applications.
Apache License 2.0
5.47k stars 173 forks source link

[Bug] Not handling all cases during pattern-matching in lambdas #1436

Open AZMCode opened 1 year ago

AZMCode commented 1 year ago

As of now, using a non-exhaustive pattern in a lambda returns the following error message

carp: src/Qualify.hs:220:55-108: Non-exhaustive patterns in lambda

With zero indication of where the offending lambda is located in code, unlike other compile time error messages.

scolsen commented 1 year ago

This is reporting a case where we actually aren't handling all possible cases in the compiler. Do you have some example code that triggered this?

AZMCode commented 1 year ago

Sure, let me whip up some code to reproduce it. A moment.

AZMCode commented 1 year ago

Crashes the carp interpreter with version 0.5.5

(reduce &(fn [(Pair x y) elm] (Pair (+ x 1) y)) (Pair 0 0) &(Array.repeat 16 &(fn[] ())))

Not sure if it's possible to reduce this example even further

scolsen commented 1 year ago

Thanks a ton, @AZMCode! I'll take a look and see if I can get a fix in the next day or two.

AZMCode commented 1 year ago

Thank you for taking the time.

AZMCode commented 11 months ago

After a long time not using the language, I came back to it for funsies, stumbled upon this bug again, and decided to reduce the code further. Here's an updated example that triggers the exact same bug:

(def f (fn [ (Unit) ] ()))
AZMCode commented 11 months ago

I don't know if this code is valid at all, but it surely shouldn't crash the interpreter/compiler

scolsen commented 7 months ago

This short repo case is great to have, thank you @AZMCode! I am hoping to spend some more time on Carp again soon and can try to fix this.

(wound up getting busy with other things as usual, after pledging to work on this before, but it is still on my radar!)