[Caml-list] An awkwardness with type parameters

[Caml-list] An awkwardness with type parameters

[Hendrik Boom]

I have a (broken) function definition starting:

let mixfix : 'token1 'phrase1.
  ('token1, 'phrase1, ('token1, 'phrase1) Phrasestream.phrasestream) grammar
        -> ('token1, 'phrase1) parser
   =  fun gram -> (
  ...

It goes o for a hundred-odd lines.
The type-parameterized types Phrasestream.phrasestream, grammar, and parser   
have been previously defined, and there are also operations defined on these
types.

The problem I'm having is that the OCaml type-checker ends up identifying
the type parameters 'token1 an 'phrase1 because of type errors I've made in
the body of the mixfix function.  Somewhere I ended up using an
operator that's supposed to work on values of type 'token1
on a value of type 'phrase1 instead, and identification of 'token1 and 
'phrase1 is the natural result.

Is there some way of forcing the type checker to treat 'token1 and 
'phrase1 as different types so that I can get meaningful type errors
at the point were they occur?

With the present setup I only get type violation messages much later, 
when I try to use the mixfix function.  It's far too late to trace the 
problem back to the actual error by that time.

-- hendrik

Re: [Caml-list] An awkwardness with type parameters

[Jacques Garrigue]

2019/02/26 15:23, Hendrik Boom <hendrik@topoi.pooq.com>:
> 
> I have a (broken) function definition starting:
> 
> let mixfix : 'token1 'phrase1.
>  ('token1, 'phrase1, ('token1, 'phrase1) Phrasestream.phrasestream) grammar
>        -> ('token1, 'phrase1) parser
>   =  fun gram -> (
>  ...
> 
> It goes o for a hundred-odd lines.
> The type-parameterized types Phrasestream.phrasestream, grammar, and parser   
> have been previously defined, and there are also operations defined on these
> types.
> 
> The problem I'm having is that the OCaml type-checker ends up identifying
> the type parameters 'token1 an 'phrase1 because of type errors I've made in
> the body of the mixfix function.  Somewhere I ended up using an
> operator that's supposed to work on values of type 'token1
> on a value of type 'phrase1 instead, and identification of 'token1 and 
> 'phrase1 is the natural result.
> 
> Is there some way of forcing the type checker to treat 'token1 and 
> 'phrase1 as different types so that I can get meaningful type errors
> at the point were they occur?

You can use locally abstract types, which are often used with GADTs but are not
restricted to them:
  let mixfix : type token1 phrase1.
    (token1, phrase1, (token1, phrase1) Phrasestream.phrasestream) grammar
       -> (token1, phrase1) parser
  =  fun gram -> (
 …
This is the same as the type you wrote, but additionally prevents the types from being
instantiated inside the definition of mixdix.

Jacques Garrigue

Re: [Caml-list] An awkwardness with type parameters

[Hendrik Boom]

On Tue, Feb 26, 2019 at 03:39:24PM +0900, Jacques Garrigue wrote:
> 
> 2019/02/26 15:23, Hendrik Boom <hendrik@topoi.pooq.com>:
> > 
> > I have a (broken) function definition starting:
> > 
> > let mixfix : 'token1 'phrase1.
> >  ('token1, 'phrase1, ('token1, 'phrase1) Phrasestream.phrasestream) grammar
> >        -> ('token1, 'phrase1) parser
> >   =  fun gram -> (
> >  ...
> > 
> > It goes o for a hundred-odd lines.
> > The type-parameterized types Phrasestream.phrasestream, grammar, and parser   
> > have been previously defined, and there are also operations defined on these
> > types.
> > 
> > The problem I'm having is that the OCaml type-checker ends up identifying
> > the type parameters 'token1 an 'phrase1 because of type errors I've made in
> > the body of the mixfix function.  Somewhere I ended up using an
> > operator that's supposed to work on values of type 'token1
> > on a value of type 'phrase1 instead, and identification of 'token1 and 
> > 'phrase1 is the natural result.
> > 
> > Is there some way of forcing the type checker to treat 'token1 and 
> > 'phrase1 as different types so that I can get meaningful type errors
> > at the point were they occur?
> 
> You can use locally abstract types, which are often used with GADTs but are not
> restricted to them:
>   let mixfix : type token1 phrase1.
>     (token1, phrase1, (token1, phrase1) Phrasestream.phrasestream) grammar
>        -> (token1, phrase1) parser
>   =  fun gram -> (

Thus *with* the type keyword, but *without* the apostrophes on token1 
and phrase1?

-- hendrik

Re: [Caml-list] An awkwardness with type parameters

[Jacques Garrigue]

[-- Attachment #1: Type: text/plain, Size: 1868 bytes --]

On 2019/02/27 10:59, Hendrik Boom wrote:
> 
> On Tue, Feb 26, 2019 at 03:39:24PM +0900, Jacques Garrigue wrote:
>> 
>> 2019/02/26 15:23, Hendrik Boom <hendrik@topoi.pooq.com <mailto:hendrik@topoi.pooq.com>>:
>>> 
>>> I have a (broken) function definition starting:
>>> 
>>> let mixfix : 'token1 'phrase1.
>>> ('token1, 'phrase1, ('token1, 'phrase1) Phrasestream.phrasestream) grammar
>>>       -> ('token1, 'phrase1) parser
>>>  =  fun gram -> (
>>> ...
>>> 
>>> It goes o for a hundred-odd lines.
>>> The type-parameterized types Phrasestream.phrasestream, grammar, and parser   
>>> have been previously defined, and there are also operations defined on these
>>> types.
>>> 
>>> The problem I'm having is that the OCaml type-checker ends up identifying
>>> the type parameters 'token1 an 'phrase1 because of type errors I've made in
>>> the body of the mixfix function.  Somewhere I ended up using an
>>> operator that's supposed to work on values of type 'token1
>>> on a value of type 'phrase1 instead, and identification of 'token1 and 
>>> 'phrase1 is the natural result.
>>> 
>>> Is there some way of forcing the type checker to treat 'token1 and 
>>> 'phrase1 as different types so that I can get meaningful type errors
>>> at the point were they occur?
>> 
>> You can use locally abstract types, which are often used with GADTs but are not
>> restricted to them:
>>  let mixfix : type token1 phrase1.
>>    (token1, phrase1, (token1, phrase1) Phrasestream.phrasestream) grammar
>>       -> (token1, phrase1) parser
>>  =  fun gram -> (
> 
> Thus *with* the type keyword, but *without* the apostrophes on token1 
> and phrase1?

Exactly. This means that in the body of your function their are abstract types, and you cannot unify them. Aside of that the behavior is the same as what we had written first.

Jacques


[-- Attachment #2: Type: text/html, Size: 5924 bytes --]

Re: [Caml-list] An awkwardness with type parameters

[Hendrik Boom]

On Tue, Feb 26, 2019 at 03:39:24PM +0900, Jacques Garrigue wrote:
> 
> 2019/02/26 15:23, Hendrik Boom <hendrik@topoi.pooq.com>:
> > 
> > I have a (broken) function definition starting:
> > 
> > let mixfix : 'token1 'phrase1.
> >  ('token1, 'phrase1, ('token1, 'phrase1) Phrasestream.phrasestream) grammar
> >        -> ('token1, 'phrase1) parser
> >   =  fun gram -> (
> >  ...
> > 
> > It goes o for a hundred-odd lines.
> > The type-parameterized types Phrasestream.phrasestream, grammar, and parser   
> > have been previously defined, and there are also operations defined on these
> > types.
> > 
> > The problem I'm having is that the OCaml type-checker ends up identifying
> > the type parameters 'token1 an 'phrase1 because of type errors I've made in
> > the body of the mixfix function.  Somewhere I ended up using an
> > operator that's supposed to work on values of type 'token1
> > on a value of type 'phrase1 instead, and identification of 'token1 and 
> > 'phrase1 is the natural result.
> > 
> > Is there some way of forcing the type checker to treat 'token1 and 
> > 'phrase1 as different types so that I can get meaningful type errors
> > at the point were they occur?
> 
> You can use locally abstract types, which are often used with GADTs but are not
> restricted to them:
>   let mixfix : type token1 phrase1.
>     (token1, phrase1, (token1, phrase1) Phrasestream.phrasestream) grammar
>        -> (token1, phrase1) parser
>   =  fun gram -> (
>  …
> This is the same as the type you wrote, but additionally prevents the types from being
> instantiated inside the definition of mixdix.
> 
> Jacques Garrigue

Thank you.  I've already found the bug, but I made this change and it will
keep it from coming back.

-- hendrik