Syntax ideas for non-uniform memory (near/far etc)

Syntax ideas for non-uniform memory (near/far etc)

[Kuba Ober]

I'm trying to adapt Ocaml syntax to embedded uses. There, memory is often
non-uniform and variables can live in different areas, say near/far/rom.

I was wondering what would be the "cleanest" syntax for that. I presume that
adding near/far/rom as keywords and using them similarly to "rec" would work,
e.g.

let print rom s = ... (* prints a string with a rom address *)

The truth is that "rom/near/far" is really part of the type, as if a function 
has a parameter living say in rom
then it won't take one in ram. So maybe one could have

let print (s : rom) = ....
of type string -> unit

For those unfamiliar with embedded work, think 16-bit x86 with near/far 
pointers and whatnot.

I'm all ears for other ideas as to how it might be implemented. Any syntactic 
sugar to make it cleaner looking?

I presume that an extension of this idea is to have multi-faceted types, where 
each type is really a tuple of "types", such that some could be polymorphic 
and some not.

Say one wants to have a function which will work on data put anywhere:

let print (s : 'c, string) = ....

where 'c is the "storage class", here polymorphic, and string is the good old 
type.

Of course none of this would use *the* OCaml compiler, I'm trying to write (or 
port, rather) my own.

Kuba

Re: [Caml-list] Syntax ideas for non-uniform memory (near/far etc)

[Richard Jones]

On Sat, Jan 05, 2008 at 02:41:00PM -0500, Kuba Ober wrote:
> I'm trying to adapt Ocaml syntax to embedded uses. There, memory is often
> non-uniform and variables can live in different areas, say near/far/rom.
> 
> I was wondering what would be the "cleanest" syntax for that. I presume that
> adding near/far/rom as keywords and using them similarly to "rec" would work,
> e.g.
> 
> let print rom s = ... (* prints a string with a rom address *)
>
> The truth is that "rom/near/far" is really part of the type, as if a
> function has a parameter living say in rom then it won't take one in
> ram. So maybe one could have
[...]

It sounds a bit like you need a phantom type.  Have a look around 1/3
of the way down this message, where Brian Rogoff implements the
"classic" read-only/read-write/write-only phantom types:

http://caml.inria.fr/pub/ml-archives/caml-list/2001/09/081c77179ee2a3787233902a51633122.en.html

Phantom types only ensure that (eg.) you can't write to a ROM
location, or you can only use certain functions on a near pointer.
They don't actually generate any extra code or overhead (which is, in
a way, a good thing about them).

Rich.

-- 
Richard Jones
Red Hat