On Jan 3, 2:32 pm, Vesa Karvonen <vesa.karvo...@[EMAIL PROTECTED]
> wrote:
> That is quite reasonable. It is certainly possible to do without
generics
> in ML, but in some contexts it means that you'll probably have to write
a
> lot more boilerplate code (typically for ha****ng and pretty printing).
Yeah, but I am maniacally adverse to boiler plate and code
duplication ;)
> Well, my libraries in mltonlib are certainly both experimental and
subject
> to change (read: improvements) although I don't currently have any
drastic
> (user visible) changes in mind. I try very hard to avoid bugs, of
course,
> and usually immediately fix any bugs I encounter. If you find any bugs,
> please re****t them. I also try to (and do) keep the code in mltonlib
> continuously in a state that compiles and works correctly, so using the
> libraries from a checked out and update SVN copy should not be a
problem.
I understand that, but when you have a set of libraries which are
reasonably stable, you could just package them and put a release
number
on them. That would make a difference on how the libraries are
perceived
from outside.
> In particular, I'd like there to be a convenient framework for building
> (and testing) all the libraries and examples in mltonlib. Note that
many
> libraries (including the generics library), particularly when used with
> MLton, in mltonlib actually don't require any separate build step. I'm
> not very fond of make, because it has poor facilities for abstraction
(not
> in the sense of computational completeness --- I believe (Gnu) make is
> Turing complete). I've been thinking about writing something like Rake
> for SML some weekend or I might just bite the bullet and write a
> comprehensive set of Makefiles for building most of mltonlib.
Have you considered cmake? Not that I have any significative
experience
with it, but I have read some good press about it.
> > Also I am happy when I see a bug tracker, a mailing list, and I have a
> > feeling that I am not the only user in the word.
>
> As hinted in the README files, the MLton users mailing list is
appropriate
> for discussing the libraries. You can also re****t bugs there --- the
> README files should probably mention this explicitly. Currently I feel
no
> need to introduce a bug tracker, but I would certainly consider it if
the
> need becomes apparent (e.g. having more than one or two outstanding
> external bug re****ts at a time).
Ok, I would subscribe to the MLton mailing list, even if it looks odd
to me, since I am not using MLton.
> The source files (mostly signature files) in the "public" subdirectories
> of my libraries usually contain comments that are intended to function
as
> reference do***entation. Some libraries are do***ented more thoroughly
> than others. If you find the reference do***entation of some specific
> library / signature lacking, feel free to re****t it. I plan to write a
> specialized tool that can convert a public directory written in roughly
> the form I've used into cross referenced do***entation, but that is not
at
> the top of my list of things to do.
I planned to do the same, but I wanted to do it in SML, this is why I
have not even started yet ;)
> Some libraries in mltonlib do use MLton's extensions (e.g. finalizers,
> ffi). I also hope that (some of) the libraries from mltonlib will
> eventually be packaged along with MLton. Perhaps this might happen in
the
> next major release.
This is why I think it would be useful to distribute separately the
****table
stuff.
> Note that the SML community isn't at civil war :-). I believe that most
> MLton users also use other SML implementations (usually with a REPL).
Yeah, but I also have some prejudice against whole program
compilation.
> Sounds like a good deal! Additional tutorial do***entation and examples
> would certainly be useful. I would recommend that you first concentrate
> on learning how to use the library, which, I believe, is reasonably easy
> once you get past the initial setup stage. I would be happy to help
with
> understanding how to use the library. Currently the generics library is
> fully usable with MLton, SML/NJ and Poly/ML. Understanding how the
> library is implemented (i.e. how it "works") is probably considerably
more
> difficult. For that I would recommend first reading my article. If
you'd
> like, I can e-mail you a copy of a slightly updated version of the
article
> and help with understanding it and how the library works.
Ok, send me the article, please.
> I would also recommend moving further discussion of specific libraries
in
> mltonlib to the MLton users mailing list
> (http://mlton.org/mailman/listinfo/mlton-user).
I doubt that folks in
> c.l.f are all that interested in such a specific topic and people who
are
> interested can always browse the publicly available mailing list
archives
> (or join the list).
>
> -Vesa Karvonen
Will do.
Michele Simionato
|
