"ocaml_beginners"::[] How to access types within a module for matching

Hello,

I have the following module defined:

module Key_map = Map.Make (struct
type t = dt_key
let compare a b =
let a, sa, aa, ta = a in
let b, sb, ab, tb = b in
let r = Pervasives.compare a b in
if r <> 0 then r else
let r = Pervasives.compare sa sb in
if r <> 0 then r else
let r = Pervasives.compare aa ab in
if r <> 0 then r else
Pervasives.compare ta tb
end)

and want to use:

type enum =
| End
| More of dt_node * dt_node Key_map.t * enum

so:

let rec left (t:dt_node Key_map.t) e =
match t with
| Empty -> e
....

My problem is "Empty" is not of the correct type. I need to indicate
that I want a "dt_node Key_map.t&quot;.Empty.

How can I do this?

TIA,
Hugo F.

Messages in this topic (1) Reply (via web post) | Start a new topic

.

Hugo Ferreira wrote:
&gt; Hello,
&gt;
> I have the following module defined:
>
>; module Key_map = Map.Make (struct
> type t = dt_key
&gt; let compare a b =
> let a, sa, aa, ta = a in
> let b, sb, ab, tb = b in
> let r = Pervasives.compare a b in
> if r <> 0 then r else
>; let r = Pervasives.compare sa sb in
> if r <> 0 then r else
>; let r = Pervasives.compare aa ab in
> if r <> 0 then r else
>; Pervasives.compare ta tb
> end)
>;
> and want to use:
>;
> type enum =
> | End
> | More of dt_node * dt_node Key_map.t * enum
>;
> so:
>
> let rec left (t:dt_node Key_map.t) e =
> match t with
>; | Empty -> e
> ....
&gt;
> My problem is "Empty" is not of the correct type. I need to indicate
> that I want a "dt_node Key_map.t&quot;.Empty.
>
> How can I do this?
&gt;
> TIA,
>; Hugo F.
>
If Empty was defined by the Map functor you could just write Key_map.Empty.
But the 'a Key_map.t type is abstract (its structure is hidden) so there
is no way to match its values.
A solution is:
let rec left t e = if Key_map.is_empty t then e else ...

(There exists a *value* Key_map.empty as opposed to a *constructor*
Key_map.Empty, but testing emptiness by a "if t = Key_map.empty", while
probably OK in practice, is not absolutely guaranteed to be OK; in
general comparing maps with = is wrong.)

BTW, if I didn't misread things, your compare function is strictly
equivalent to Pervasives.compare so you could more shortly write

module Key_map = Map.Make (struct
type t = dt_key
let compare a b = compare
end)

Frédéric

Messages in this topic (0) Reply (via web post) | Start a new topic

.

Hello Frédéric,

Frédéric van der Plancke wrote:
&gt; Hugo Ferreira wrote:
&gt;> Hello,
&gt;>
snip..
>;>
>;> type enum =
>&gt; | End
>> | More of dt_node * dt_node Key_map.t * enum
>;>
>;> so:
>>
>> let rec left (t:dt_node Key_map.t) e =
>&gt; match t with
>;> | Empty -> e
>&gt; ....
&gt;>
snip
>&gt;
> If Empty was defined by the Map functor you could just write Key_map.Empty.
> But the 'a Key_map.t type is abstract (its structure is hidden) so there
> is no way to match its values.
> A solution is:
> let rec left t e = if Key_map.is_empty t then e else ...
>

Actually all I want to do is "extend" Map to implement iterators. To do
this I need access to the Map.Make(Ord).t. If it where not a functor,
all I would do is include the modules structure and define/implement the
necessary functions (as per the ocaml-tutorial example).

> (There exists a *value* Key_map.empty as opposed to a *constructor*
> Key_map.Empty, but testing emptiness by a "if t = Key_map.empty", while
> probably OK in practice, is not absolutely guaranteed to be OK; in
> general comparing maps with = is wrong.)
>

As I said, I want access to the Map's internals in order to extend it
(as apposed to reimplementing it). I only have the structure after
generating the module via Map.Make, but now the internals are hidden. So
including that, is of no use. 8-(

In short how do I extend a module functor?

> BTW, if I didn't misread things, your compare function is strictly
> equivalent to Pervasives.compare so you could more shortly write
&gt;
> module Key_map = Map.Make (struct
> type t = dt_key
&gt; let compare a b = compare
> end)
>;

Hmm... I was not aware of this. Initially I set this up to use a
"specialized" comparison on one of the elements of the tuple. Later I
realized that the standard Pervasives comparison worked fine.

I guess I should simplify as you indicate above.

Hugo F.

&gt; Frédéric
>
>
>
> Archives up to November 11, 2006 are also downloadable at http://www.connettivo.net/cntprojects/ocaml_beginners/
> The archives of the very official ocaml list (the seniors' one) can be found at http://caml.inria.fr
> Attachments are banned and you're asked to be polite, avoid flames etc.
> Yahoo! Groups Links
&gt;
>
>
>

Messages in this topic (0) Reply (via web post) | Start a new topic

.

On Wed, May 16, 2007 at 01:28:12PM +0100, Hugo Ferreira wrote:
&gt; As I said, I want access to the Map's internals in order to extend it
> (as apposed to reimplementing it). I only have the structure after
&gt; generating the module via Map.Make, but now the internals are hidden. So
> including that, is of no use. 8-(
>
> In short how do I extend a module functor?

I think the answer is that you make a copy of the source.

Rich.

--
Richard Jones
Red Hat

Messages in this topic (0) Reply (via web post) | Start a new topic

.

Rich,

Richard Jones wrote:
&gt; On Wed, May 16, 2007 at 01:28:12PM +0100, Hugo Ferreira wrote:
&gt;> As I said, I want access to the Map's internals in order to extend it
>&gt; (as apposed to reimplementing it). I only have the structure after
&gt;> generating the module via Map.Make, but now the internals are hidden. So
>&gt; including that, is of no use. 8-(
>>
>> In short how do I extend a module functor?
>
> I think the answer is that you make a copy of the source.
>

Thank you for the answer. I was hopping the code reuse in Ocaml would be
a little better than that. What a disappointment the module system has
been for me. 8-(

Wonder what approach F# has taken in this respect.

Regards,
H.F.

> Rich.
&gt;

Messages in this topic (0) Reply (via web post) | Start a new topic

.

On Wednesday 16 May 2007 17:05:10 Hugo Ferreira wrote:
&gt; Thank you for the answer. I was hopping the code reuse in Ocaml would be
> a little better than that. What a disappointment the module system has
> been for me. 8-(

I have often wanted a generic tree functor that could be specialized to
implement Set, Map and other containers (like a functional array).

> Wonder what approach F# has taken in this respect.

The same as OCaml except that it doesn't have functors.

--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
The F#.NET Journal
http://www.ffconsultancy.com/products/fsharp_journal/?e

Messages in this topic (0) Reply (via web post) | Start a new topic

.

On Wednesday 16 May 2007 17:17:31 Jon Harrop wrote:
&gt; On Wednesday 16 May 2007 17:05:10 Hugo Ferreira wrote:
&gt; > Thank you for the answer. I was hopping the code reuse in Ocaml would be
> > a little better than that. What a disappointment the module system has
> > been for me. 8-(
>
> I have often wanted a generic tree functor that could be specialized to
> implement Set, Map and other containers (like a functional array).

Incidentally, this is not a problem with the language but with the stdlib.
Both Set and Map are specifically designed to abstract away their internals,
so the fact that you cannot fiddle with their internals is due to the design
and not a problem with OCaml or with its module system.

We developed a stdlib extension for OCaml that provides all kinds of nice
features like this, coupled with significantly better performance. I can
commercialise it if you're interested?

--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
The F#.NET Journal
http://www.ffconsultancy.com/products/fsharp_journal/?e

Messages in this topic (0) Reply (via web post) | Start a new topic

.

On Wed, 16 May 2007, Hugo Ferreira wrote:

> Thank you for the answer. I was hopping the code reuse in Ocaml would be
> a little better than that. What a disappointment the module system has
> been for me. 8-(
>
> Wonder what approach F# has taken in this respect.

But the whole point of the modules/functors here is precisely to hide the
inner workings of the code and to abstract the types. Why would you
expect it to be any different? The standard library is not a repository
of code with the guts exposed to allow for extension by tweaking those
internals -- if you want that then you're going to have to go the cut and
paste route.

Perhaps they cou/d release a devlib or something with everything exposed
to you, but is there really a need for such a thing? Especially when the
code is available to you?

William D. Neumann

---

"There's just so many extra children, we could just feed the
children to these tigers. We don't need them, we're not doing
anything with them.

Tigers are noble and sleek; children are loud and messy.&quot;

-- Neko Case

Life is unfair. Kill yourself or get over it.
-- Black Box Recorder

Messages in this topic (0) Reply (via web post) | Start a new topic

.

On Thursday 17 May 2007 08:56:11 Hugo Ferreira wrote:
&gt; I wanted to avoid the copy & paste reuse technique (see my response to
> Jon on this). Anyway my question is this: say I want to develop a
> generic data structure of my own like Map so that:
&gt; 1. It still enforces an interface for the key (or any other number of
> elements it requires)
> 2. It be extensible i.e: make its guts available for those that need it
> (not that I am not talking about reimplementation or tweaking, juts
>; extending)

You need to quantify exactly what you mean by "guts". Then parameterise the
rest of the internals over the "guts" and pass the "guts" into the functor as
a module argument.

--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
The F#.NET Journal
http://www.ffconsultancy.com/products/fsharp_journal/?e

Messages in this topic (0) Reply (via web post) | Start a new topic

.

On Thursday 17 May 2007 08:36:17 Hugo Ferreira wrote:
&gt; You are correct of course. My initial problem is how can I extend the
> Map to include iterators.

Have you considered simply adding more powerful fold functions? Can you not
write what you need in terms of fold?

> Richard said "make a copy of the source&quot; but
> this seems unwise. What happens if a bug in the original code is
> detected and corrected, what happens if the implementation is changed
> without altering the types? Changes would go unnoticed and I would not
> be the wiser.

That is a problem with inextensible abstraction.

>; Jon, I will be direct and hope not be rude in answering this: if I had
> the resources I would rather use it on your book and not the library.
> After all I want to implement specific stuff that are not generally
> available elsewhere. (That being said, I hope your work on F# will
>; provide you a better customer base )

No worries. Our F# work has pulled in as much profit over the past month as
OCaml for Scientists but I think F# will really take off when Foundations of
F# is published by APress in the coming weeks.

--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
The F#.NET Journal
http://www.ffconsultancy.com/products/fsharp_journal/?e

Messages in this topic (0) Reply (via web post) | Start a new topic

.