Version française
Home     About     Download     Resources     Contact us    
Browse thread
modules local to functions.
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Andrew Conway <arc@l...>
Subject: Re: modules local to functions.


I wrote:

> > However, there are cases when I want to define a module in the middle
> > of a function (eg a functor of packed binary arrays where I want to (...)

Christian Boos commented:

>I have encountered a similar problem yesterday! 
>My understanding is that YOU CAN'T do that in CSL at all: functor
>application means code generation, and there's no runtime code
>generation!

Ah. I expected (though I hadn't looked into the code at all) that
a run time structure creation (eg struct let n = variable end) was
very similar to the creation of a tuple/normal structure, just requiring
sticking some values into a block of memory. I then expected that a 
module creation from a functor was very similar to a partial function
application, (with perhaps a bit of execution) and could thus be done 
at run time (as distinct from, say C++ templates which produce specialised 
code for each application).

But it may well be significantly more complex than that.

> One can get around the problem by defining n as a function or reference
> and changing it dynamically.

Ugh! I hadn't thought of that, and it is a good idea even if just
a little inelegant. Unfortunately it is not appropriate in my case as
I have several values in the structure which get defined when the module
is created and which depend on n...ie:


    module Makespecific(N:Specifyn) = struct
       type mytype = int
       let computednumber = complexfunction N.n 
       let mirror () : mytype = computednumber
    end

and I only want to call complexfunction once for each module instantiation.

Of course, I could make "computednumber" a reference, and I could have
a function "change_n_and_recompute_everything", but again it is an inelegant
solution that is hard to understand, and I end up with "!"s all over the
code for no algorithmically justifyable reason.

Yeah yeah, I know I am being picky...

Thanks,

Andrew.