Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Misleading error when using lincat as parameter #35

Open
daherb opened this issue Feb 12, 2019 · 5 comments
Open

Misleading error when using lincat as parameter #35

daherb opened this issue Feb 12, 2019 · 5 comments
Labels
bug Something isn't working

Comments

@daherb
Copy link
Member

daherb commented Feb 12, 2019

When loading the following Grammar

abstract TestAbs = {
  cat
    Temp ; Pol ; Cl ; S ; 
  fun
    UseCl  : Temp -> Pol -> Cl -> S ;
}
  param Order   = Ord | Subord | Quest;
  lincat
    Cl = {s : Temp => Bool => Order => Str};
    S = {s : Order => Str};
    Pol = {s : Str ; b : Bool};
    Temp = { t : Bool * Bool } ;
  lin
    UseCl temp pol cl = { --Temp -> Pol -> Cl -> S ;  
      s = \\o => case o of {
	Ord => cl.s ! lin Temp temp ! pol.b ! Ord;
	_ => "Baz" 
	};
      };
}

this error occurs
compiling Test.gf... src/compiler/GF/Compile/GeneratePMCFG.hs:(430,42)-(431,76): Non-exhaustive patterns in case

@Thomas-H
Copy link
Contributor

The example can be reduced a little bit more:

abstract TestAbs = {
  cat
    Temp ; Cl ; S ; 
  fun
    UseCl  : Temp -> Cl -> S ;
}

concrete Test of TestAbs = {
  param Pol = Pos;
  lincat
    Cl = {s : Temp => Str};
    S = {s : Str};
    Temp = { t : Pol } ;
  lin
    UseCl temp cl = { s = cl.s ! lin Temp temp; };
}

The root of the problem seems to be the use of the lincat Temp as an index in a table, Temp => Str }. Show this even be allowed?

It's the lock fields that are added to lincats that cause problem when you use lincats in this way. They cause problems in GeneratePMCFG in two ways actually:

  • There is an assumption that the record fields are in sorted order, but it appears that the lock fields break that assumption, in this example creating a mismatch between {t=…,lock_Temp=…} and {lock_Temp=…,t=…} and causing a lookup to fail.
  • If you write just temp instead of lin Temp temp there will be a mismatch between {t=…} and {lock_Temp=…,t=…}, again causing a lookup to fail (and you also get a warning about the missing lock field lock_Temp at an earlier stage).

As a quick fix, maybe it's enough to add some code in GeneratePMCFG to discard the lock fields before doing the lookup that currently fails, but perhaps there is a better place to fix this… @krangelov ?

@inariksit
Copy link
Member

I stumbled upon a similar bug a while ago, but figured that it's such a marginal use case to use lincats in weird ways that I didn't bother to report :-P For curiosity, here it is (sorry it's not even a self-contained example, it was from NounAra.gf):

-- Relevant definitions
Agr = NounPer3 {g:Gender ; n:Number} | Pron PerGenNum ; 
PN = {s : Case => Str; g : Gender; n : Number} ;
NP = {s : Case => Str ; a = Agr} ;

-- Bug appears here
UsePN pn = {
    s = pn.s;
    a = NounPer3 pn -- this causes internal error in GeneratePMCFG
--    a = NounPer3 {g=pn.g ; n=pn.n} -- this works
    } ;

@Thomas-H
Copy link
Contributor

Hmm, maybe it is not only lock fields that can cause problems, maybe record subtyping in general can cause problems, in this case a mismatch between records {s,g,n} and {g,n}. Maybe a more elaborate fix is needed…

@krangelov
Copy link
Member

krangelov commented Feb 13, 2019 via email

@heatherleaf
Copy link
Member

Aren't you discussing two different problems here? In Krasimir's example the problem is record subtyping ({s,g,n} vs {g,n}). But in Herbert's and Thomas' examples, the problem is using an abstract category as a linearisation type.

Here's a version of Thomas' example that compiles:

concrete Test of TestAbs = {
param Pol = Pos;
lincat
  Cl = {s : {t : Pol} => Str}; -- writing Temp instead of {t:Pol} throws "Non-exhaustive patterns in case"
  S = {s : Str};
  Temp = {t : Pol};
lin
  UseCl temp cl = {s = cl.s ! temp};
}

(Perhaps both are symptoms of the same bug of course)

@heatherleaf heatherleaf added the bug Something isn't working label Mar 8, 2019
@inariksit inariksit changed the title Bug in GF compiler Misleading error when using lincat as parameter Oct 23, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

5 participants