Re: [Caml-list] Unix-Filekind => codexample with questions

[Oliver Bandel <oliver@first.in-berlin.de>]

On 21 Apr 2002, John Prevost wrote:

> >>>>> "ob" == Oliver Bandel <oliver@first.in-berlin.de> writes:
> 
>     ob> Hello, I need a function, which tells me if a file is a
>     ob> regular file or not.
> 
>     ob> Please look at my code-example:
> 
>         let is_regularfile name =
>               let filekind name = let tmp = Unix.stat name in tmp.Unix.st_kind
>               in
>               let fk = try (filekind name ) with
>                           | Unix.Unix_error (Unix.ENOENT,_,_) -> Unix.S_DIR
>                           | _ -> Unix.S_DIR
> 
>                in
>                match fk with
>                | Unix.S_REG -> true
>                | _          -> false;;
> 
> 
>     ob> This example works: It tells me, if a file is of kind/type
>     ob> regular file with true. If it is not a regular file or an
>     ob> error occured, it tells me this by passing me the result
>     ob> false.
> 
> How about:
> 
> let is_regularfile name =
>   try (match Unix.stat name with
>          | {Unix.st_kind = Unix.S_REG} -> true
>          | _ -> false)
>   with
>     _ -> false
> 
> I'm not sure why you're using so many intermediate values here--it
> just seems to make the code harder to figure out.  Better to just wrap
> a try around the whole check, and use a small simple match on the stat
> result.


I really started with more than one functions and then
only put them together into one function, to have a
cleaner function (not giving the Unix.S_DIR (as an indicator
of not-Unix.S_REG)i as returnvalue to the outside).

I thought about pattern-matching the records, and to
use the ".member"-notation of records directly to the
application of the stat-function (as in Markus' example),
but I didn't know if OCaml's syntax provides the latter one.

So I used my first working "one-function-only"-version
and asked you all for comments.



For example the part with

>               let fk = try (filekind name ) with
>                           | Unix..Unix_error (Unix.ENOENT,_,_) -> Unix.S_DIR
>                           | _ -> Unix.S_DIR

may be too verbose and does not make any sense, because both
cases return the same value and the "_"-match matches on
all cases.

But I'm relativley new to Ocaml and therefore I can see the details
in matching the error-value better, when written explicitly (the
first case) and it's easier to expand the matching, when using
copy&paste&change of that line (changing Unix.ENOENT to the
needed value after duplicating the line). So, some maybe
unnecessary looking constructs
in the code were helpers for understanding, what I'm doing.

With more experience in OCaml-programming I maybe do not need
such verbose code (and I really like brevity - that's one of
the main-reasons to choose OCaml as my favourite programming
language for future projects).

But nevertheless, it's always worth to think about
verbose coding of programs, if that clarifies the
intention. At least in C-programming, writing more
code than less may help in understanding, what's going on.
[1]

Maybe it's different in OCaml, because it's code
does contain enough sense per command-word/line of code.
In C there is too much bloat; and more verbose coding
can (may) help in understanding.

So the verbose coding of my example was a result of
too-many-years-C-programming and too less experience
in Ocaml-programming.


All answers had helped a lot.

Ciao,
   Oliver


[1]: I like the literate programming idea; e.g. haskell provides
 two programming styles: code with inserted comments,
 or text with inserted code; so programming and documenting
 the code means, to edit *one* document, but to get
 the program and the documentation as a result. And in this
 way it's much easier and more motivating to write documentation
 of code-snippets (and the real advantage comes in big projects).
 All other (non-literate-programming) attempts
 in programming (programming here means: design+coding+documenting)
 I have seen, doesn't worked well.


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