caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: "Jocelyn Sérot" <Jocelyn.SEROT@ubpmes.univ-bpclermont.fr>
To: OCaML Mailing List <caml-list@inria.fr>
Subject: Re: [Caml-list] Dependent types ?
Date: Tue, 27 Sep 2011 10:27:29 +0200	[thread overview]
Message-ID: <AF612ADF-D90A-4AF4-B5B8-92899DB965FD@lasmea.univ-bpclermont.fr> (raw)
In-Reply-To: <CADKNfhLMqAstEUJyik4DZ9QEBdb-4D-=9HnDgy3dF0WbfrnnXg@mail.gmail.com>

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


Le 26 sept. 11 à 14:45, Yaron Minsky a écrit :

> As written, the behavior of the types might not be what you expect,  
> since addition of two 16 bit ints may result in an int that requires  
> 17 bits.
>

In the current situation, this will be handled at the VHDL level.
Making it explicit at CAPH (the source level DSL) would be great but  
i'm afraid it is too complex to implement for the moment.
> When using phantom types, you need to be especially careful that the  
> types mean what you think they mean.
>
> On Sep 26, 2011 8:13 AM, "Denis Berthod" <denis.berthod@gmail.com>  
> wrote:
> > Hello,
> >
> > I think that achieving something very near from what you whant is
> > relatively easy using phantom types.
> > That avoid the boxing/unboxing in records.
> >
> > type i16
> > type i32
> >
> > module SizedInt:
> > sig
> > type 'a integer
> > val int16: int -> i16 integer
> > val int32: int -> i32 integer
> > val add: 'a integer -> 'a integer -> 'a integer
> > end
> > =
> > struct
> > type 'a integer = int
> >
> > let int16 x = x
> > let int32 x = x
> >
> > let add x y = x + y
> > end
> >
> > then
> >
> > open SizedInt
> >
> > let bar =
> > let x = int16 42 in
> > foo x
> >
> > must have type i16 integer -> i16 integer
> >
> > Regards,
> >
> > Denis Berthod
> >
> >
> > Le 26/09/2011 13:42, Jocelyn Sérot a écrit :
> >> Hello,
> >>
> >> I've recently come across a problem while writing a domain specific
> >> language for hardware synthesis
> >> (http://wwwlasmea.univ-bpclermont.fr/Personnel/Jocelyn.Serot/caph.html 
> ).
> >> The idea is to extend the type system to accept "size"  
> annotations for
> >> int types (it could equally apply to floats).
> >> The target language (VHDL in this case) accept "generic" functions,
> >> operating on ints with variable bit width and I'd like to reflect  
> this
> >> in the source language.
> >>
> >> For instance, I'd like to be able to declare :
> >>
> >> val foo : int * int -> int
> >>
> >> (where the type int is not annotated, i.e. "generic")
> >>
> >> so that, when applied to, let say :
> >>
> >> val x : int<16>
> >> val y : int<16>
> >>
> >> (where <16> is a size annotation),
> >>
> >> like in
> >>
> >> let z = foo (x,y)
> >>
> >> then the compiler will infer type int<16> for z
> >>
> >> In fact, the exact type signature for foo would be :
> >>
> >> val foo : int<s> * int <s> -> int<s>
> >>
> >> where "s" would be a "size variable" (playing a role similar to a  
> type
> >> variable in, for ex : val map : 'a list -> ('a ->'b) -> 'b list).
> >>
> >> In a sense, it has to do with the theory of sized types (Hughes and
> >> Paretto, .. ) and dependent types (DML for ex), but my goal is far
> >> less ambitious.
> >> In particular, i dont want to do _computations_ (1) on the size  
> (and,
> >> a fortiori, don't want to prove anything on the programs).
> >> So sized types / dependent types seems a big machinery for a
> >> relatively small goal.
> >> My intuition is that this is just a variant of polymorphism in  
> which
> >> the variables ranged over are not types but integers.
> >> Before testing this intuition by trying to implement it, I'd like  
> to
> >> know s/o has already tackled this problem.
> >> Any pointer - including "well, this is trivial" ! ;-) - will be
> >> appreciated.
> >>
> >> Best wishes
> >>
> >> Jocelyn
> >>
> >> (1) i.e. i dont bother supporting declarations like : val mul :  
> int<n>
> >> * int<n> -> int <2*n> ...
> >>
> >>
> >>
> >
> >
> > --
> > Caml-list mailing list. Subscription management and archives:
> > https://sympa-roc.inria.fr/wws/info/caml-list
> > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> > Bug reports: http://caml.inria.fr/bin/caml-bugs
> >


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

  parent reply	other threads:[~2011-09-27  8:27 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-26 11:42 Jocelyn Sérot
2011-09-26 12:07 ` Thomas Braibant
2011-09-26 12:13 ` Denis Berthod
2011-09-26 12:45   ` Yaron Minsky
2011-09-26 12:56     ` Denis Berthod
2011-09-26 15:55     ` Jocelyn Sérot
2011-09-26 16:44       ` Gabriel Scherer
2011-09-26 21:09         ` Christophe Raffalli
2011-09-27  8:34           ` Jocelyn Sérot
2011-09-27  8:23         ` Jocelyn Sérot
2011-09-27  9:16           ` Gabriel Scherer
2011-09-27  9:41             ` Arnaud Spiwack
2011-09-27 12:25               ` Jocelyn Sérot
2011-09-27 14:13           ` oliver
2011-09-27  8:27     ` Jocelyn Sérot [this message]
2011-09-26 22:51 ` oliver
2011-09-27 22:12 Damien Guichard
2011-09-28  7:27 ` Denis Berthod

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=AF612ADF-D90A-4AF4-B5B8-92899DB965FD@lasmea.univ-bpclermont.fr \
    --to=jocelyn.serot@ubpmes.univ-bpclermont.fr \
    --cc=caml-list@inria.fr \
    /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).