Fatal error: beta: '' when printing after casting

[Matteo Manighetti]

I wrote some code meant to build clauses (in type prop) from terms of other types. Everything seems to work, but a fatal error occurs when printing, either using print or even when the solution is displayed.

A minimal example (note that I am using string here for appl, since I couldn't reproduce the behavior just by using tm. My actual use case is with an API-defined ctype)

kind tm type.

type all (tm -> tm) -> tm.
type imp tm -> tm -> tm.
type appl string -> list tm -> tm.
type q tm.

pred compile i:tm, i:list prop, o:prop.
compile (all T) L (pi x\ C x) :-
  pi x\ compile (T x) L (C x).

compile (imp T1 T2) L C :-
  std.unsafe-cast T1 TT,
  compile T2 [TT|L] C.

compile (appl H Args) L ((HH Args) :- L) :-
  std.unsafe-cast H HH.

$ elpi test.elpi 
goal> compile (all x\ all y\ (imp q (appl "p" [y,x]))) [] C.

Parsing time: 9.901

Compilation time: 0.002

Typechecking time: 0.044

Success:
Fatal error: beta: ''
  C = pi c0 \ pi c1 \

[Matteo Manighetti]

Actually a smaller example is sufficient. The problem is there when there is a term of a builtin type (or API cdata) applied to something.

kind a type.
type p a.
type foo int -> a.

pred test i:a, o:a.
test (foo S) (S' p) :-
  std.unsafe-cast S S'.
  
main X :- test (foo 1) X.

$ elpi test.elpi
goal> main X.

Parsing time: 3.693

Compilation time: 0.002

Typechecking time: 0.043

Success:
Fatal error: beta: ''
  X = 

[Enrico Tassi]

Well, the term you build is X = 1 p which is illtyped. I think I can improve the error message, but is comes from S' p where S' is not a function, but rather a number, and elpi fires a beta reduction...

[Enrico Tassi]

I mean, the problem is not in printing, it is that in elpi the head of an application cannot be a number or a string, but only a constant or a unif variable.

[Matteo Manighetti]

I see, indeed if that is the case it could be detected earlier. In my use case, I wanted to reuse constants (of some cdata type) as the head of applications, but that raised this same error. I guess this is because cdata is more similar to int/string than to actual constants?

[Enrico Tassi]

Cdata is the type/constructor of opaque data, int string real ...

[Matteo Manighetti]

Ok, I think what I was not getting right is that OpaqueData declared through the API is also cdata, and thus can never be applied to something.