caml-list - the Caml user's mailing list
 help / color / mirror / 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	[thread overview]
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	other threads:[~2019-02-27  3:46 UTC|newest]

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

Reply instructions:

You may reply publicly 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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).