ocaml-lib-devel — Developer's mailing list

Re: [Ocaml-lib-devel] XML Light

[Maas-Maarten Z. <ma...@wa...>]

>
>
>>I'm currently rewriting my Xml-Light library which is a minimal Xml
>>parser/printer and adding DTD support to it.
>>    
>>
>
> Is it? Is it _really_ a minimal XML parser/printer?
> I fear it is just a parser/printer for a minimal _subset_ of XML!
> (e.g. Does it supports UNICODE characters? What about Entities?
>  What about Notation? Is it 100% fully compliant with the spec?)
>
> We do not need yet another standard for documents. Either it is
> fully XML compliant (and there is already PXP - native ocaml -
> or gdome2-ocaml - binding to libgdome) or it is unuseful/threatening.
>
>  
>
There is also an ocaml wrapper for expat.

Maas

Re: [Ocaml-lib-devel] XML Light

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

> > resulting library binary won't exceed few KB.
> > PXP have to go its own way, there is really enough space and need for
one
> > library like Xml Light, don't you think ?
>
> If you want my real opinion, after reading some of the Tim Bray
> discussions recently on the pros and cons of working with XML
>
> http://www.tbray.org/ongoing/When/200x/2003/03/16/XML-Prog
>
> I was looking forward to messing around with a regex style XML
> processor.  It looks much easier than any of the event, push,
> pull models of working with XML.
>
> Getting a Ocaml version of this would be cool and be a new
> direction in processing XML.

The OCaml pattern matching is enough for that, don't you think ?

while (<STDIN>) {
  next if (X<meta>X);
  if    (X<h1>|<h2>|<h3>|<h4>X)
  { $divert = 'head'; }
  elsif (X<img src="/^(.*\.jpg)$/i>X)
  { &proc_jpeg($1); }
  # and so on...
}


OCaml :

let process = function
    | Elements ("meta",_,_) -> ()
    | Elements ("h1",_,_) | Elements ("h2",_,_) | Elements ("h3",_,_) |
Elements ("h4",_,_)  -> divert := "head"
    | Elements ("img",attr,_) as x -> proc_jpeg (Xml.attrib x "src")
    | ... (* and so on *)
in
let rec walk = function
    | PCData _ -> ()
    | Elements (_,_,children) as x ->
        process x;
        List.iter walk children
in
walk (Xml.parse_in stdin)

Of course, this version is first reading all stdin and parsing it as a Xml
tree before processing, but I'm thinking right now of adding Lazy xml
processing to Xml Light so you parse only what you need. Others things
possible are to generate a MLI file from an DTD which will provide all types
and conversion functions from and to XML.

Nicolas Cannasse

Re: [Ocaml-lib-devel] XML Light

[Blair Z. <bl...@or...>]

Nicolas Cannasse wrote:
> 
> resulting library binary won't exceed few KB.
> PXP have to go its own way, there is really enough space and need for one
> library like Xml Light, don't you think ?

If you want my real opinion, after reading some of the Tim Bray
discussions recently on the pros and cons of working with XML

http://www.tbray.org/ongoing/When/200x/2003/03/16/XML-Prog

I was looking forward to messing around with a regex style XML
processor.  It looks much easier than any of the event, push,
pull models of working with XML.

Getting a Ocaml version of this would be cool and be a new
direction in processing XML.

Did you see the XML is too hard thread recently?  Check out

http://www.google.com/search?q=xml+too+hard

Best,
Blair

-- 
Blair Zajac <bl...@or...>
Plots of your system's performance - http://www.orcaware.com/orca/

Re: [Ocaml-lib-devel] XML Light

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

> > PXP is huge, complex, didn't managed to compiled it under Win32 in one
day,
> > but quite complete : this library is for "professionnal" XML users. Let
me
> > explain my thoughts... As far as I know, there is a lot of differents
ways
> > of using XML, and I'm pretty sure that about 85% of the usages are for
> > configuration files and import/export of XML data. Theses usages needs
only
> > the _subset_ of all the XML specs that Xml Light will support, I have no
> > ambition of rewriting a PXP, but I think it will be good for the OCaml
> > community to have such a small thing available. Of course, I would like
to
> > be as much compliant with the spec, so please review the code once
released.
> >
> > So I don't think its unuseful since I already had several users enjoying
the
> > previous version of Xml Light which was not even supporting CDATA et
PCDATA
> > ! And I don't think it's threatening either since with the help of the
> > community we will stick to a given subset of the specs.
>
> What about putting an easy to use wrapper around PXP then?  How about
> helping PXP run on Windows then?
>
> I'm sure I'm talking to a programmer here who, like me, would like to
> write new code rather than use existing code :)

I can't deny I am :-)
But I have also good arguments for it, for example the code size of the
resulting library binary won't exceed few KB.
PXP have to go its own way, there is really enough space and need for one
library like Xml Light, don't you think ?

Nicolas Cannasse

Re: [Ocaml-lib-devel] XML Light

[Blair Z. <bl...@or...>]

Nicolas Cannasse wrote:
> 
> PXP is huge, complex, didn't managed to compiled it under Win32 in one day,
> but quite complete : this library is for "professionnal" XML users. Let me
> explain my thoughts... As far as I know, there is a lot of differents ways
> of using XML, and I'm pretty sure that about 85% of the usages are for
> configuration files and import/export of XML data. Theses usages needs only
> the _subset_ of all the XML specs that Xml Light will support, I have no
> ambition of rewriting a PXP, but I think it will be good for the OCaml
> community to have such a small thing available. Of course, I would like to
> be as much compliant with the spec, so please review the code once released.
> 
> So I don't think its unuseful since I already had several users enjoying the
> previous version of Xml Light which was not even supporting CDATA et PCDATA
> ! And I don't think it's threatening either since with the help of the
> community we will stick to a given subset of the specs.

What about putting an easy to use wrapper around PXP then?  How about
helping PXP run on Windows then?

I'm sure I'm talking to a programmer here who, like me, would like to
write new code rather than use existing code :)

Best,
Blair

-- 
Blair Zajac <bl...@or...>
Plots of your system's performance - http://www.orcaware.com/orca/

Re: [Ocaml-lib-devel] XML Light

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

> > I'm currently rewriting my Xml-Light library which is a minimal Xml
> > parser/printer and adding DTD support to it.
>
>  Is it? Is it _really_ a minimal XML parser/printer?
>  I fear it is just a parser/printer for a minimal _subset_ of XML!

Yes it is.

>  (e.g. Does it supports UNICODE characters? What about Entities?
>   What about Notation? Is it 100% fully compliant with the spec?)

No, no, no, and no :-)

>  We do not need yet another standard for documents. Either it is
>  fully XML compliant (and there is already PXP - native ocaml -
>  or gdome2-ocaml - binding to libgdome) or it is unuseful/threatening.

Why do you think then I am "loosing" my time writing it then ?

PXP is huge, complex, didn't managed to compiled it under Win32 in one day,
but quite complete : this library is for "professionnal" XML users. Let me
explain my thoughts... As far as I know, there is a lot of differents ways
of using XML, and I'm pretty sure that about 85% of the usages are for
configuration files and import/export of XML data. Theses usages needs only
the _subset_ of all the XML specs that Xml Light will support, I have no
ambition of rewriting a PXP, but I think it will be good for the OCaml
community to have such a small thing available. Of course, I would like to
be as much compliant with the spec, so please review the code once released.

So I don't think its unuseful since I already had several users enjoying the
previous version of Xml Light which was not even supporting CDATA et PCDATA
! And I don't think it's threatening either since with the help of the
community we will stick to a given subset of the specs.

Nicolas Cannasse

[Ocaml-lib-devel] Added reversed enumerations to xarray

[Brian H. <bh...@sp...>]

Enumerations that count down instead of up.  I realized that in arrays I 
can decrement as easily as increment.

Brian

Re: [Ocaml-lib-devel] function application operator?

[Brian H. <bri...@ql...>]

While we're at it:

let curry f = fun a b -> f (a, b)

let uncurry f = fun (a, b) -> f a b

Brian

[Ocaml-lib-devel] function application operator?

[Brian H. <bri...@ql...>]

I was reading the Haskell wiki page (via Lambda the Ultimate) and came 
across this page:
http://www.haskell.org/hawiki/PipeliningFunctions

I don't think Ocaml has a function application operator- not that one is 
hard to write:
let ( $ ) : ('a -> 'b) -> 'a -> 'b = fun f x -> f x

or even more simply:

let ( $ ) f x = f x

Likewise, functional composition is fairly trivial to implement:

let ( $. ) f g x = f (g x)

I'm not 100% sure I see the purpose of having these operators- I'd just 
use parens, and instead of writting:
    foo $. bar $. bang $ x
I'd write
    foo (bar (bang x))
which does the same bleeding thing.  But I thought I'd throw the idea out 
to the listmind to see if we wanted to make things friendlier for any 
Haskel programmers who come our way?

Brian

Re: [Ocaml-lib-devel] Indentation

[Blair Z. <bl...@or...>]

Nicolas Cannasse wrote:
> 
> > Mixed spaces and tabs are bad.  Let us pick one, and stick with it.  My
> > preference is for spaces, but I'll work with tabs.
> 
> I know that the 4-chars-tabs I'm using are not so good, but it's quite
> difficult for me to start using spaces, since my MSVC editior doesn't allow
> the tab-as-spaces key. so right now I'ld prefer that we stick to tabs :-) We
> can still sed files later one finalized for a clean source release.

I vote for spaces.

Maybe you could run that sed command before any commits?

Best,
Blair

-- 
Blair Zajac <bl...@or...>
Plots of your system's performance - http://www.orcaware.com/orca/

Re: [Ocaml-lib-devel] email notices on cvs commits

[Brian H. <bh...@sp...>]

On Tue, 22 Apr 2003, Nicolas Cannasse wrote:

> > > > At work, our cvs is set up to email notices out to a mailing list when
> > > > commits happen.  Any chance of setting up our cvs server to do that?
> > >
> > > I can do it, but I would prefer a "commitlog" file in /CVSROOT/commitlog
> > > Since like this you can have a quick look at all modified files.
> >
> > I have added the following to /CVSROOT/loginfo file, but it doesn't seems
> to
> > work :
> >
> > ALL (echo ""; id; echo %s; date; cat) >> $CVSROOT/CVSROOT/commit.log
> 
> Okay, I added the "commit.log" file to CVSROOT and now I get :
> 
> sh: /cvsroot/ocaml-lib/CVSROOT/commit.log: Permission denied
> 
> when committing a file.
> This seems like a sourceforge-specific problem.
> I will disable it.
> 
> Nicolas Cannasse
> 

CVS commits now return:
sh: /usr/local/bin/cvs-commitmail: No such file or directory
cvs [server aborted]: received broken pipe signal
cvs commit: saving log message in /tmp/cvsaxoz6C

Something's not quite there yet.

Brian

Re: [Ocaml-lib-devel] Indentation

[Brian H. <bh...@sp...>]

On Tue, 22 Apr 2003, Nicolas Cannasse wrote:

> > Mixed spaces and tabs are bad.  Let us pick one, and stick with it.  My
> > preference is for spaces, but I'll work with tabs.
> 
> I know that the 4-chars-tabs I'm using are not so good, but it's quite
> difficult for me to start using spaces, since my MSVC editior doesn't allow
> the tab-as-spaces key. so right now I'ld prefer that we stick to tabs :-) We
> can still sed files later one finalized for a clean source release.

I'll handle tabs.  And tabs have the advantage that we don't need to fight 
over what level of indentation to use- set tabstops to whatever the heck 
you like.

It's *mixing* tabs and spaces which is the problem.  Even worse, as
microsoft and unix have different philosphies on how tabs work.  A tab in
unix moves you to the next column to the right whose number is a multiple
of tabstop, while in windows it moves you right tabstop columns.  So if 
you have the sequence "\t \t" at the begining of a line, with a tabstop of 
4, in unix you are in column 8 (the second tab only moves you three 
columns, not 4), while in windows you are in column 9.

If you have several people editing the file, some in unix and some in 
windows, some using tabs and some using spaces, and (of course) everyone 
using different tabstops, indenting become a nightmare.

Brian

Re: [Ocaml-lib-devel] XML Light

[Claudio S. C. <sac...@cs...>]

> I'm currently rewriting my Xml-Light library which is a minimal Xml
> parser/printer and adding DTD support to it.

 Is it? Is it _really_ a minimal XML parser/printer?
 I fear it is just a parser/printer for a minimal _subset_ of XML!
 (e.g. Does it supports UNICODE characters? What about Entities?
  What about Notation? Is it 100% fully compliant with the spec?)

 We do not need yet another standard for documents. Either it is
 fully XML compliant (and there is already PXP - native ocaml -
 or gdome2-ocaml - binding to libgdome) or it is unuseful/threatening.

 					Friendly,
					C.S.C.

-- 
----------------------------------------------------------------
Real name: Claudio Sacerdoti Coen
PhD Student in Computer Science at University of Bologna
E-mail: sac...@cs...
http://www.cs.unibo.it/~sacerdot
----------------------------------------------------------------

Re: [Ocaml-lib-devel] email notices on cvs commits

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

> > > At work, our cvs is set up to email notices out to a mailing list when
> > > commits happen.  Any chance of setting up our cvs server to do that?
> >
> > I can do it, but I would prefer a "commitlog" file in /CVSROOT/commitlog
> > Since like this you can have a quick look at all modified files.
>
> I have added the following to /CVSROOT/loginfo file, but it doesn't seems
to
> work :
>
> ALL (echo ""; id; echo %s; date; cat) >> $CVSROOT/CVSROOT/commit.log

Okay, I added the "commit.log" file to CVSROOT and now I get :

sh: /cvsroot/ocaml-lib/CVSROOT/commit.log: Permission denied

when committing a file.
This seems like a sourceforge-specific problem.
I will disable it.

Nicolas Cannasse

Re: [Ocaml-lib-devel] Indentation

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

> Mixed spaces and tabs are bad.  Let us pick one, and stick with it.  My
> preference is for spaces, but I'll work with tabs.

I know that the 4-chars-tabs I'm using are not so good, but it's quite
difficult for me to start using spaces, since my MSVC editior doesn't allow
the tab-as-spaces key. so right now I'ld prefer that we stick to tabs :-) We
can still sed files later one finalized for a clean source release.

Nicolas Cannasse

Re: [Ocaml-lib-devel] email notices on cvs commits

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

> > At work, our cvs is set up to email notices out to a mailing list when
> > commits happen.  Any chance of setting up our cvs server to do that?
>
> I can do it, but I would prefer a "commitlog" file in /CVSROOT/commitlog
> Since like this you can have a quick look at all modified files.

I have added the following to /CVSROOT/loginfo file, but it doesn't seems to
work :

ALL (echo ""; id; echo %s; date; cat) >> $CVSROOT/CVSROOT/commit.log


BTW, perhaps sourceforge CVS server is delaying some changes.
If there is any CVS expert around...

Nicolas Cannasse

[Ocaml-lib-devel] Indentation

[Brian H. <bri...@ql...>]

Mixed spaces and tabs are bad.  Let us pick one, and stick with it.  My 
preference is for spaces, but I'll work with tabs.

Brian

Re: [Ocaml-lib-devel] email notices on cvs commits

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

> At work, our cvs is set up to email notices out to a mailing list when 
> commits happen.  Any chance of setting up our cvs server to do that?

I can do it, but I would prefer a "commitlog" file in /CVSROOT/commitlog
Since like this you can have a quick look at all modified files.

Nicolas

Re: [Ocaml-lib-devel] Names for xarray: I propose dynarray

[Brian H. <bri...@ql...>]

On Tue, 22 Apr 2003, Nicolas Cannasse wrote:

> > According to the NIST, what I've implemented is a dynamic array:
> > http://www.nist.gov/dads/HTML/dynamicarray.html
> >
> > I hereby propose we rename it dynarray then.  I'm not worried about losing
> > revision control history- if I hadn't checked it in, we wouldn't have had
> > any to lose :-).
> 
> It would be perhaps nice to have then then same name-prefix for both
> "mutable" list and "mutable" array.
> RefList / RefArray ( this one make sense since the type Xarray.t contains a
> mutable 'array field )
> or
> DynList / DynArray
> 

No insult, but reflist confuses me.  With a few exceptions, it looks like 
it's just a ref to a list, and the functions just dereference the ref and 
call the appropriate list function.  I suppose I'm saying that I'm seeing 
enough meat on the bone here to make it a worthwhile library.

In any case, I don't think both it and xarray (whatever it gets renamed 
to) should have the same prefix.  Arrays in ocaml are already mutable- 
that's implicit.  But their size is immutable once created.  So we're 
adding the feature of being able to resize the array.  Likewise, in 
reflist, we're adding the feature of being able to mutably change the head 
of a list.

For dynlist I'd say it should be fully dynamic, like dynarray is.  Append 
and prepend and insert into the middle.  I need to play with how this 
should work a little.

Hmm.  Playing around a little bit, I notice that:

# let x = [| 1; 2; 3 |];;
val x : int array = [|1; 2; 3|]
# x. (1);;
- : int = 2
# x . (3);;
Exception: Invalid_argument "Array.get".
# x.3;;
Syntax error
# x. 3;;
Syntax error
# let ( %. ) = Array.get ;;
val ( %. ) : 'a array -> int -> 'a = <fun>
# x%.(3);;
Exception: Invalid_argument "Array.get".
# x%.(2);;
- : int = 3
# (3);;
- : int = 3
# x %. 2;;
- : int = 3
# 

Of course, %. looks like a floating point operator.  But this does open 
some possibilities for an accessor operator mostly like .().

Brian

[Ocaml-lib-devel] email notices on cvs commits

[Brian H. <bh...@sp...>]

At work, our cvs is set up to email notices out to a mailing list when 
commits happen.  Any chance of setting up our cvs server to do that?

BTW, I inlined setcdr, as discussed.

Brian

[Ocaml-lib-devel] Web Page

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

Hi,

I just noticed there is already a web page setuped at :
http://ocaml-lib.sourceforge.net/
But it's quite out dated.
It there some good willed people around who would like to take care of it ?

Thanks,
Nicolas Cannasse

Re: [Ocaml-lib-devel] Include usage

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

> This way we can even override the OCaml StdLib functions by redefining
them
> after the include statement.
> I think it would be nice to reduce this way the extList.ml code to only
> modified/new functions, that would make things a lot clearer and results a
> lower code size.
>
> What do you think of it ?

Done for ExtList.

Nicolas Cannasse

Re: [Ocaml-lib-devel] ExtList: using _setcdr instead of Obj.magic

[Brian H. <bri...@ql...>]

On Tue, 22 Apr 2003, Nicolas Cannasse wrote:

> > > It is called , it should actually be called when call - complexity is
> lower
> > > than O(n) since the overhead is not big.
> >
> > Which is never in list functions, that I know about.
> 
> I was talking about complexity in term of numbers of calls to _setcdr.
> BTW, you're right, I'm not sure there is functions with only one call to
> _setcdr

So was I.  I can't think of a function that calls _setcdr that doesn't 
call it O(n) times.  Which means we never called _setcdr- I remember 
grepping for it and not finding it.

> 
> > I've yet to hear this in a case where it turned out to be so.
> 
> This will need a very major changes in the entire Ocaml sources since it
> will involve modifying the current memory representation, and I'm pretty
> sure it won't happen before few years.

Yeah, this does strike me as being an unlikely change.  How many different 
formats are there for an immutable linked list are there?  2?  data then 
next, or next then data.  They chose the first one.  And I don't see any 
advantage to them switching.

> 
> > And I
> > notice the changes are sneaking out of ExtList- I note that Enum has an
> > Obj.magic call which is effectively _setcdr.  On my to-do list was to take
> > a long hard look at Enum.force to see if I could move that _setcdr back
> > into ExtList where it belongs.
> 
> From my point of view, the setcdr is a trick which should of course not be
> put in the interface extList.mli ( we agreed on that before ). And so if you
> want to use it in Enum, you have to rewrite it. This is a performance trick,
> since we could always build the list in the other way and then rev it, and a
> safe trick since we could instead use a non tail-rec call.
> As a performance trick , it should be inlined.
> As a safe trick, it shouldn't be shown to the user, and a _setcdr function
> shouldn't even exists :)
> 

OK.  You talked me into it.  _setcdr goes away, and I'll replace 
everything with Obj.magic calls.

Brian

Re: [Ocaml-lib-devel] ExtList: using _setcdr instead of Obj.magic

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

> > It is called , it should actually be called when call - complexity is
lower
> > than O(n) since the overhead is not big.
>
> Which is never in list functions, that I know about.

I was talking about complexity in term of numbers of calls to _setcdr.
BTW, you're right, I'm not sure there is functions with only one call to
_setcdr

> I've yet to hear this in a case where it turned out to be so.

This will need a very major changes in the entire Ocaml sources since it
will involve modifying the current memory representation, and I'm pretty
sure it won't happen before few years.

> And I
> notice the changes are sneaking out of ExtList- I note that Enum has an
> Obj.magic call which is effectively _setcdr.  On my to-do list was to take
> a long hard look at Enum.force to see if I could move that _setcdr back
> into ExtList where it belongs.

From my point of view, the setcdr is a trick which should of course not be
put in the interface extList.mli ( we agreed on that before ). And so if you
want to use it in Enum, you have to rewrite it. This is a performance trick,
since we could always build the list in the other way and then rev it, and a
safe trick since we could instead use a non tail-rec call.
As a performance trick , it should be inlined.
As a safe trick, it shouldn't be shown to the user, and a _setcdr function
shouldn't even exists :)

Nicolas Cannasse

Re: [Ocaml-lib-devel] Names for xarray: I propose dynarray

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

> According to the NIST, what I've implemented is a dynamic array:
> http://www.nist.gov/dads/HTML/dynamicarray.html
>
> I hereby propose we rename it dynarray then.  I'm not worried about losing
> revision control history- if I hadn't checked it in, we wouldn't have had
> any to lose :-).

It would be perhaps nice to have then then same name-prefix for both
"mutable" list and "mutable" array.
RefList / RefArray ( this one make sense since the type Xarray.t contains a
mutable 'array field )
or
DynList / DynArray

Nicolas Cannasse