Are there multiplatform alternatives to classes li...

# multiplatform

[martmists]

Are there multiplatform alternatives to classes like Optional and StackOverflowError?

[Joffrey]

Optional in Kotlin can just be a nullable type, that's multiplatform and you benefit from a bunch of syntax features that are nicer than `Optional`'s own utilities.

Regarding StackOverflowError, what are you trying to do with this class in the first place?

[mbonnin]

Unfortunately, there are cases were the distinction between null and undefined could be useful. We ended up defining our own Optional but having a standard way to do it would be nice

[mbonnin]

In swift you can do "double" optional IIRC which kindof solves the issue (albeit is looking kind of weird...)

[martmists]

Nullability sadly causes some other problems in the code, and the StackOverflowError is necessary to not crash when left-recursion parsing goes too deep

[Joffrey]

Do you have examples of problems caused by nullability? I think I'm missing your point

[Joffrey]

If recursion goes too deep to the point of throwing this, why would the solution be to catch the error, though? Shouldn't you fix the recursion issue instead?

[martmists]

The issue is that "infinite" recursion is necessary for implementing a left-recursive packrat parser. I don't do any left-memoization by default, so if it ends up recursing to deep I throw a different error, stating memoLeft needs to be used and in which rule it's necessary

[martmists]

The only other option I have is to fully analyze the code with a KSP/IR plugin and generate an entire call graph and modify the IR to place memoization by default but that doesn't sound like a great solution to me personally.

[Joffrey]

I probably don't fully understand your use case / domain at hand. It seems that part of the responsibility of throwing would be in user code, not picking the correct library function from your code, and you want nicer error handling. But I'm missing why you can't solve the problem my removing the potentially infinite recursion and go for an iterative parser

[martmists]

Often when creating a parser you'll have expressions like expr := expr '+' term | term and while this could be expanded to term ('+' term)* this can become increasingly big with more complex grammars, and there's a good reason to want to implement it recursively as also outlined in this medium post by Guido van Rossum: https://medium.com/@gvanrossum_83706/left-recursive-peg-grammars-65dab3c580e1

[Joffrey]

Thanks. Ok, I think I understood your previous sentence now:

if it ends up recursing to deep I throw a different error, stating memoLeft needs to be used and in which rule it's necessary

I thought memoLeft was a function name, leading to a different implementation of your algo. So I thought your consumers/users were writing code. If I understand correctly now, your users write grammars, and your code is the parser. And memoLeft is some sort of option that users can choose to use for some rules in the grammar, is this correct?

[martmists]

It's a bit of a mix of the two; users write grammars in kotlin code, but rules need to be wrapped in memoLeft if they have left-recursion, otherwise it will cause a StackOverflowError (or similar on other targets), in which case I want to notify the user to use memoLeft to avoid that problem.

[martmists]

For example, the grammar commaList := (commaList | term) ',' term would be written as

private val commaList by sequence(memoLeft {  // memoLeft needed due to left-recursion
        val l = first(
            ::commaList,
            ::term
        )
        char(',')
        val r = term()
        "$l,$r"  // String for now, could be replaced with AST/IR elements
    })

[martmists]

But if the user forgets to use memoLeft, it causes a StackOverflowError, which I catch to alert them that they should probably use it, in this case in rule commaList

[Joffrey]

Shouldn't you just impose a recursion limit like 20-30 levels and fail before the stackoverflow? What if the user runs the program in a high memory environment and it runs fine, and then the same thing runs with lower memory and fails?

[martmists]

putting in arbitrary limits isn't useful to end users, especially if 1 + 1 + 1 + 1 ... repeating 50 times isn't any less valid.