caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Oliver Bandel <oliver@first.in-berlin.de>
To: caml-list@inria.fr
Subject: [Caml-list] Unix-Filekind => codexample with questions
Date: Sun, 21 Apr 2002 22:50:37 +0200 (MET DST)	[thread overview]
Message-ID: <Pine.LNX.3.95.1020421220023.174A-100000@first.in-berlin.de> (raw)

Hello,

I need a function, which tells me if a file is
a regular file or not.

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



This example works: It tells me, if a file is of kind/type
regular file with true. If it is not a regular file
or an error occured, it tells me this by passing
me the result false.

I thought about printing an error-message when an error
occurs. I can do this by inserting a printing-command
into the try-construct, if I return a Unix.st_kind-value
(so that Ocaml get's right types back). I tried this,
and it works - so I know how to handle the Unix.ENOENT
(and that makes my lucky :)). But I nevertheless have
more questions.





IMHO it looks a littlebid dirty, to return Unix.S_DIR
on an error-case, even if it is only internal to the
function is_regularfile.

Yes, I know, here is it an advantage of FPLs to give back
only the result and have the inner dirty tricks encapsulated
by the scoping here (at least that it is possible to
programn in this way, even if not mandatory).

But If I would split up the function into
three functions (one returning the filetype, one
doing the error-/exception-handling (giving back non-Unix.S_REG
e.g by using Unix.S_DIR) and one function, using these two functions,
returning a boolean value) the advantage of an FPL
is gone, because using unclean programming (which then
nevertheless is possible).
(Or is the problem here, that pattern-matching and
 exception-handling is not purely functional?)

Is there a type like "None of the defined Unix.st_kind-results",
such as NULL in C is definitely a non-valid address?

Does advantage of FPLs in respect to clean programming
belongs in "encapsulation by scoping" with nested
let-statements, which are hiding usage of unclean values
(like above)?

Or is it completely ok to write such functions like above?
(Philosophically question...?!)

BTW: What about the indentation-style of my function?
How would you rewrite that function, when using
Ocaml-like indentation?

TIA,
   Oliver

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


             reply	other threads:[~2002-04-21 20:55 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-04-21 20:50 Oliver Bandel [this message]
2002-04-21 21:04 ` Remi VANICAT
2002-04-21 21:17 ` John Prevost
2002-04-21 21:56   ` Markus Mottl
2002-04-23 14:45   ` Oliver Bandel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.LNX.3.95.1020421220023.174A-100000@first.in-berlin.de \
    --to=oliver@first.in-berlin.de \
    --cc=caml-list@inria.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).