Browse thread
[Caml-list] Frustrated Beginner
[
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: | 2003-12-23 (06:53) |
From: | Dustin Sallings <dustin@s...> |
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