|
»
« Return to Thread: tail recursion
Re: "ocaml_beginners"::[] Re: tail recursion
by Jon Harrop
::
Rate this Message:
On Tuesday 11 March 2008 20:23:50 Fabrice Marchant wrote:
> It's not the first time I run into problems ditching last parameters.
> Please what are the things to think to, to detect that kind of problem ?
This is the value restriction. Basically, you can cancel arguments from both
sides of a function definition except for the last argument in impure
languages like OCaml:
let f x y z = g 3 x y z
let f x y = g 3 x y
let f x = g 3 x
but not:
let f = g 3
> > if you want a fully polymorphic version, you need to wrote it as :
> > let append l =
> > let rec rappend = function
> > [] -> id
> >
> > | h::t -> rappend t <<- (cons h) in
> >
> > (rappend <<- List.rev) l
> >
> > which defeat your goal.
>
> A harsh term for half a failure : just one parameter is yet kept !
You might prefer:
let append =
...
fun l -> (rappend <<- List.rev) l
> > > Is it absolutely true that the 3 tiny functions id, cons and ( <<- )
> > > will be inlined without any efficiency loss ?
I believe function arguments to higher-order functions are not inlined. So
List.rev will not be inlined into ( <<- ).
> Looking at the generated code for comparison ( ugly 'as' syntax ) :
> I've programmed several assemblers, 8086 too, but this compiler output - as
> often - is pretty unreadable.
>
> However, I love the 'id' code : just 'ret' !
>
> I cannot be assertive but this indirect call, depending on what lies on
> camlTrop+... :
>
> movl %eax, 0(%esp)
> movl camlTrop + 4, %ebx
> movl (%eax), %eax
> movl (%ebx), %ecx
> call *%ecx
>
> doesn't seem to refer to an OCaml internal but more probably to a not
> inlined function.
>
> Adding a -inline 1 (or 2) option doesn't affect generated code.
You might try bigger numbers (like 1e6 :-).
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/?e
> It's not the first time I run into problems ditching last parameters.
> Please what are the things to think to, to detect that kind of problem ?
This is the value restriction. Basically, you can cancel arguments from both
sides of a function definition except for the last argument in impure
languages like OCaml:
let f x y z = g 3 x y z
let f x y = g 3 x y
let f x = g 3 x
but not:
let f = g 3
> > if you want a fully polymorphic version, you need to wrote it as :
> > let append l =
> > let rec rappend = function
> > [] -> id
> >
> > | h::t -> rappend t <<- (cons h) in
> >
> > (rappend <<- List.rev) l
> >
> > which defeat your goal.
>
> A harsh term for half a failure : just one parameter is yet kept !
You might prefer:
let append =
...
fun l -> (rappend <<- List.rev) l
> > > Is it absolutely true that the 3 tiny functions id, cons and ( <<- )
> > > will be inlined without any efficiency loss ?
I believe function arguments to higher-order functions are not inlined. So
List.rev will not be inlined into ( <<- ).
> Looking at the generated code for comparison ( ugly 'as' syntax ) :
> I've programmed several assemblers, 8086 too, but this compiler output - as
> often - is pretty unreadable.
>
> However, I love the 'id' code : just 'ret' !
>
> I cannot be assertive but this indirect call, depending on what lies on
> camlTrop+... :
>
> movl %eax, 0(%esp)
> movl camlTrop + 4, %ebx
> movl (%eax), %eax
> movl (%ebx), %ecx
> call *%ecx
>
> doesn't seem to refer to an OCaml internal but more probably to a not
> inlined function.
>
> Adding a -inline 1 (or 2) option doesn't affect generated code.
You might try bigger numbers (like 1e6 :-).
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/?e
« Return to Thread: tail recursion
| Free embeddable forum powered by Nabble | Forum Help |
