|
|
 Up |
|
|
  |
Author: michele.simionatomichele.simionato Date: Nov 15, 2007 22:27
I am trying to understand how functor works, so I did some
experiments.
I defined an abstract signature for sequences with an ".app" function
signature SEQUENCE_WITH_APP =
sig
type 'a t
val app: ('a -> unit) -> 'a t -> unit
end
and a functor
functor F(S:SEQUENCE_WITH_APP) = struct
val app = S.app
end
then I wrote the following interactive program:
val input = let
val stdin = TextIO.stdIn
in fn () => case TextIO.inputLine stdin of (SOME line) => line |
NONE => ""
end
|
| Show full article (1.68Kb) |
|
| | 16 Comments |
|
|
Author: Vesa KarvonenVesa Karvonen Date: Nov 15, 2007 23:35
michele.simionato@ gmail.com gmail.com> wrote:> I am trying to understand how functor works, so I did some
> experiments. I defined an abstract signature for sequences with an
> ".app" function
> signature SEQUENCE_WITH_APP =
> sig
> type 'a t
> val app: ('a -> unit) -> 'a t -> unit
> end
If you don't mind, I'll make a few remarks on style. This isn't
important at all, but I would recommend putting that "sig" keyword on
the same line with the "signature" keyword, to save vertical space.
That would be analogous to what you are already doing with the
"struct" keyword below:
> and a functor
> functor F(S:SEQUENCE_WITH_APP) = struct
> val app = S.app
> end
> then I wrote the following interactive program:
|
| Show full article (4.42Kb) |
|
| | no comments |
|
|
Author: michele.simionatomichele.simionato Date: Nov 16, 2007 00:08
On Nov 16, 8:35 am, Vesa Karvonen
wrote:
> If you don't mind, I'll make a few remarks on style.
Please do, this is one of the reasons why I am posting snippets.
> Standard ML does not allow functors to be instantiated in core
> language expressions.
Why not?
> Also, if you look at the functor
> instantiations, the functor and the argument to the functor are known
> statically. A smart compiler could further prove that the functor F
> does not have observable run-time effects. So, a smart compiler
> could, in fact, lift those functor instantiations out of the loop.
But how do I know if my compiler was smart enough? I mean, I may not
have
the manual at my disposal, or I may not believe the manual. I am
asking
for a way to check if the compiler did or did not optimize a given
functor
instantiation.
|
| Show full article (0.87Kb) |
| no comments |
|
|
Author: Vesa KarvonenVesa Karvonen Date: Nov 16, 2007 01:55
michele.simionato@ gmail.com gmail.com> wrote:> On Nov 16, 8:35 am, Vesa Karvonen
> wrote:
[...]
>> Standard ML does not allow functors to be instantiated in core
>> language expressions.
> Why not?
In Standard ML, the module and core languages are intentionally
stratified (layered) in the sense that modules are on top of core
language constructs and module language constructs may not be
manipulated as ordinary values of the core language. This simplifies
the language considerably, avoiding difficulties with statically
typing first-class modules. Since the definition of Standard ML, many
alternative designs have been proposed for allowing first-class
modules. Alice ML provides one such design.
>> [...] So, a smart compiler could, in fact, lift those functor
>> instantiations out of the loop.
|
| Show full article (2.14Kb) |
| no comments |
|
|
Author: Vesa KarvonenVesa Karvonen Date: Nov 16, 2007 02:10
Vesa Karvonen wrote:
[...]
> Working with MLton, I've used such facilities occasionally. Not so
> long ago, I developed a simple non-recursive hash function for strings
> and enabled a couple of very simple constant folding transforms for
> vector expressions in MLton (in SML, strings are character vectors).
> The idea was to make it so that MLton could, effectively, hash
> constant strings at compile time. It worked. I wrote a simple test
> program, compiled it with MLton, and inspected the generated code.
> The generated assembly language code contained the final hash value as
> an immediate value in an instruction.
|
| |
| no comments |
|
|
Author: rossbergrossberg Date: Nov 16, 2007 06:56
On Nov 16, 8:35 am, Vesa Karvonen
wrote:
> michele.simion...@ gmail.com gmail.com> wrote:
Mh, strange, for some reason, Michele's original message does not seem
to show up on Google Groups. So I'm not sure I see all of his
question's via Vesa's quotes.
> I would recommend putting that "sig" keyword on
> the same line with the "signature" keyword, to save vertical space.
Just to add some perspective: I wouldn't, but that is a matter of
personal taste. ;-)
>> I guess the compiler could have resolved the functors at compilation
>> time. Is that correct?
In general, a functor is just a fancy form of function - that is how
their semantics is specified, and that should be how your mental model
treats them.
Some compilers optimise functors statically in a special manner, but
that does not generally apply because it relies on certain compilation
models or a commitment to the bare SML notion of first-order functor.
In any case, it does not affect the meaning of the program.
|
| Show full article (2.23Kb) |
| no comments |
|
|
Author: Vesa KarvonenVesa Karvonen Date: Nov 16, 2007 07:11
rossberg@ps.uni-sb.de wrote:
[..]
> Some compilers optimise functors statically in a special manner, but
> that does not generally apply because it relies on certain
> compilation models or a commitment to the bare SML notion of
> first-order functor.
I think that what makes optimization more difficult is having
first-class modules rather than just higher-order functors. The
module language of SML could be extended to provide higher-order
functors without fundamentally changing the stratified relationship
between the module and core languages.
-Vesa Karvonen
|
| |
| no comments |
|
|
Author: rossbergrossberg Date: Nov 16, 2007 07:27
On Nov 16, 4:11 pm, Vesa Karvonen
wrote:
> rossb...@ps.uni-sb.de wrote:
>
> [..]
>
>> Some compilers optimise functors statically in a special manner, but
>> that does not generally apply because it relies on certain
>> compilation models or a commitment to the bare SML notion of
>> first-order functor.
>
> I think that what makes optimization more difficult is having
> first-class modules rather than just higher-order functors. The
> module language of SML could be extended to provide higher-order
> functors without fundamentally changing the stratified relationship
> between the module and core languages.
|
| Show full article (0.99Kb) |
| no comments |
|
|
Author: michele.simionatomichele.simionato Date: Nov 16, 2007 07:37
On Nov 16, 3:56 pm, rossb...@ps.uni-sb.de wrote:
> Mh, strange, for some reason, Michele's original message does not seem
> to show up on Google Groups. So I'm not sure I see all of his
> question's via Vesa's quotes.
Dunno, I am posting via Google Groups. Anyway, it seems Vesa quoted
all
of my questions. But don't worry, I have another one. Looking at
examples of SML
programs I found the following one for Alice ML:
http://www.angelfire.com/tx4/cus/shapes/alice.html
I understand what the program does, but it looks like a typical OOP
program. You could write the same in any OOP language, it is a program
heavily based on mutation and internal state. I thought this
paradigmn
was discouraged in the functional community, and I wonder how one
would
rewrite that program in a functional way. Any takers? ;)
Michele Simionato
|
| |
| no comments |
|
|
|
|
|
Author: Torben Ægidius MogensenTorben Ægidius Mogensen Date: Nov 16, 2007 07:44
Vesa Karvonen writes:
> rossberg@ps.uni-sb.de wrote:
> [..]
>> Some compilers optimise functors statically in a special manner, but
>> that does not generally apply because it relies on certain
>> compilation models or a commitment to the bare SML notion of
>> first-order functor.
>
> I think that what makes optimization more difficult is having
> first-class modules rather than just higher-order functors. The
> module language of SML could be extended to provide higher-order
> functors without fundamentally changing the stratified relationship
> between the module and core languages.
|
| |
| no comments |
|
|
|
|
