Benjamin Canou schrieb:
Please note that this is an early version, in particular the DOM
interface module is neither pretty nor well typed.
If you enhance these APIs, you should probably try to coordinate it
with whatever might happen in http://code.google.com/p/ocamljs/
so that source code
O'Browser is an implementation of the OCaml virtual machine in JavaScript,
designed to run in web browsers.
What can I say? WOW, great idea!
--
Paolo
~
~
:wq
___
Caml-list mailing list. Subscription management:
Hi,
Good idea but maybe a browser plugin to manipulate DOM would be much more
efficient.
Still pretty instructive.
Franz
On 11/18/08 1:20 AM, Benjamin Canou [EMAIL PROTECTED] wrote:
Hi,
O'Browser is an implementation of the OCaml virtual machine in
JavaScript, designed to run in web
On Tue, Nov 18, 2008 at 06:14:45PM +0900, Burgisser Francois wrote:
Good idea but maybe a browser plugin to manipulate DOM would be much more
efficient.
But, sadly, much less portable.
--
Gabriel
___
Caml-list mailing list. Subscription management:
Dear list,
As you know, we've been working for several months of OCaml Batteries
Included. Early in the development, it appeared to us that, with the
large number of modules involved, we would need a hierarchy of modules.
For instance, for the moment, we have a module [System] containing
On Tue, Nov 18, 2008 at 10:56:18AM +0100, David Teller wrote:
open System.IO;;
open System.File;;
Your biggest problem is using dot ('.') instead of underscore ('_').
Using a dot means that the System namespace cannot be extended by
external packages. If you use an underscore then an
This raises two questions:
1) how important is it to allow third-party modules to extend the
namespace?
2) how important is it to offer a uniform package structure (where
levels are always separated by '.' rather than some level by '.' and
some by '_')?
For the moment, we have considered point 1
I thought the linker only linked in symbols which were actually used?
On Tue, 2008-11-18 at 11:21 +0100, Zheng Li wrote:
Your biggest problem is using dot ('.') instead of underscore ('_').
Using a dot means that the System namespace cannot be extended by
external packages. If you use an
Le 18 nov. 08 à 11:29, Erkki Seppala a écrit :
For example I prefer using the least amount of opening of modules,
to make it easier to see where the values come from
Same here. This is why I'm a little bit sceptical about this hierarchy.
With the current standard library if I suddenly want
On Tue, 2008-11-18 at 12:34 +0100, Daniel Bünzli wrote:
Besides Hierarchies are anyway limited in their descriptive power and
one day you'll find something that will fit in two places, Rope is
already an example being both Data.Persistent and Data.Text.
That's correct, there are plenty of
On Tue, Nov 18, 2008 at 01:15:39PM +0100, David Teller wrote:
Do you see any better way of managing the complexity of all this?
I'm still not getting where the benefit of having this hierarchy is,
except that it adds a Java-like complexity and will create
hard-to-manage churn if a module ever
On Tue, 2008-11-18 at 12:34 +0100, Daniel Bünzli wrote:
Le 18 nov. 08 à 11:29, Erkki Seppala a écrit :
For example I prefer using the least amount of opening of modules,
to make it easier to see where the values come from
Same here. This is why I'm a little bit sceptical about this
Ok, that's an interesting point. Now, we just need to all agree on one
standard :)
On Tue, 2008-11-18 at 12:28 +, Benedikt Grundmann wrote:
Do you see any better way of managing the complexity of all this?
Yes don't introduce it at all, make a decision to use or not use labels
and stick
On Tue, 2008-11-18 at 12:32 +, Richard Jones wrote:
API changes are handled really badly in OCaml, ironically because of
the lack of a textual preprocessor. You can't just write this every
time lablgtk / calendar / latest culprit decides to change their API:
#ifdef LABLGTK 210
let
David Teller wrote:
I thought the linker only linked in symbols which were actually used?
You really should check.
I have not yet looked too much into the source, but if the
batteries_core.ml is one of them to be referenced anyway, I'm afraid all
modules (not just parents/siblings) will be
Le 18 nov. 08 à 13:15, David Teller a écrit :
But, to keep things ordered, we will still need modules
[Threads.Threads], [Threads.Mutex], [Threads.RMutex]...
[CoThreads.Threads], [CoThreads.Mutex]... and, well, that's a
hierarchy
already.
If you include in batteries an external package
Hi,
I personally prefer the hierarchy but, once again, the majority
may disagree. So if you believe this is better, the next logical
step would be to design a full and consistent list of modules
including all the modules which already appear in the current
version of Batteries, and with some
David Teller wrote:
I thought the linker only linked in symbols which were actually used?
No, it is not the case.
The only automatic mechanism for code pruning is at the level of
individual modules embedded in a library. As soon as you pack, you
obtain a monolithic module which can only be
On Tue, 2008-11-18 at 05:31 -0800, Dario Teixeira wrote:
Paraphrasing Einstein, I think the hierarchy should be as flat
as possible, but no flatter. For example, I see no reason to
materialise in the hierarchy the separation between persistent
and mutable data structures. The should be a
On Tue, Nov 18, 2008 at 03:23:33PM +0100, David Teller wrote:
On Tue, 2008-11-18 at 05:31 -0800, Dario Teixeira wrote:
Paraphrasing Einstein, I think the hierarchy should be as flat
as possible, but no flatter. For example, I see no reason to
materialise in the hierarchy the separation
On Tue, 2008-11-18 at 14:24 +0100, Daniel Bünzli wrote:
Le 18 nov. 08 à 13:15, David Teller a écrit :
But, to keep things ordered, we will still need modules
[Threads.Threads], [Threads.Mutex], [Threads.RMutex]...
[CoThreads.Threads], [CoThreads.Mutex]... and, well, that's a
hierarchy
Ok, good to know. Since we're packing anyway, there's nothing we can do
yet. However, we've already planned to work on a dynamically linked
version of Batteries. Just not for release 1.0
So back to square 1 on this argument.
Thanks Alain Zheng
On Tue, 2008-11-18 at 15:10 +0100, Alain Frisch
On Tue, Nov 18, 2008 at 01:49:09PM +0100, David Teller wrote:
P.S.: I've pointedly ignored your perch on POD :) In my mind, that's a
very different topic. For the moment, we'll stick with ocamldoc.
I've used POD selectively even in OCaml projects, mainly because it is
by far the easiest way to
Dear Colleagues,
Just a reminder that submissions for HFL 2009 are due this Friday 21
November. Below is a link to the official call. We are looking forward
to another exciting workshop in 2009. We hope you will submit an
abstract and attend the workshop. Please email your submission to
[EMAIL
On Tuesday 18 November 2008 10:06:25 Richard Jones wrote:
On Tue, Nov 18, 2008 at 10:56:18AM +0100, David Teller wrote:
open System.IO;;
open System.File;;
Your biggest problem is using dot ('.') instead of underscore ('_').
Using a dot means that the System namespace cannot be extended
Excerpts from Jon Harrop's message of Tue Nov 18 19:17:23 +0100 2008:
On Tuesday 18 November 2008 10:06:25 Richard Jones wrote:
On Tue, Nov 18, 2008 at 10:56:18AM +0100, David Teller wrote:
open System.IO;;
open System.File;;
Your biggest problem is using dot ('.') instead of
On Tuesday 18 November 2008, you wrote:
On Mon, 2008-11-17 at 22:43 -0500, Kuba Ober wrote:
Please note that this is an early version, in particular the DOM
interface module is neither pretty nor well typed.
However, it can already be used to create little applets or scripts (as
in
On Tuesday 18 November 2008, Jon Harrop wrote:
On Monday 17 November 2008 16:20:50 Benjamin Canou wrote:
Hi,
O'Browser is an implementation of the OCaml virtual machine in
JavaScript, designed to run in web browsers.
It features a runtime library compatible with OCaml's standard one
Hi,
On Tuesday 18 November 2008 19:15:28 Kuba Ober wrote:
On Tuesday 18 November 2008, you wrote:
On Mon, 2008-11-17 at 22:43 -0500, Kuba Ober wrote:
Please note that this is an early version, in particular the DOM
interface module is neither pretty nor well typed.
However, it can
On Tue, Nov 18, 2008 at 06:17:23PM +, Jon Harrop wrote:
I don't follow. Can you not use include to extend an existing module:
# module Array = struct
include Array
You're missing the point which is scalability - how to deal with
distributed parties who are loosely coordinated. The
On Tuesday 18 November 2008 18:59:14 Richard Jones wrote:
On Tue, Nov 18, 2008 at 06:17:23PM +, Jon Harrop wrote:
I don't follow. Can you not use include to extend an existing module:
# module Array = struct
include Array
You're missing the point which is scalability - how to
On Tue, Nov 18, 2008 at 08:17:36PM +, Jon Harrop wrote:
If the library creator did not use functors or classes to make their design
reusable then the only solution for the user is to include all of the
implementations they require:
You're talking about something completely different.
In
Le 18 nov. 08 à 20:22, Richard Jones a écrit :
The proposal is to have a hierarchy of OCaml modules, of this sort:
Net
Net.Amazon
Net.BitTorrent
Net.FTPServer
(and a million more)
which doesn't scale.
If there is nothing in the Net module (and ignoring the linking issue)
you can
I'd like to see a plugin that makes available to JS a function to execute ocaml
bytecode. There could be a standard way to check for support, and the pure
javascript interpreter could be loaded if it is missing (for those
browsers/computers on which performance is reasonable).
--- On Tue,
On 11/18/2008 7:17 PM, Jon Harrop wrote:
I don't follow. Can you not use include to extend an existing module:
# module Array = struct
include Array
let empty = [||]
end;;
module Array :
sig
external length : 'a array - int = %array_length
...
val empty : 'a
On Tuesday 18 November 2008 09:56:18 David Teller wrote:
Now, we've decided that our current hierarchy is perhaps somewhat clumsy
and that it may benefit from some reworking. Before we proceed, we'd
like some feedback from the community...
I only have one major concern: you say with the large
On 11/19/2008 12:49 AM, Jon Harrop wrote:
Perhaps that could be solved with extensive Camlp4 hacking to rename the
previous modules (even coming from an include) to avoid the clash?
I don't think so. It seems you need type information.
That brings its own problems, of course. You no longer
On Tuesday 18 November 2008 22:07:33 Alain Frisch wrote:
and you want to extend M11, you need to write:
module M' = struct
module M1 = struct
module M11 = struct include M.M1.M11 (* extension here *) end
module M12 = M.M1.M12
module M13 = M.M1.M13
...
end
Do you have a sense of how hard this would be to fix? It would be lovely to
have some reasonable namespace control without having to take chunks of the
namespace as all-or-nothing pieces
y
On Tue, Nov 18, 2008 at 9:10 AM, Alain Frisch [EMAIL PROTECTED] wrote:
David Teller wrote:
I
Whilst not really answering your question I'd like to point out mixin
modules [1]. This is a way to provide extensible modules, thus getting
you a lot of you'd want from a namespace system. I would guess these
would actually be harder to implement than namespaces; both seem to
require compiler
On Tue, 2008-11-18 at 23:30 +, Jon Harrop wrote:
On Tuesday 18 November 2008 09:56:18 David Teller wrote:
I only have one major concern: you say with the large number of modules
involved, we would need a hierarchy of modules but the number of modules
involved is tiny (a few dozen in
On Wednesday 19 November 2008 06:29:52 David Teller wrote:
On Tue, 2008-11-18 at 23:30 +, Jon Harrop wrote:
I only have one major concern: you say with the large number of modules
involved, we would need a hierarchy of modules but the number of modules
involved is tiny (a few dozen in
42 matches
Mail list logo
