https://kotlinlang.org logo
#multiplatform
Title
# multiplatform
m

martmists

05/31/2022, 2:59 PM
Are there multiplatform alternatives to classes like Optional and StackOverflowError?
j

Joffrey

06/01/2022, 7:29 PM
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?
m

mbonnin

06/01/2022, 7:31 PM
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
In swift you can do "double" optional IIRC which kindof solves the issue (albeit is looking kind of weird...)
m

martmists

06/02/2022, 7:55 PM
Nullability sadly causes some other problems in the code, and the StackOverflowError is necessary to not crash when left-recursion parsing goes too deep
j

Joffrey

06/02/2022, 7:56 PM
Do you have examples of problems caused by nullability? I think I'm missing your point
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?
1
m

martmists

06/02/2022, 8:00 PM
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
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.
j

Joffrey

06/02/2022, 8:06 PM
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
m

martmists

06/02/2022, 8:26 PM
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
j

Joffrey

06/02/2022, 8:36 PM
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?
m

martmists

06/02/2022, 8:58 PM
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.
For example, the grammar
commaList := (commaList | term) ',' term
would be written as
Copy code
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
    })
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
j

Joffrey

06/03/2022, 7:42 AM
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?
m

martmists

06/03/2022, 10:58 AM
putting in arbitrary limits isn't useful to end users, especially if
1 + 1 + 1 + 1 ...
repeating 50 times isn't any less valid.
2 Views