Assertion errors in PGF2 not catchable exceptions

[johnjcamilleri]

Take this minimum working example:

import PGF2
import Control.Exception
import qualified Data.Map as Map

main :: IO ()
main = do
  pgf <- readPGF "Feedback.pgf"
  let Just eng = Map.lookup "FeedbackEng" (languages pgf)
  onException (do
    let expr = mkApp (mkCId "BaseFeature") []
    let s = linearize eng expr
    putStrLn s
    ) (putStrLn "Caught exception")

where:

BaseFeature : Feature -> Feature -> ListFeature

So in my code I am building an invalid tree and expect to get an error. What currently happens is that my program crashes with the following:

pgf_cnc_resolve_app (pgf/linearizer.c:176): assertion failed
	n_args == gu_seq_length(papply->args)

Is there any way this can be thrown as a Haskell exception so that it can be handled appropriately?

[krangelov]

If you generate expressions dynamically and you want to be sure that they are correct, then the right way to go is to use the typechecker. If an incorrect tree is sent to the runtime then it can fail in many different ways. Some of them might be captured by assertions but not all of them.

…

On Fri, 21 Aug 2020 at 00:30, John J. Camilleri ***@***.***> wrote: Assigned #72 <#72> to @krangelov <https://github.com/krangelov>. — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub <#72 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEYFSZDRIIMQCBMHLXJJSZLSBWPWXANCNFSM4QGVCHVA> .

[johnjcamilleri]

Ah I see, fair enough. I guess this can be better documented, I'll add something to the Haskell docs for PGF2.

[anka-213]

Perhaps we should make a safer API that enforces that dynamically built expressions are type-checked before they can be used with linearize and similar functions?
E.g by adding a newtype that can only be built by type-checking or by unsafeAssumeTypeChecked.

[aarneranta]

Yes, it is important to check trees before linearizing them, as the GF Shell does. A couple of issues should be taken into account: - the type of PGF.linearize should not be changed, since we don't want to break people's old code - errors raised by type checking failures should come with clear error messages - sometimes checking is guaranteed even for dynamically built expressions, for example if they are generated from a Haskell datatype dump, which is a common practice in NLG systems

…

________________________________ From: Andreas Källberg ***@***.***> Sent: Sunday, May 2, 2021 7:33:57 AM To: GrammaticalFramework/gf-core Cc: Subscribed Subject: Re: [GrammaticalFramework/gf-core] Assertion errors in PGF2 not catchable exceptions (#72) Perhaps we should make a safer API that enforces that dynamically built expressions are type-checked before they can be used with linearize and similar functions? E.g by adding a newtype that can only be built by type-checking or by unsafeAssumeTypeChecked. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub<#72 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAWBQXKVC6MU2XBTWXVC2OLTLTP4LANCNFSM4QGVCHVA>.

[anka-213]

I guess the major question is how large the performance penalty of type-checking would be. If it is minimal, we could just always do type checking before linearizing and add an unsafe variant that doesn't type check first.