Gabriel Scherer writes:
> A summary to this lengthy mail:
> (1) Why type-enriched Camlp4 is an unreasonable idea
> (2) We should extract the typedtree; why it's hard
> (3) A fictional narrative of the camlp4/camlp5 history
> (4) Why you don't want to become Camlp4 maintainer
> (5) How we could tr
On Sat, Dec 10, 2011 at 10:12 PM, wrote:
> What I'd really like is a way to mix any version I want of the packages I
> install, especially experimental versions for the packages I want to test
> or
> contribute to.
> I stopped using GODI some time ago because I wanted master of ocaml and
> batter
Hi...
There are some cool but quite dirty tricks based on computed gotos
between functions to avoid problems with function size; see Section
5.2 of:
Compiling logic programs to C using GNU C as a portable assembler
Fergus Henderson, Zoltan Somogyi and Thomas Conway.
Proceedings of the ILPS '95 Pos
A summary to this lengthy mail:
(1) Why type-enriched Camlp4 is an unreasonable idea
(2) We should extract the typedtree; why it's hard
(3) A fictional narrative of the camlp4/camlp5 history
(4) Why you don't want to become Camlp4 maintainer
(5) How we could try not to use Camlp4 in the future
(6)
On Sat, Dec 10, 2011 at 15:45, Xavier Leroy wrote:
> 2- As pointed out already in this discussion, it's not on the Caml compiler
> that community efforts are most needed. For example, the most impactful
> action that his community could take, in my opinion, is to adopt and embrace
> a common pac
On 12/10/2011 04:49 PM, ri...@happyleptic.org wrote:
I will try to use it for some time.
But your description of it does not match my dreams.
Ideally, I would `odb install this-package --version=X.Y.Z`,
and `odb install another-one --branch=master`, and odb would
upgrade and/or rebuild what's req
On 12/10/2011 04:44 PM, Gabriel Scherer wrote:
Could you (or Sylvain) make a more precise picture of how exactly the
community could help in the Oasis-DB effort?
My opinion is that oasis-db+odb is good enough for wider use. I don't
know what plans Sylvain has for the oasis-db server side, but
> This is possible currently, by using the --stable, --testing and
> --unstable flags when installing different packages. Of course, the
> downside of this is that there's no guarantee or test of
> compatibility between packages and different versions of OCaml (and
> possibly each other). Oasis p
Edgar, It's excellent to know that you have some knowledge of Oasis-DB.
I share the common assumption that this is one of the missing bricks
of the OCaml ecosystem, and I hope the community at large can help
with it. I asked Sylvain about it a few months ago, but he wasn't sure
at that time what w
Jérémie Dimino writes:
> Le samedi 10 décembre 2011 à 19:10 +, Wojciech Meyer a écrit :
>> I'm aware that these are huge changes to Camlp4, but it would make
>> meta programming more powerful and push Camlp4 to the next level.
>
> Sure. But it seems that the next version of OCaml will have ru
On 12/10/2011 04:12 PM, ri...@happyleptic.org wrote:
What I'd really like is a way to mix any version I want of the packages I
install, especially experimental versions for the packages I want to test or
contribute to.
I stopped using GODI some time ago because I wanted master of ocaml and
batter
On Sat, Dec 10, 2011 at 09:44:01PM +0100, Diego Olivier Fernandez Pons wrote:
>
> What I see as the very first issue is the spread of the efforts between
> similar yet incompatible ML dialects leading to 4 weak communities (SML,
> OCaml, F#, Haskell) instead of a really strong one and all the rela
What I'd really like is a way to mix any version I want of the packages I
install, especially experimental versions for the packages I want to test or
contribute to.
I stopped using GODI some time ago because I wanted master of ocaml and
batteries but stable versions of everything else. So I ended
On 12/10/2011 03:32 PM, Andrei Formiga wrote:
The question is: what should be done? What must be done to enable
OASIS-DB?
Sylvain has worked with me to enable auto-installation of oasis-db
packages via odb[2]. There's not a large repo of packages[1], but most
of it is auto-installable (run o
Le samedi 10 décembre 2011 à 19:10 +, Wojciech Meyer a écrit :
> I'm asking, because certainly it would be a very wanted feature. I can
> see two major limitations of the current Camlp4/p5 system:
>
> - no way of recursively expand syntax, generate some code and then
> re-generate again usin
Caml-list
On 10 December 2011 13:58, Gabriel Scherer wrote:
> There already exist such a common denominator language. For
> performance reasons, it is architecture-dependent
[...]
>
There have been plans to move to a better common denominator, or at
> least a better bridge language (C--, LL
On Tue, Dec 6, 2011 at 12:24 PM, Jonathan Protzenko
wrote:
>
> = Improving the community =
>
> I think the main point of the discussion is to improve "the community". If
> we really want to improve OCaml as a whole, then I think we can put our
> efforts on better areas than patching the compiler.
and some spare time,
guys, I would like to build and improve the ocamlbrowser example in the
lablgtk2 applications directory. On my setup (OSX 10.6), the TK one doesn't
work, and I fear even on a working setup, it may discourage a lot of newcomers
to the language.
the problem is, it's the firs
and some spare time,
guys, I would like to build and improve the ocamlbrowser example in the
lablgtk2 applications directory. On my setup (OSX 10.6), the TK one doesn't
work, and I fear even on a working setup, it may discourage a lot of newcomers
to the language.
the problem is, it's the firs
Wojciech Meyer writes:
> Hi,
>
> Jérémie Dimino writes:
>
>> But there is something i don't understand here. Why is there camlp4 and
>> camlp5 ? These two projects do exactly the same thing and are
>> incompatible. So i don't see the point of maintaining them both. We
>> should at least deprecat
Hi,
Jérémie Dimino writes:
> But there is something i don't understand here. Why is there camlp4 and
> camlp5 ? These two projects do exactly the same thing and are
> incompatible. So i don't see the point of maintaining them both. We
> should at least deprecate one.
BTW: Are there any plans to
Le samedi 10 décembre 2011 à 15:45 +0100, Xavier Leroy a écrit :
> 5- Before embarking on patching the core Caml distribution, it wouldn't hurt
> to ask (privately) where the priorities are. For instance, I don't see the
> point for a linear-scan allocator (Benedikt Meurer) or more efficient
> com
Am 10.12.2011 13:58, schrieb Gabriel Scherer:
Moreover, it is basically impossible
to move up the abstraction ladder (eg. provide common runtime
components) without sacrificing universality or efficiency.
This might be relevant to the topic at hand:
http://lists.gnu.org/archive/html/dotgnu-gene
On 12/10/2011 04:45 PM, Xavier Leroy wrote:
> All right. Let me stop here and pray for constructive, non-knee-jerk
> reactions.
I am not an active member of the OCaml community, but I'll try to suggest
some (constructive I hope) solutions.
> see very few people actually joining these efforts.
On Dec 10, 2011, at 15:45 , Xavier Leroy wrote:
> This discussion started on the wrong foot, and I don't see how I could
> seriously consider Benedikt's plans given the amount of flaming and trolling
> that surround it. Benedikt, you should realize that your first message was
> aggressive, even
On Sat, 10 Dec 2011 00:18:25 +0100
Goswin von Brederlow wrote:
>
> Well, write the code as ONE function and do use lables. Sure, the C
> source will be huge for larger projects but then again you get the
> single source optimization bonus from gcc.
This won't work very well in practice, because
On 12/07/2011 12:18 PM, Gabriel Scherer wrote:
>> The French book "Le langage Caml" is very great, althought it is quite old,
>> and althought examples used in the book (write a pascal compiler, a grep
>> tool and so on) is maybe too theoristic for engineer target.
>> Maybe a translation would be
On 12/08/2011 10:10 AM, Benedikt Meurer wrote:
> Opening up the development of OCaml is a great suggestion, for
> example. Personally I'd even suggest to disconnect OCaml and INRIA,
> with an independent team of core maintainers (with appropriate spare
> time and knowledge). INRIA would still cont
Most projects are either academic research or industrial products. In
academia, reinventing a common language run-time won't get funding because
it is not novel enough. In industry, products that aren't economically
viable in the mid-term (years) or sooner won't get funding. So the common
solutions
On Sat, Dec 10, 2011 at 01:38:53PM +0100, ri...@happyleptic.org wrote:
> > I think that to achieve better
> > interoperability and "hype", one of those would be a better fit than the
> > current native and bytecode compilers.
>
> Next year is going to be exciting with so many people commiting them
There already exist such a common denominator language. For
performance reasons, it is architecture-dependent (I mean there are
several dialects to better use hardware peculiarities; the virtual
machine it runs on is not exactly virtual). Unfortunately, most
languages have concentrated on compiling
> I think that to achieve better
> interoperability and "hype", one of those would be a better fit than the
> current native and bytecode compilers.
Next year is going to be exciting with so many people commiting themselves
to develop all these additions to the compiler ! :-)
--
Caml-list maili
Le 10/12/2011 11:36, Diego Olivier Fernandez Pons a écrit :
> At some point I thought that C-- (http://www.cminusminus.org/index.html)
> and that type of work would converge to that but it never happened.
Interesting... but it doesn't seem to have evolved since 2007.
LLVM and Parrot advertised th
Stéphane Glondu wrote:
> C sure is not a good target language, but assembly is not either.
> The assembly backends of ocamlopt (and GHC... there is no support at all on
> some Debian ports) look like a maintenance burden that their authors obviously
> cannot cope with. I find the idea of making oca
Caml-list,
Given that other people are raising trolls, here is mine...
I have to admit I appreciate F# transparent interaction with C# libraries
which allows me to use large amounts of code that I would have had to
poorly rewrite otherwise (GUI, database, web stuff, etc). Same happens with
SM
On Dec 9, 2011, at 22:22 , Richard W.M. Jones wrote:
> On Fri, Dec 09, 2011 at 03:05:43PM +0100, Benedikt Meurer wrote:
>> Hm, I'm not sure. It's really easy to generate LLVM code for OCaml
>> in general, the problem is getting things to interact with legacy
>> OCaml code, with exception handling
On Dec 10, 2011, at 00:24 , Goswin von Brederlow wrote:
>>> Whether you call it a "fork" or a "distribution" doesn't matter.
>>
>> It does, IMHO. Forking a project allows you to integrate more intrusive
>> changes, and doesn't force you to stay compatible (in some way) with the
>> original work.
37 matches
Mail list logo
