"ocaml_beginners"::[] module rec

Shalom.

Maybe my task will force me to use recursive modules
instead of currently used non-recursive ones.

Will there be any runtime penalty when calling
functions or getting some data that belongs to recursive
modules?

Another way is to use parametrized type, something like:

type my_struct_gen 's =
{ ...
; current_state : mutable 's
}
;
...
module State
:
sig
type t = 'a;
end
=
struct
type t = { ... some references to my_struct_gen ... }
end
...
type my_struct = my_struct_gen State.t;

Will it be better in performance than recursive modules?

And yet another way is to declare types together:

type my_struct =
{ ...
; current_state : mutable state_t
}
and state_t =
{ ... some references to my_struct ... }
}
;

Everything looks good, but I want to create and modify
values of type state_t only inside one small module.
Can this be done using something like "private"?
(type state_t is represented by record).

--
WBR,
dmitry mailto: gds-mlsts%40moldavcable.com">gds-mlstsmoldavcable.com

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

.

Shalom, code17.

c> Have no idea about your efficiency problem, but recursive module
c> seems like a heavy-weight solution for me. I will only take this
c> approach if there is some reason making it considerably elegant
c> than other solutions.

Can you describe your situation, where recursive modules was
heavy-weight for you?

>> type my_struct =
>> { ...
>> ; current_state : mutable state_t
>> }
>> and state_t =
>> { ... some references to my_struct ... }
>> }
>> ;
>>
>> Everything looks good, but I want to create and modify
>> values of type state_t only inside one small module.
>> Can this be done using something like "private"?
>> (type state_t is represented by record).

c> Yes, this is exactly the private type. Prefix the "private" keyword
c> to the definition of state_t in the signature will do it.

I have a more complex structure, so I can't declare type my_struct
inside module State (which should be the only module that able to
create/modify state_t). Something like this:

type my_struct = ...;
module SomeBigModule1 = ... it uses my_struct ...;
module SomeBigModule2 = ... it uses my_struct and SomeBigModule1;
module State = ... here I want to declare private type state_t.
... this module uses my_struct, SomeBigModule1
... and SomeBigModule2;
module SomeBigModule3 = ... uses my_struct, SomeBigModule1,
... SomeBigModule2 and module State;

If I declare private type state_t together with type my_struct,
I won't be able to create/modify values of this type inside
module State. And I can't move module State before BigModules1
and 2 because module State uses them.

So, I see these solutions:
1. create module MyStruct for type my_struct and declare modules
MyStruct, SomeBigModule1, SomeBigModule2 and State as recursive
modules.
2. use parametrized type (my_struct_gen 's) and specify
type of state after module State:
"type my_struct = my_struct_gen State.t".
3. declare types together, but state_t won't be private.

I don't know the cost of solution #1. I approximately know
the cost of solution #2 (operations on field
"my_struct.current_state"; will be generic, since the exact
type of this field is unknown to functions that work with
"my_struct_gen 's"; not a very big penalty really).
So, if recursive modules have the same performance as usual
modules (my original question was exactly about it), I will
use solution #1, otherwise I will use #2.

--
WBR,
dmitry mailto: gds-mlsts%40moldavcable.com">gds-mlstsmoldavcable.com

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

.

Shalom, code17.

c> I roughly understand your situation, but I don't
c> understand the design, especially the reason why you want
c> the state_t type private (or opaque) to all other inside
c> modules. If all these modules are programmed by you, why
c>; do you care whether they can operate over state_t type
c> directly?

I want the compiler to check my code, because it really
guarantees that state_t can be created/modified only in one
small module. This module can be fully and quickly checked
without reviewing other parts of my code.

I don't need the cool feature "private type", I could be
satisfied by opaque state_t, but I can't declare it as
opaque type because of the structure of my code, described
in previous letter (functions that work with state_t
requires some functions that work with my_struct).

--
WBR,
dmitry mailto: gds-mlsts%40moldavcable.com">gds-mlstsmoldavcable.com

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

.