Browse thread
[Caml-list] ocaml killer
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
| Date: | -- (:) |
| From: | William Lovas <wlovas@s...> |
| Subject: | Re: fancy types (was Re: [Caml-list] ocaml killer) |
On Fri, Jan 30, 2004 at 11:36:13AM +0100, Thomas Fischbacher wrote:
>
> On Thu, 29 Jan 2004, William Lovas wrote:
>
> > # type ('a, 'b) specialist = S of (('a, 'b) specialist -> 'a -> 'b);;
> > type ('a, 'b) specialist = S of (('a, 'b) specialist -> 'a -> 'b)
> > # let fac n =
> > let do_rec (S specialist) n =
> > if n = 0 then
> > 1
> > else
> > n * specialist (S specialist) n
> > in
> > do_rec (S do_rec) n;;
> > val fac : int -> int = <fun>
>
> Hm, correct me if I am wrong, but to me this looks as if you had to
> unnecessarily cons at every recursive call...
Well, it depends on what you mean by "unnecessarily" and what you mean by
"cons". First, if by "cons" you mean "call a constructor", then yes, i did
have to cons at every recursive call. However, if by "cons" you mean
"allocate memory", i can't say for sure by looking at this code -- it says
nothing about the optimizations applied to variant types during compilation
or potential opportunities for structure sharing. I strongly suspect that
memory need not be allocated, though, in which case the answer is no, i did
not have to allocate memory at every recursive cell.
As far as "unnecessarily" goes, to me the calls are perfectly necessary --
otherwise the code wouldn't make sense -- I think in types first and code
second. :)
So if efficiency is your concern, you've nothing to worry about. If its
verbosity, then you have a fair argument -- you just have to weigh the
development time benefits against the small amount of extra code you have
to write beyond what LISP would require you to write. Personally, i think
it's worth it, but that's just an opinion.
cheers,
William
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners