ocaml-lib-devel — Developer's mailing list

Re: [Ocaml-lib-devel] Filename and file manipulation

[<syl...@po...>]

Hello,

On Sun, Feb 01, 2004 at 10:54:27AM +0100, Nicolas Cannasse wrote:
> > Sometimes ago we were discussing about a possible library manipulation
> > filename and files.
> >
> > I have almost created it. I think it is pretty stable but i need
> > extended testing on different filename, and an expert eye on my code.
> >
> > You can find documentation and tarball here :
> > http://www.gallu.homelinux.org/~gildor/ocaml-fileutils/
> 
> Hello,
> 
> I had a look at SysPath. My first thoughs were that it's too much complex.
> It seems that in order to have multi OS library, you used several language
> features such as Functors , as well as a lexer plus a yacc parser for each
> system in order to parsing the paths. IMHO it's too heavyweight and the
> small differences ( drive letter and / against \ ) in path representation
> between systems should be handled with a maximal transparency.
> 
> Using functors to abstract something is nice if you're expecting the future
> users of your library to have the will to extend it further. I don't think
> it applies to this problem, since we already know well the 3-4 differents
> systems ( Unix , MacOS, Windows, Cygwin-? ) and there is an almost-zero
> probability that another system using a different path representation will
> be added to this list in the future...
> 
> Using a lexer and a yacc parser for parsing such easy things as paths is
> also - still IMHO - using a hammer to kick a mosquito. A simple custom
> lexer/parser such as the one I proposed in my original post should be enough
> and perhaps provide even better speed.
> In order to be KISS-compliant, I advise you to rewrote the whole SysPath
> using only one file and module.

Well, OK. You are right about the fact that is a bit complicated.
However, the difference doesn't lie only in separator. For example :
MacOS ":a" means for unix "./a" and "::a" means "./../a"...

For MacOS theres separator are context dependent. So i cannot apply
simple regexp for doing filename split... I can analyze the string and
adapt it to my need with String ( just like original implementation of
Flename ). But it is as heavy as lex/yacc. 

There is also the problem of escaped char...

To my mind, lex/yacc is kiss compliant. But it is only a point of view (
i use frequently this kind of construct because most of the time, when i
do a custom parser/lexer, it always finish to block me when i try to
extend it in any direction ). Concerning the speed, i think there is no
real difference between custom parser and yacc parser ( i will tend to
think that it is faster with yacc than with a custom parser ).

The code by itself (yacc+lex+interface)x(win32,unix,macOs,cygwin) + sysPath.ml
sysUtil.ml is not very long... And each module is KISS compliant. If i
merge all in one file, i will have something too complicated. 

Concerning other implementation, i think that one day i will add, some
others possibility, like URL et al. 

In fact, i think we do not agree on one thing : path and filename are
complicated too me -- maybe i am silly. You need to take in account a
lot of things to deals with this kind of things. 

> 
> SysUtil looks very good, I have no complaints about it :)
> 

At least, there is one good things ;-)

> Regards,
> Nicolas Cannasse
> 

Thanks for the report.
Kind regard
Sylvain LE GALL

Re: [Ocaml-lib-devel] Filename and file manipulation

[Nicolas C. <war...@fr...>]

Just a little additionnal suggestion about SysUtil :

SysUtil is heavily relying on the Unix module for its implementation, and
that's ok. But only one feature ( the Match pattern to match the filename
using a regexp) is using the Str module. In order to reduce dependencies, I
think you should abstract the Match, using an user define regexp matching.
For exemple :

in SysUtil.mli :
---

val configure_regexp : make:(string -> 'a) -> test:('a -> bool) -> unit

in SysUtil.ml :
-----
let regexp_make= ref (fun _ -> failwith "Regexp is not configured")
let regexp_test = ref (fun x _ -> failwith "Regexp is not configured"; x =
0) (* we need to give a type here for ungeneralized variables *)

let configure_regexp ~make ~test =
    regexp_make := Obj.magic make; (* we need to cast here because the type
we need is slighty different *)
    regexp_test := Obj.magic test

* and in testing Match :
    let reg = !regexp_make str in
    fun x -> !regexp_test reg x

Then the user could write :

SysUtil.configure_regexp Str.regexp Str.string_match
before making any Match

( we can also use only one function with currying trick :
    SysUtil.configure_regexp (fun reg -> let reg = Str.regexp reg in
(Str.String.match reg))
but it's then less comprehensible for the user )

Regards,
Nicolas Cannasse

Re: [Ocaml-lib-devel] Filename and file manipulation

[Nicolas C. <war...@fr...>]

> Sometimes ago we were discussing about a possible library manipulation
> filename and files.
>
> I have almost created it. I think it is pretty stable but i need
> extended testing on different filename, and an expert eye on my code.
>
> You can find documentation and tarball here :
> http://www.gallu.homelinux.org/~gildor/ocaml-fileutils/

Hello,

I had a look at SysPath. My first thoughs were that it's too much complex.
It seems that in order to have multi OS library, you used several language
features such as Functors , as well as a lexer plus a yacc parser for each
system in order to parsing the paths. IMHO it's too heavyweight and the
small differences ( drive letter and / against \ ) in path representation
between systems should be handled with a maximal transparency.

Using functors to abstract something is nice if you're expecting the future
users of your library to have the will to extend it further. I don't think
it applies to this problem, since we already know well the 3-4 differents
systems ( Unix , MacOS, Windows, Cygwin-? ) and there is an almost-zero
probability that another system using a different path representation will
be added to this list in the future...

Using a lexer and a yacc parser for parsing such easy things as paths is
also - still IMHO - using a hammer to kick a mosquito. A simple custom
lexer/parser such as the one I proposed in my original post should be enough
and perhaps provide even better speed.
In order to be KISS-compliant, I advise you to rewrote the whole SysPath
using only one file and module.

SysUtil looks very good, I have no complaints about it :)

Regards,
Nicolas Cannasse

[Ocaml-lib-devel] Filename and file manipulation

[Sylvain LE G. <syl...@po...>]

Hello all,

Sometimes ago we were discussing about a possible library manipulation
filename and files.

I have almost created it. I think it is pretty stable but i need
extended testing on different filename, and an expert eye on my code.

You can find documentation and tarball here :
http://www.gallu.homelinux.org/~gildor/ocaml-fileutils/

I wait for any of your comment on this code. If you think some functions
should be added, just tell me, or better send a bug report to
su...@bu... ( see README in the tarball to know
exactly the text that must precede the bug report ).

Features :
Filename :
- reduce "a/../b" -> "b"
- make absolute filename
- make relative filename
- reparent a filename=20
( a pair of others but not very interesting ).

Files :
- test
- mv
- cp
- rm
- find
- mkdir
- which
- list_dir

I hope it will be usefull for you. If you think the library is enough
stable, just tell me... I will make a public announcement.

Kind regard
Sylvain LE GALL

Re: [Ocaml-lib-devel] Re: Abstract IO

[Achim B. <bl...@la...>]

On Mon, Jan 26, 2004 at 01:55:49PM +0100, Nicolas Cannasse wrote:
> I agree with that, this is the correct behavior for a (string,string list)
> input, but what about a (char,string) input ? pos/seek should be expressed
> in the smallest unit of the two parameters ( char ). And here it's getting
> confusing because the \0 string separator is also a char.

What about the following definition: After a "seek inp n" inp is in the
same state as if after its creation exactly n read operations where
performed.

I have attached my proposal for an interface including seek.

Achim
-- 
________________________________________________________________________
                                                              | \_____/ |
   Achim Blumensath                                          \O/ \___/\ |
   LaBRI / Bordeaux                                          =o=  \ /\ \|
   www-mgi.informatik.rwth-aachen.de/~blume                  /"\   o----|
____________________________________________________________________\___|

Re: [Ocaml-lib-devel] Re: Abstract IO

[Nicolas C. <war...@fr...>]

[...]
> > Other case : if you have a file containing N strings of X characters
> > separated by \0 , then reading 3 strings will give you a position of
> > 3*(X+1) - including the \0 separator. It's difficult to add a concept of
> > "length" and "pos" on such tokens , although it's very easy to do in the
> > case ('a,'a list) input.
>
> So in this example you have an object of type
> (string, string list) input. Physically, the different strings are
> stored in a file separated by \0. But for the abstract interface this
> is irrelevant. In your example, if you read 3 strings then pos should
> return 3, /not/ the sum of the lengths of the individual strings, and if
> you do a "seek in 14" then the implementation should go to the start
> of the 15th string in the file.

I agree with that, this is the correct behavior for a (string,string list)
input, but what about a (char,string) input ? pos/seek should be expressed
in the smallest unit of the two parameters ( char ). And here it's getting
confusing because the \0 string separator is also a char.

Nicolas Cannasse

Re: [Ocaml-lib-devel] Re: Abstract IO

[Nicolas C. <war...@fr...>]

> Note that I suggested seek only for input streams.
>
> If I understand the interface correctly an object of type ('a, 'b) input
> semantically corresponds to a list of objects of type 'a with one
> selected position (the current one). Therefore, the semantics of seek
> and pos should be:
>
>  If "in" corresponds to the list a_0,...,a_n and a_i is the currently
>  selected element, then "pos in" should return i and "seek in k" should
>  mark a_k as new selected element.

The only problem I see is that doesn't scale well with strings.
As I show you before, you might consider strings as N-char-lists, but the
semantics of reading depends for example if the file is open in binary of
text mode.
Other case : if you have a file containing N strings of X characters
separated by \0 , then reading 3 strings will give you a position of
3*(X+1) - including the \0 separator. It's difficult to add a concept of
"length" and "pos" on such tokens , although it's very easy to do in the
case ('a,'a list) input.

Regards,
Nicolas Cannasse

Re: [Ocaml-lib-devel] Re: Abstract IO

[Nicolas C. <war...@fr...>]

> Just two comments.
>
> > exception No_more_input
>
> Why not just End_of_file?

We're talking here about abstract IO, that means that the underlying "item"
we're reading from can be a file, or a string, or anything else...

> val read : ('a, 'b) input -> 'a
> val nread : ('a, 'b) input -> int -> 'b
> val available : ('a, 'b) input -> int option
> val close_in : ('a, 'b) input -> unit
>
>  val seek : ('a, 'b) input -> int -> unit;
>  val pos  : ('a, 'b) input -> int;
>
> or, rather, define two input types: a sequential one and one with random
> access.

Theses two looks ok and could be added, but we need more closures to
implement them in an abstract way and we're not sure they can succeed ( seek
with negative index on a socket for example ).
The semantics is also not clear : for exemple if I create a (string,string
list) file-based output and write "HELLO" "WORLD" then I will be able to
read "HELLOWORLD" in one time from the corresponding input - that means that
I write 2 strings and read 1. Seek and pos units are based on a "character"
unit , while we're working here with a more abstract "token" type.

Regards,
Nicolas Cannasse

Re: [Ocaml-lib-devel] Re: Abstract IO

[Achim B. <bl...@la...>]

On Sat, Jan 24, 2004 at 09:55:54AM +0100, Nicolas Cannasse wrote:
> Here's a copy/paste of IO.mli

Just two comments.

> exception No_more_input

Why not just End_of_file?

> val read : ('a, 'b) input -> 'a
> val nread : ('a, 'b) input -> int -> 'b
> val available : ('a, 'b) input -> int option
> val close_in : ('a, 'b) input -> unit

What about

  val seek : ('a, 'b) input -> int -> unit;
  val pos  : ('a, 'b) input -> int;

or, rather, define two input types: a sequential one and one with random
access.

Achim
--=20
________________________________________________________________________
                                                              | \_____/ |
   Achim Blumensath                                          \O/ \___/\ |
   LaBRI / Bordeaux                                          =3Do=3D  \ /\ =
\|
   www-mgi.informatik.rwth-aachen.de/~blume                  /"\   o----|
____________________________________________________________________\___|

Re: [Ocaml-lib-devel] findlib

[Yamagata Y. <yor...@mb...>]

From: "Nicolas Cannasse" <war...@fr...>
Subject: Re: [Ocaml-lib-devel] findlib
Date: Sat, 24 Jan 2004 09:40:59 +0100

> I add a look , it's ok for me although I couldn't test since there is no
> findlib under windows. You can commit the changes.

Done.

Re: [Ocaml-lib-devel] Re: Abstract IO

[Yamagata Y. <yor...@mb...>]

From: "Nicolas Cannasse" <war...@fr...>
Subject: Re: [Ocaml-lib-devel] Re: Abstract IO
Date: Sat, 24 Jan 2004 09:55:54 +0100

> > 2) There would be pros and cons, but maybe objects (not abstract
> >    types) are more fitted to channels.  It makes extension easier, for
> >    example.
> 
> I don't see how it makes extension easier.

Subtyping makes it possible that a channel has its own interface, and
still behaves as a basic channel type.  Of course, there is a cost of
more complex typing.
cryptokit(http://pauillac.inria.fr/~xleroy/software.html) and
ocamlnet(http://ocamlnet.sourceforge.net/) make use of OO-channels.

> > 3) I'd like to see filter type.
> 
> Can you explain more ?

I'm thinking of an interface like

val apply_in : ('a, 'b) input -> ('a, 'b, 'c, 'd) filter -> ('c, 'd)
input

val apply_out : ('a, 'b, 'c, 'd) filter -> ('c, 'd, 'x) output -> ('a,
'b, 'x) output

> I thing that it would be nice to add something like a pipe :
> 
> IO.pipe : () -> ('a,'b) input * ('a,'b,unit) output

Unless it launchs new threads each time, (or we implement continuation
in ocaml) this has not much use.  We have to track which inputs
connect which outputs, oterwise the execution is blocked by the lack of
incoming data.

Re: [Ocaml-lib-devel] Re: Abstract IO

[Nicolas C. <war...@fr...>]

> > I had a look at it but it's a different approach than my proposal.
You're
> > actually restricting the IO's to char/string IO while I'm proposing to
have
> > generics IO that can write/read anything ( chars and strings, but also
> > tokens, lists, ... ).
>
> Ok, I had a quick look.  I think,
>
> 1) Output channels lack flush operation.  Is that ok?

True,

> 2) There would be pros and cons, but maybe objects (not abstract
>    types) are more fitted to channels.  It makes extension easier, for
>    example.

I don't see how it makes extension easier. Rewriting the basic functions
inside an object or passing them to IO.create_in/out is slighty the same,
except that object method lookup is more expensive. But I'm not against
adding an OO wrapper to the IO module for people who prefers using objects.

> 3) I'd like to see filter type.

Can you explain more ?
I thing that it would be nice to add something like a pipe :

IO.pipe : () -> ('a,'b) input * ('a,'b,unit) output

> (Btw, If you attachs sources as Text/Plain, not
> Application/Octetstream, then it makes viewing more easier.)

Here's a copy/paste of IO.mli , since some people are reading directly from
the archives it's maybe better since attachments are discarded.
I wanted to commit but looks like I can't checkout the CVS in developper
mode (only anonymous). I'll try later.

Best Regards,
Nicolas Cannasse

----------- IO.mli --------------------
type ('a, 'b) input
type ('a, 'b, 'c) output

exception No_more_input
exception Input_closed
exception Output_closed

val default_available : unit -> 'a option
val default_close : unit -> unit

val create_in :
  read:(unit -> 'a) ->
  nread:(int -> 'b) ->
  available:(unit -> int option) -> close:(unit -> unit) -> ('a, 'b) input

val create_out :
  write:('a -> unit) ->
  nwrite:('b -> unit) ->
  flush:(unit -> unit) -> close:(unit -> 'c) -> ('a, 'b, 'c) output


val read : ('a, 'b) input -> 'a
val nread : ('a, 'b) input -> int -> 'b
val available : ('a, 'b) input -> int option
val close_in : ('a, 'b) input -> unit

val write : ('a, 'b, 'c) output -> 'a -> unit
val nwrite : ('a, 'b, 'c) output -> 'b -> unit
val printf : ('a, string, 'b) output -> ('c, unit, string, unit) format4 ->
'c
val flush : ('a, 'b, 'c) output -> unit
val close_out : ('a, 'b, 'c) output -> 'c

val input_string : string -> (char, string) input
val output_string : unit -> (char, string, string) output

val input_channel : in_channel -> (char, string) input
val output_channel : out_channel -> (char, string, unit) output

val input_enum : 'a Enum.t -> ('a, 'a Enum.t) input
val output_enum : unit -> ('a, 'a Enum.t, 'a Enum.t) output

Re: [Ocaml-lib-devel] findlib

[Nicolas C. <war...@fr...>]

> > You might have a look at the Debian package of extlib
>
> I'm not familiar with Debian build system, but I think it doesn't make
> use of findlib in the installtion time, though it enable findlib to
> access extlib once it is installed.  In addition to searching library,
> Findlib have the ability to manage directories in which libraries are
> installed.  A nice ability for people like me, always forgetting the
> location of things.
>
> I made a quick hack which makes install.ml detect findlib.  The
> behavior doesn't change if findlib is not present.  The new install.ml
> is attached below.
>
> Please test this, if you are interested.

I add a look , it's ok for me although I couldn't test since there is no
findlib under windows. You can commit the changes.

Thanks,
Nicolas Cannasse

Re: [Ocaml-lib-devel] findlib

[Yamagata Y. <yor...@mb...>]

From: "Nicolas Cannasse" <war...@fr...>
Subject: Re: [Ocaml-lib-devel] findlib
Date: Thu, 22 Jan 2004 10:27:20 +0100

> You might have a look at the Debian package of extlib

I'm not familiar with Debian build system, but I think it doesn't make
use of findlib in the installtion time, though it enable findlib to
access extlib once it is installed.  In addition to searching library,
Findlib have the ability to manage directories in which libraries are
installed.  A nice ability for people like me, always forgetting the
location of things.

I made a quick hack which makes install.ml detect findlib.  The
behavior doesn't change if findlib is not present.  The new install.ml
is attached below.

Please test this, if you are interested.

--
Yamagata Yoriyuki

Re: [Ocaml-lib-devel] Re: Abstract IO

[Nicolas C. <war...@fr...>]

I'm sorry if the attachment MIME content was wrong (damn outlook :-).
I don't have a copy on my computer at work.
If someone is willing to post the sources again...

Regards,
Nicolas Cannasse

Re: [Ocaml-lib-devel] findlib

[Nicolas C. <war...@fr...>]

> IIRC, extlib installer does not support installation through findlib.
> Is this correct?  How people use extlib with findlib?
>
> I once made patch to installer enabling findlib support.  Since then,
> installer has been changed.  But if there is a interest, I'd try to
> make a new one.  What do you think?

You might have a look at the Debian package of extlib ( by Stephano
Zacchiroli ). Although the package is not up-to-date it uses findlib (a META
is included in the CVS, I don't know more about findlib).

Nicolas Cannasse

[Ocaml-lib-devel] findlib

[Yamagata Y. <yor...@mb...>]

IIRC, extlib installer does not support installation through findlib.
Is this correct?  How people use extlib with findlib?

I once made patch to installer enabling findlib support.  Since then,
installer has been changed.  But if there is a interest, I'd try to
make a new one.  What do you think?

--
Yamagata Yoriyuki

Re: [Ocaml-lib-devel] Re: Abstract IO

[Yamagata Y. <yor...@mb...>]

From: "Nicolas Cannasse" <war...@fr...>
Subject: Re: [Ocaml-lib-devel] Re: Abstract IO
Date: Wed, 21 Jan 2004 17:34:40 +0100

> I had a look at it but it's a different approach than my proposal. You're
> actually restricting the IO's to char/string IO while I'm proposing to have
> generics IO that can write/read anything ( chars and strings, but also
> tokens, lists, ... ).

Ok, I had a quick look.  I think,

1) Output channels lack flush operation.  Is that ok?

2) There would be pros and cons, but maybe objects (not abstract
   types) are more fitted to channels.  It makes extension easier, for
   example.

3) I'd like to see filter type.

(Btw, If you attachs sources as Text/Plain, not
Application/Octetstream, then it makes viewing more easier.)

--
Yamagata Yoriyuki

Re: [Ocaml-lib-devel] Re: Abstract IO

[Nicolas C. <war...@fr...>]

> Hello,
>
> Nicolas Cannasse wrote:
> > I sent this one a couple of weeks ago but didn't get any answer
>
> Probably because the module is not in CVS yet.

I was actually waiting for people thoughs before putting it on the CVS. Does
no-reply means that it's already perfect so I can add it ? :-)

> You might be interested in a similar module I wrote for my ant system.
>
>   www-mgi.informatik.rwth-aachen.de/~blume/pub/ant-current.tar.bz2
>
> The file is ant/tools/IO.ml.

I had a look at it but it's a different approach than my proposal. You're
actually restricting the IO's to char/string IO while I'm proposing to have
generics IO that can write/read anything ( chars and strings, but also
tokens, lists, ... ). But the nice thing is to actually add the
read/write_u16 , read/write_byte etc.... as you did in order to manipulate
binary files easier.

Nicolas Cannasse

[Ocaml-lib-devel] Re: Abstract IO

[Achim B. <bl...@la...>]

Hello,

Nicolas Cannasse wrote:
> I sent this one a couple of weeks ago but didn't get any answer

Probably because the module is not in CVS yet.

You might be interested in a similar module I wrote for my ant system.

  www-mgi.informatik.rwth-aachen.de/~blume/pub/ant-current.tar.bz2

The file is ant/tools/IO.ml.

Achim
-- 
________________________________________________________________________
                                                              | \_____/ |
   Achim Blumensath                                          \O/ \___/\ |
   LaBRI / Bordeaux                                          =o=  \ /\ \|
   www-mgi.informatik.rwth-aachen.de/~blume                  /"\   o----|
____________________________________________________________________\___|

Fw: [Ocaml-lib-devel] Abstract IO

[Nicolas C. <war...@fr...>]

I'm forwarding this message to the extlib list.
I sent this one a couple of weeks ago but didn't get any answer, I'm not
sure that it reached the list back then.


> Hi list,
>
> I just took some time to write a little module for handling IO in an
> abstract way.
> Several times I hit into some things that I wanted to print either in a
> string or in a file, here is some beginning of answer to this problem.
>
> For efficiency reason each input/output have two ways of reading/writing
> data : for example a chanr nel input can write char by char or directly
> strings. it's then a (char,string) input. An ouput takes a third parameter
> which is the value returned by a call to close.
>
> Then you can do the following :
>
> let o = IO.output_string() in
> IO.printf o "hello world %c"  '!';
> let s = IO.close_out o in
> print_endline s
>
> which is equivalent to :
>
> let o = IO.output_channel stdout in
> IO.printf o "hello world %c" '!';
> IO.close_out o; // are you sure :-)
>
> Comments are of course welcome,
>
> Nicolas Cannasse
>

Re: [Ocaml-lib-devel] suggestion: ExtString.unescape(d)

[Nicolas C. <war...@fr...>]

> Just a suggestion for an useful function that IMO is missing in the
> String module: String.unescaped. This function should be the inverse
> function of String.escaped, it seems to me really stupid to have an
> escaping function but not its counterpart!
[...]
> The only drawback of this implementation is that Genlex doesn't raises
> exception for the cases in which the compiler outputs warnings. The
> string "a\b" will be unescaped to "ab" ignoring the invalid "\". This is
> not a problem if you unescape string produced by escape but it can be a
> problem in other cases.

I see no problem in adding this one , as well as an alias :
let escape = escaped

But it would be better to add an raw implementation of unescape, without
relying on another module such as Genlex in order to minimize the
dependencies required by the ExtString module.

Regards,
Nicolas Cannasse

Re: [Ocaml-lib-devel] Std.input_list failing silently

[Nicolas C. <war...@fr...>]

> It appears that the Std.input_list function always returns [] when
> called from native code:

Thanks for the report !
It was a bug that is coming from the native code generator being too much
smart at optimizing list accesses. Looks like it's happening only when used
in conjonction with recursive loops. I fixed the implementation of
input_list ( as well as Enum.force which was using the same technique ).
Please update from the CVS.

Regards,
Nicolas Cannasse

[Ocaml-lib-devel] suggestion: ExtString.unescape(d)

[Stefano Z. <za...@bo...>]

Just a suggestion for an useful function that IMO is missing in the
String module: String.unescaped. This function should be the inverse
function of String.escaped, it seems to me really stupid to have an
escaping function but not its counterpart!

I'm also puzzled by the name "escaped", why not "escape"? Mysteries of
the ocaml standard libraray ... IMO is a good idea also to add the two
aliases String.{escape,unescape}.

On the implementation side I've used a dirty trick: the Genlex module.
String.escaped claims to follow ocaml lexing conventions and Genlex
claims the same. If its true, the implementation of String.unescaped
could be:

  let unescape =
    let lexer = lazy (Genlex.make_lexer []) in
    fun s ->
      let tok_stream = Lazy.force lexer (Stream.of_string ("\"" ^ s ^ "\"")) in
      match Stream.peek tok_stream with
      | Some (Genlex.String s) -> s
      | _ -> assert false

The only drawback of this implementation is that Genlex doesn't raises
exception for the cases in which the compiler outputs warnings. The
string "a\b" will be unescaped to "ab" ignoring the invalid "\". This is
not a problem if you unescape string produced by escape but it can be a
problem in other cases.

Cheers.

-- 
^Stefano Zacchiroli -- Master in Computer Science @ Uni. Bologna, Italy$
^zack@{cs.unibo.it,debian.org,bononia.it} -- http://www.bononia.it/zack$
^Frequentando il mio maestro mi ero reso conto [.] che la logica poteva$
^servire a molto a condizione di entrarci dentro e poi di uscirne -Adso$

[Ocaml-lib-devel] Std.input_list failing silently

[Peter J. <pe...@jo...>]

It appears that the Std.input_list function always returns [] when
called from native code:

$ cat > test.ml
let c = open_in "test.ml" in
let l = Std.input_list c in
print_int (List.length l);
close_in c

$ ocamlc -o ex extLib.cma test.ml && ./ex
4
$ ocamlopt -o ex extlib.cmxa test.ml && ./ex
0

This is with ExtLib 1.0b (with the Obj.set_field fix applied to std.ml)
and OCaml 3.07.