This site is updated infrequently. For up-to-date information, please visit the new OCaml website at ocaml.org.

[Caml-list] Frustrated Beginner
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
 Date: 2003-12-23 (06:53) From: Dustin Sallings Subject: Re: [Caml-list] Frustrated Beginner
```
On Dec 22, 2003, at 22:26, Tyler Eaves wrote:

(I'm sending this back to the list because, as you pointed out, there
were a few problems with that example, so here's one for the archives).

> Okay, so far so good. I take it that in O'Caml the overhead of a
> function call is much less than in, say, C? Otherwise this approach
> would seem to be rather inefficient.

Well, the short answer is that that's not a function call.  :)  See
tail-recursion.

It's also not the best example since it was so simple and didn't
return anything useful.  Consider this implementation of fold (roughly
translating it in this email from a scheme version I wrote on my palm):

let rec fold f init lst =
match lst with
[] -> init
| h::t -> fold f (f init h) t
;;

If you're not familiar with fold, here's an example:

fold (fun v c -> c + v) 0 [1;2;3;4;5;6;7;8;9;10]

That invocation returns 55.  Basically, the function is called for
each value in the list (v) and the current value is passed in along
with the current value during the calculation (c).  When it gets to the
end (list is []), you return the init value.  Otherwise, you apply the
function.

Note that this function could also be written as follows (and probably
would be):

let rec fold f init = function
[] -> init
| h::t -> fold f (f init h) t
;;

> 	Would not Stream.iter be worth considering here? I found that when
> looking at at the Stream doc.

Absolutely.  I haven't typically used streams that way.  How 'bout a
rewrite:

let f = open_in Sys.argv.(1) in
(* Loop on this stream *)
Stream.iter (function
'\t' -> print_string " - tab - "
| c -> print_char c
) (Stream.of_channel f);
close_in f

>>     (* The previous statement had a sem because it's an imperative
>> style here *)
>>     close_in f
> 	Will this close EVER be reached? I see only two possibilities, either
> the stream eventually EOFs, or we've hit an 'infinite' file, such as
> /dev/random

Good catch. :)  I think that was another example of using streams a
bit different from how I usually do, but bad examples are worse than no
examples.  Or maybe it was one of those ``find the bug'' assignments.
:)

--
SPY                      My girlfriend asked me which one I like better.
pub  1024/3CAE01D5 1994/11/03 Dustin Sallings <dustin@spy.net>
|    Key fingerprint =  87 02 57 08 02 D0 DA D6  C8 0F 3E 65 51 98 D8 BE
L_______________________ I hope the answer won't upset her. ____________

-------------------
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

```