caml-list - the Caml user's mailing list
 help / Atom feed
From: Jacques Garrigue <garrigue@math.nagoya-u.ac.jp>
To: Hendrik Boom <hendrik@topoi.pooq.com>
Cc: Mailing List OCaml <caml-list@inria.fr>
Subject: Re: [Caml-list] An awkwardness with type parameters
Date: Wed, 27 Feb 2019 12:46:20 +0900
Message-ID: <710C867E-725F-419E-9FFA-0C6AF7FCD763@math.nagoya-u.ac.jp> (raw)
In-Reply-To: <20190227015952.zvj7fef7fg3ivsnf@topoi.pooq.com>

[-- 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 --]

  reply index

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-26  6:24 Hendrik Boom
2019-02-26  6:39 ` Jacques Garrigue
2019-02-27  2:00   ` Hendrik Boom
2019-02-27  3:46     ` Jacques Garrigue [this message]
2019-02-27 18:21   ` Hendrik Boom

Reply instructions:

You may reply publically to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=710C867E-725F-419E-9FFA-0C6AF7FCD763@math.nagoya-u.ac.jp \
    --to=garrigue@math.nagoya-u.ac.jp \
    --cc=caml-list@inria.fr \
    --cc=hendrik@topoi.pooq.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

caml-list - the Caml user's mailing list

Archives are clonable: git clone --mirror https://inbox.ocaml.org/caml-list

AGPL code for this site: git clone https://public-inbox.org/ public-inbox