[Caml-list] Generating C stubs

[Caml-list] Generating C stubs

[Jérôme Marant]

  Hi,

    In order to avoid spending some time on writing C stubs
    myself, I'd like them to be generated automaticaly.
    There are currently 3 stub generators: camouflage, ffi
    and another one I don't recall (IIRC, someone claimed
    that he was working on a SWIG interface).

    I'm a bit confused since I don't really know what generator
    to choose among all those. Moreover, they all seem to have
    been last update in august 2001 and the C interface may
    have changed since.

    Has anyone experiences and advices about this?

    Thanks in advance. 

    Regards,

-- 
Jérôme Marant
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Generating C stubs

[Jocelyn Sérot]

Le mercredi 15 mai 2002, à 11:13 , Jérôme Marant a écrit :

>   Hi,
>
>     In order to avoid spending some time on writing C stubs
>     myself, I'd like them to be generated automaticaly.
>     There are currently 3 stub generators: camouflage, ffi
>     and another one I don't recall (IIRC, someone claimed
>     that he was working on a SWIG interface).
>
>     I'm a bit confused since I don't really know what generator
>     to choose among all those. Moreover, they all seem to have
>     been last update in august 2001 and the C interface may
>     have changed since.
>
>     Has anyone experiences and advices about this?
>
>     Thanks in advance.
>
>     Regards,
>


I've been using CAMLIDL (http://caml.inria.fr/camlidl/) extensively and 
it works well.
It does not work directly from your C headers (.h) but from a IDL 
signature, but writting this
sig is straightforward in most of the cases.

Jocelyn

--
E-mail: Jocelyn.Serot@l_a_s_m_e_a.u_n_i_v-bpclermont.fr
S-mail: LASMEA - UMR 6602 CNRS, Universite Blaise Pascal, 63177 Aubiere 
cedex
Tel: +33.(0)4.73.40.73.30 - Fax: +33.(0)4.73.40.72.62
http://wwwlasmea.univ-bpclermont.fr/Personnel/Jocelyn.Serot/Welcome.html
Valid e-mail: remove underscores (sorry, this is prevention against junk 
mail)
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Generating C stubs

[Jérôme Marant]

On Wed, May 15, 2002 at 11:49:50AM +0200, Jocelyn Sérot wrote:
> 
> I've been using CAMLIDL (http://caml.inria.fr/camlidl/) extensively and 
> it works well.
> It does not work directly from your C headers (.h) but from a IDL 
> signature, but writting this
> sig is straightforward in most of the cases.

  I thought that CamlIDL was targeted at COM and interprocess communication,
  wasn't it?

-- 
Jérôme Marant
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Generating C stubs

[Remi VANICAT]

Jérôme Marant <jerome.marant@fr.thalesgroup.com> writes:

> On Wed, May 15, 2002 at 11:49:50AM +0200, Jocelyn Sérot wrote:
>> 
>> I've been using CAMLIDL (http://caml.inria.fr/camlidl/) extensively and 
>> it works well.
>> It does not work directly from your C headers (.h) but from a IDL 
>> signature, but writting this
>> sig is straightforward in most of the cases.
>
>   I thought that CamlIDL was targeted at COM and interprocess communication,
>   wasn't it?

It is also useful for generating interface between C and caml
-- 
Rémi Vanicat
vanicat@labri.u-bordeaux.fr
http://dept-info.labri.u-bordeaux.fr/~vanicat
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Generating C stubs

[Jérôme Marant]

Remi VANICAT <vanicat@labri.u-bordeaux.fr> writes:

> Jérôme Marant <jerome.marant@fr.thalesgroup.com> writes:
>
>> On Wed, May 15, 2002 at 11:49:50AM +0200, Jocelyn Sérot wrote:
>>> 
>>> I've been using CAMLIDL (http://caml.inria.fr/camlidl/) extensively and 
>>> it works well.
>>> It does not work directly from your C headers (.h) but from a IDL 
>>> signature, but writting this
>>> sig is straightforward in most of the cases.
>>
>>   I thought that CamlIDL was targeted at COM and interprocess communication,
>>   wasn't it?
>
> It is also useful for generating interface between C and caml

  Right. Thanks.

-- 
Jérôme Marant

http://marant.org
              
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Generating C stubs

[Florian Hars]

Jérôme Marant wrote:
>   I thought that CamlIDL was targeted at COM and interprocess communication,
>   wasn't it?

Yeah, the CamlIDL web site is one of the worst marketing blunders in the
history of modern computing in insinuating that it is exclusively targeted
at Windows-only programs. Unix only enters the picture as an afterthought
further down the page where everyone who is not looking for a Windows
solution has long since stopped reading. (Apart form the fact that no
sane programmer in full possession of his mental abilities would use
something with "IDL" in its name for a task as simple as linking to a
shared library :-))

Why not start the page with something like
"CamlIDL generates stub code to use C libraries and C++ classes
from Objective Caml from high level definitions. Under Windows it can
also provide COM bindings." 

And maybe the Ocaml manual should mention the existence of CamlIDL in
the introduction of the chapter about interfacing C with Ocaml, like
(stealing parts from the lower half of the website) "The following chapter
documents the low level interface between C and Objective Caml. For
practical programming tasks it might be more appropiate to use a tool
like CamlIDL that operates on a higher level of abstraction and takes
care of details such as those pesky Val_xxx and Xxx_val macros, proper
registration of GC roots, the different calling conventions from bytecode
and from native-code, etc."

Yours, Florian Hars.
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Generating C stubs

[Markus Mottl]

Florian Hars schrieb am Donnerstag, den 16. Mai 2002:
> And maybe the Ocaml manual should mention the existence of CamlIDL in
> the introduction of the chapter about interfacing C with Ocaml, like
> (stealing parts from the lower half of the website) "The following chapter
> documents the low level interface between C and Objective Caml.

And maybe it could also be made part of the distribution? We now already
have camlp4 and ocamldoc in it so a few bytes more don't make a big
difference anyway.

LG,
Markus

-- 
Markus Mottl                                             markus@oefai.at
Austrian Research Institute
for Artificial Intelligence                  http://www.oefai.at/~markus
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

[Caml-list] Camlp4/OCaml [was: Generating C stubs]

[Daniel de Rauglaudre]

On Thu, May 16, 2002 at 09:34:06AM +0200, Markus Mottl wrote:

> And maybe it could also be made part of the distribution? We now already
> have camlp4 and ocamldoc in it so a few bytes more don't make a big
> difference anyway.

The inclusion of Camlp4 being eventually a bad idea, in next version,
Camlp4 will be distributed separately, like before.

-- 
Daniel de RAUGLAUDRE
daniel.de_rauglaudre@inria.fr
http://cristal.inria.fr/~ddr/
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Camlp4/OCaml [was: Generating C stubs]

[Chris Hecker]

>The inclusion of Camlp4 being eventually a bad idea, in next version,
>Camlp4 will be distributed separately, like before.

Why?  It seemed like a great idea to me!

And what's going to happen with streams?

Chris

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Camlp4/OCaml [was: Generating C stubs]

[John Prevost]

>>>>> "ddr" == Daniel de Rauglaudre <daniel.de_rauglaudre@inria.fr> writes:

    ddr> The inclusion of Camlp4 being eventually a bad idea, in next
    ddr> version, Camlp4 will be distributed separately, like before.

Really?  Why did someone decide that inclusion was a bad idea?

John.
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Camlp4/OCaml [was: Generating C stubs]

[Daniel de Rauglaudre]

On Thu, May 16, 2002 at 03:39:45PM -0400, John Prevost wrote:

> Really?  Why did someone decide that inclusion was a bad idea?

I say it. Camlp4 and the attempts to improve the syntax have been
considered *officially* by the OCaml team as a "not serious" work and a
"loss of time". As I worried about that, and asked for more information,
it has been confirmed by the team, moreover with several personnal attacks.

Sorry for this "human" problem, but I cannot create and have
imagination in my work when I am considered like that.

Camlp4 continues and I made many changes, but in the previous CVS
distribution, directory "camlp4", no more "ocaml/camlp4". It will
be distributed normally just after OCaml releases and perhaps with
intermediate releases.

-- 
Daniel de RAUGLAUDRE
daniel.de_rauglaudre@inria.fr
http://cristal.inria.fr/~ddr/
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Camlp4/OCaml [was: Generating C stubs]

[Chris Hecker]

I don't want to get into any "human problem" with the inria folks, but a 
brief technical note is warranted, I think:

I believe meta-programming, both at the parsing level that camlp4 does, and 
taking it farther to being able to meta-program with types, other 
semantics, at code gen time, and throughout the compiler, is a very 
important area of research for moving programming languages (and the craft 
of programming) forward.  There seems to be a lot of research on this 
(camlp4 has been referenced in research papers a couple times), and I hope 
there's more in the future.

I don't care much about the revised syntax (I'd switch if it was deemed 
"official"), but the meta-programming part of camlp4 should be valued by 
the team, in my opinion.

When I talk to other programmers in my industry about caml, I mention 
camlp4 as one of the features they should consider when evaluating the 
language relative to other languages.

Chris

"I'd rather write programs to write programs than write programs." - Dick Sites


-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Camlp4/OCaml [was: Generating C stubs]

[Markus Mottl]

On Thu, 16 May 2002, Daniel de Rauglaudre wrote:
> On Thu, May 16, 2002 at 03:39:45PM -0400, John Prevost wrote:
> > Really?  Why did someone decide that inclusion was a bad idea?
> I say it. Camlp4 and the attempts to improve the syntax have been
> considered *officially* by the OCaml team as a "not serious" work
> and a "loss of time". As I worried about that, and asked for more
> information, it has been confirmed by the team, moreover with several
> personnal attacks.

Sigh. I also don't want to mess with social issues at INRIA, but find
it strange indeed that this is the official line. The only reason
so far why I didn't use camlp4 too often in the past was _because_ it
obviously didn't get enough official support. Its addition to the standard
distribution seemed like a good idea to me. I consider it a very useful
tool for a language that is still a somewhat moving target and which may
require syntax changes in the future. Those could be done with much less
hassle given a powerful tool. Not to mention extensions needed by users.

The syntax question has already been raised here several times so I
don't want to do it again. Suffice it to say that OCaml _has_ syntactic
problems about which beginners stumble frequently as I still remember
from my beginner time and as I can observe with people whom I have just
recently converted. One can get accustomed to and work around those
issues, but this doesn't really make them go away.

Regards,
Markus Mottl

-- 
Markus Mottl                                             markus@oefai.at
Austrian Research Institute
for Artificial Intelligence                  http://www.oefai.at/~markus
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Camlp4/OCaml [was: Generating C stubs]

[Alessandro Baretta]

Markus Mottl wrote:
> On Thu, 16 May 2002, Daniel de Rauglaudre wrote:
> 
>>On Thu, May 16, 2002 at 03:39:45PM -0400, John Prevost wrote:
>>
>>>Really?  Why did someone decide that inclusion was a bad idea?
>>
>>I say it. Camlp4 and the attempts to improve the syntax have been
>>considered *officially* by the OCaml team as a "not serious" work
>>and a "loss of time". As I worried about that, and asked for more
>>information, it has been confirmed by the team, moreover with several
>>personnal attacks.
> 

FAIW, let me say I'm shedding blood to make my code compile 
when I raise exceptions that have non banal type lists: I 
always misplace my parentheses. I never realized there was 
an alternative syntax provided by CamlP4, but I'm pretty 
sure this must be the solution to my crux. Should this be 
the case, I would find it considerably inconveniencing if 
camlp4 should be removed from the distribution.

Alex Baretta

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Camlp4/OCaml [was: Generating C stubs]

[Pierre Weis]

> FAIW, let me say I'm shedding blood to make my code compile 
> when I raise exceptions that have non banal type lists: I 
> always misplace my parentheses.

Have you ever read the programming guidelines that explain the
``secrets'' of Caml parentheses ?

http://pauillac.inria.fr/caml/FAQ/pgl-eng.html

Section IV: When to use parentheses within an expression

If you learn the rules, if you follow those guidelines, and still
experience problems, please let me know, since I used those simple
principles for years with thousands of students (I really mean several
thousands students not several students) and they had no problems once
they had understood and learned those rules.

On the other hand, I agree with you that if you don't know the rules
for parens in Caml, you certainly should have problems to write your
programs. This is the same problems as the one of young people at
school that use to claim that mathematics _HAVE_ (*) syntactic
problems because they never know where to put parens in

1 + 2 * 3

As a teacher, I always said that probably _THEY_ (*) have to learn the
rules first, then use them properly, and then they could criticize the
notations and at the end they will probably could have authority to
claim that mathematics have problems. Fortunately, none of them ever
reached this final step! However, they could have been right in the
first place, and mathematical notation could have to be revisited; for
the time being, nobody cares, every body still have to learn the
meaning of

1 + 2 * 3

Best regards,

Pierre Weis

INRIA, Projet Cristal, Pierre.Weis@inria.fr, http://pauillac.inria.fr/~weis/

(*) In their slang those pupils use upper case letters to mean that
this is true, also to insist that this is not only true but also TRUE,
and even that this is definitely _TRUE_.
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Camlp4/OCaml [was: Generating C stubs]

[Markus Mottl]

On Fri, 17 May 2002, Pierre Weis wrote:
> Section IV: When to use parentheses within an expression

I know that I should write OCaml-programs rather than participate in
yet another heating debate on syntax, but I just cannot resist...

> If you learn the rules, if you follow those guidelines, and still
> experience problems, please let me know, since I used those simple
> principles for years with thousands of students (I really mean several
> thousands students not several students) and they had no problems once
> they had understood and learned those rules.

It is not an argument in favour of certain syntactic rules that "people
have no problems once they have understood and learned those rules". I
agree that those rules for OCaml are not overly many and can indeed be
understood after some time. But why shouldn't we make this process even
easier by eliminating a few of them or making them simpler to comprehend
and apply?

There are cases where the current syntax can byte you by leading to
programs that compile nicely but exhibit unintended behaviour. This
certainly occurs very, very rarely and can be avoided when the programmer
happens to be in a somewhat sane state of mind. The problem is that
(at least what concerns me ;) the latter is not always the case. Syntax
designers, too, are probably well-advised to follow the principle:
"Never trust human programmers!".

> On the other hand, I agree with you that if you don't know the rules
> for parens in Caml, you certainly should have problems to write your
> programs. This is the same problems as the one of young people at
> school that use to claim that mathematics _HAVE_ (*) syntactic
> problems because they never know where to put parens in

We all have to learn conventions and standards. This does not mean that
all of them are equally clean and concise. To me OCaml is syntactically
much more beautiful than most mainstream languages. Why not let the
latter even further behind in the dust?

This all is not a plea for the Revised Syntax. IMHO, there are some things
it fixes, others that could be fixed differently and cases where we would
still need a fix. I am sure that Daniel would be prepared to discuss
this and eventually "revise the Revised Syntax". But it seems obvious
that syntactic issues are considered a non-topic by the project leaders.

My guess is that it is really pragmatic issues (costs of change; more
urgent issues) that prevent this discussion. If it is so, then why not
be honest about it?  I could live with the argument that you consider
such a step too costly, but have some sense of indirection when syntactic
problems are just discussed away.

Best regards,
Markus Mottl

-- 
Markus Mottl                                             markus@oefai.at
Austrian Research Institute
for Artificial Intelligence                  http://www.oefai.at/~markus
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Camlp4/OCaml [was: Generating C stubs]

[Pierre Weis]

> On Fri, 17 May 2002, Pierre Weis wrote:
> > Section IV: When to use parentheses within an expression
> 
> I know that I should write OCaml-programs rather than participate in
> yet another heating debate on syntax, but I just cannot resist...

Dear Markus,

You know that I'm not on the side of those that consider syntax as a
minor concern and a waste of time: to you I can say the truth because
I know you will understand it, but please do not tell it to others! In
my mind there is no clear distinction between syntax and semantics. We
very often use syntactic models of theories, hence acknowledging the
fact that difference between syntax and semantics is tenious, subtle,
and more or less a question of point of view (consider for instance
Lisp S-expressions first as abstract syntax trees (syntactic view),
and then as programs and values (semantics view)).

Hence, (to me) there is no question about the fact that semantics
(hence syntax) is of primordial importance. So that we have to improve
the syntax of the language if we can. But we cannot say that the
regular syntax is EXTREMELY ambiguous (with upper case letters and the
like). Be quite, please! It is not ambiguous. You need some parens
sometimes as in math, and math is not known to be that ambiguous.

And we have rules, once again as in math (and generally speaking we
have the same rules, even if we use them in a generalised
manner). This is a good property. The drawback is that you must learn
them; once again as in math.

Considering the difficulties of apprentices, some pedagogical theories
of mathematics once proposed to adopt completely unambiguous (read
absolutely redundant if you want) notations or encodings for algebraic
expressions in mathematics (reverse polish or lisp like parentheses
for operators). This was a complete failure. It happens to be not only
less readable than the usual notation but even much more difficult to
teach, use, and learn!

So, as you know, we have to be careful about those syntax changes: the
best could be worse that the good (as we say in french).

In any way, claiming the Caml syntax is this or that is just useless
and a waste of time. More interesting is to state problems that have
to be solved and axioms (or rules) you want to respect. That's what is
interesting in the revised syntax. Believe it or not, I am glad to see
that it elegantly realizes some of those rules I definitely would like
to have in the syntax of the language; on the other hand it
consistantly violate other of my personal axioms about the syntaxes I
like. It is truly difficult to design a good syntax!

So, what I am interested in is to set up a list of rules to guide the
design of a syntax. This is hard, but interesting and could lead to a
syntax easy to learn and use. This would be constructive and new.

Best regards,

Pierre Weis

INRIA, Projet Cristal, Pierre.Weis@inria.fr, http://pauillac.inria.fr/~weis/


-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Camlp4/OCaml [was: Generating C stubs]

[Dave Mason]

Although OCaml is probably my favourite language, I get to program in
Java a fair bit (and Scheme a little, but there the syntax is nice and
regular!).

The only syntax error I commonly make in OCaml is that I usually
forget to put parens around the exception and its arguments to a raise
function.  And the problem is exactly that... the raise FUNCTION.
try...with is syntactic, so why shouldn't raise be a statement instead
of a function?  And it wouldn't break many programs (except for a few
unit tests written with FORT).

Then I'd never make any errors in OCaml.  :-)

(In truth, these errors are maybe 10-15% of the type errors I get from
OCaml compilations.  And 90% of the `syntax' errors.)

And if we were looking for things to include in the standard OCaml
distribution, I would nominate FORT.  Unit testing is very important,
and perhaps we could create a culture that regularly shipped unit-test
with their code (as Java is making progress toward).

../Dave
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Camlp4/OCaml [was: Generating C stubs]

[Pierre Weis]

> Although OCaml is probably my favourite language, I get to program in
> Java a fair bit (and Scheme a little, but there the syntax is nice and
> regular!).
> 
> The only syntax error I commonly make in OCaml is that I usually
> forget to put parens around the exception and its arguments to a raise
> function.  And the problem is exactly that... the raise FUNCTION.
> try...with is syntactic, so why shouldn't raise be a statement instead
> of a function?  And it wouldn't break many programs (except for a few
> unit tests written with FORT).
> Then I'd never make any errors in OCaml.  :-)
> 
> (In truth, these errors are maybe 10-15% of the type errors I get from
> OCaml compilations.  And 90% of the `syntax' errors.)

You are right. Raise was a keyword in Caml for 10 years, just for the
syntactic reasons you mentioned.

With Caml Light, simplicity was the rule (remember that we managed to
run on a 640 ko PC!). So that raise was turn into a primitive function
for sake of simplicity. Afterwards, Objective Caml inherits (:-) that
property of raise.

In 2002, it may be the time to turn raise into a keyword again to
give our beginners and users a more confortable and natural system.

> And if we were looking for things to include in the standard OCaml
> distribution, I would nominate FORT.  Unit testing is very important,
> and perhaps we could create a culture that regularly shipped unit-test
> with their code (as Java is making progress toward).
> 
> ../Dave

I also agree completely with you on the unvaluable importance of
program testing (and also program proving, but this much more
difficult). We plan to write a test generator for Caml
programs. Maxence Guesdon who has industrial experience on testing
volonteers on that project.

Best regards,

Pierre Weis

INRIA, Projet Cristal, Pierre.Weis@inria.fr, http://pauillac.inria.fr/~weis/


-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Camlp4/OCaml [was: Generating C stubs]

[Diego Olivier Fernandez Pons]

    Bonjour,

Je voulais seulement contribuer avec quelques exemples d'erreurs
auxquelles je me suis confronté et dont l'origine était une mauvaise
compréhension (de ma part) de la syntaxe de Caml.

la première concerne les séquences

val start : int
val coeff : int
val name : string option

method current_state = function () ->
  ["name : " ^ match name with None -> "unknown name" | Some n -> n ;
   "coeff : " ^ string_of_int coeff ;
   "start : " ^ string_of_int start ]

ce qui donne lorsqu'on compile

Warning: this expression should have type unit
method current_state : unit -> string list

En effet, la séquence lie plus fortement que le séparateur d'éléments
dans une liste. Il suffit bien sûr - après avoir réfléchi un bon
moment - de mettre des parenthèses (mieux encore, d'évaluer le nom au
préalable et de concatener avec une constante ensuite)

A ce stade là on peste (quelques instants mais sans rancoeur réelle)
contre Caml pour avoir la mauvaise idée d'utiliser le point virgule
comme séparateur des listes plutôt que la très traditionnelle virgule.

Mais une autre erreur que j'ai commise plus d'une fois m'indique
immédiatement pourquoi c'est le cas :

[1, 2, 3] s'évalue en (int * int * int) list = [(1, 2, 3)]

car x, y est considérée comme une paire, d'où l'autre erreur qui m'a
perturbé pendant un certain temps

type term =
  | Constant of string * int
  | Variable of string
  | Apply of term * term list

let unify_terms env = function term1 term2 ->
  match (term1, term2) with
  | (Constant x, Constant y) -> (x = y, env)
  | (Variable x, Variable y) when x = y -> (true, env)
  | (Variable x, Variable y) -> (true, (x, Variable y) :: env)
  | (const, Variable _ as var) -> unify_terms env var const
etc.

This expression has type term * term but is here used with type term

C'est encore un problème de parenthèses, il faut s'habituer au fait
que x, y as value et (x, y) as value s'évaluent de la même façon.

        Diego Olivier
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Camlp4/OCaml [was: Generating C stubs]

[Markus Mottl]

Dear Pierre,

On Fri, 17 May 2002, Pierre Weis wrote:
> Hence, (to me) there is no question about the fact that semantics (hence
> syntax) is of primordial importance. So that we have to improve the
> syntax of the language if we can. But we cannot say that the regular
> syntax is EXTREMELY ambiguous (with upper case letters and the like). Be
> quite, please! It is not ambiguous. You need some parens sometimes as
> in math, and math is not known to be that ambiguous.

I am not sure whether you, as one of the language designers, felt offended
by my use of an _emphasis_. If yes, it seems to be a misunderstanding,
because I just wanted to point out the fact that "there _are_ problems"
rather than that there was anything extremely ambiguous about OCaml, which
would certainly be unjustified criticism. The problems are comparatively
minor, but they do exist and therefore shouldn't be brushed under the
carpet but (IMHO) solved at some point in the future. That's all I wanted
to say.

> Considering the difficulties of apprentices, some pedagogical theories
> of mathematics once proposed to adopt completely unambiguous (read
> absolutely redundant if you want) notations or encodings for algebraic
> expressions in mathematics (reverse polish or lisp like parentheses
> for operators). This was a complete failure. It happens to be not only
> less readable than the usual notation but even much more difficult to
> teach, use, and learn!

I wouldn't say that e.g. RPN were "absolutely redundant". In fact, I
think the reason why it wasn't so successful is exactly because it isn't
redundant: humans just need some redundant syntactic hints to parse
texts more efficiently. In the case of RPN it is actually impossible
to interpret or correctly modify only a part of an expression without
having parsed it from the beginning. This makes both understanding and
editing very difficult.

Just to give an example, I like the fact that the following is
syntactically redundant in OCaml:

  let f = function X -> () | Y -> ()

and

  let f = function | X -> () | Y -> ()

This way I can more easily choose whether I want to put the whole code in
one line or each match in a separate one. Without allowing a preceding
"|" in the first line of a match it would be annoying to add matches at
the beginning or move the first one elsewhere.

OTOH, I really dislike the lack of distinction between constructors with
tuple arguments and several arguments (as Brian has also mentioned).

Or the following irregularity:

  try ()
  with Exit -> print_string "Hello "; print_endline "world!";
  print_endline "DONE"

and

  if false then print_string "Hello "; print_endline "world!";
  print_endline "DONE"

The catch here is that users can accidently write suggestive code,
which makes people believe that "DONE" will be printed in any case as
in the "try/with"-example or that "world!" would be printed only if the
condition were true in the "if/then/else" example.

A simple-minded fix does not resolve all problems:

  try ()
  with Exit -> (print_string "Hello "; print_endline "world!");
  print_endline "DONE"

This will still not print "DONE"! But here the behaviour changes:

  if false then (print_string "Hello "; print_endline "world!");
  print_endline "DONE"

I think this is just confusing. IMHO, "try/with" and "if/then/else" should
really syntactically force users to explicitly express what they mean. To
prevent myself from falling into such traps I have adopted the strategy
to never use ";" in code parts that are executed conditionally: I use
"let _ = ... in" instead, which doesn't look particularly beautiful, but
which I can still parse successfully even when being in brain-dead mode.

The upper case is particularly bad, because the compiler cannot help you.
But there are similar ones that are annoying, but are at least caught
at compile time, e.g.:

  match v1 with
  | A ->
      match v2 with
      | X -> ()
      | Y -> ()
  | B -> ()

Then there is this question of when to use ";;", which all beginners
wonder about...

> In any way, claiming the Caml syntax is this or that is just useless
> and a waste of time. More interesting is to state problems that have
> to be solved and axioms (or rules) you want to respect.

People are certainly willing to discuss details of syntactic aspects
they find confusing. AFAIK, it's almost always the same kind of problems.

> That's what is interesting in the revised syntax. Believe it or not,
> I am glad to see that it elegantly realizes some of those rules I
> definitely would like to have in the syntax of the language; on the
> other hand it consistantly violate other of my personal axioms about
> the syntaxes I like. It is truly difficult to design a good syntax!

I certainly agree that designing a good syntax is quite challeninging.
Another reason why we should think about it - who doesn't like being
challenged :-)

> So, what I am interested in is to set up a list of rules to guide the
> design of a syntax. This is hard, but interesting and could lead to a
> syntax easy to learn and use. This would be constructive and new.

What I consider at least as important is how to introduce syntactic
changes into a language without driving users mad.  This gets us back
to the topic of having camlp4 in the distribution or not. I think that
irrespective of the syntactic rules the community can finally agree on,
a tool like camlp4 would be very welcome to support a transition.

Best regards,
Markus Mottl

-- 
Markus Mottl                                             markus@oefai.at
Austrian Research Institute
for Artificial Intelligence                  http://www.oefai.at/~markus
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Camlp4/OCaml [was: Generating C stubs]

[james woodyatt]

On Sunday, May 19, 2002, at 04:31 AM, Markus Mottl wrote:
> [...]
> What I consider at least as important is how to introduce syntactic
> changes into a language without driving users mad.  This gets us back
> to the topic of having camlp4 in the distribution or not. I think that
> irrespective of the syntactic rules the community can finally agree on,
> a tool like camlp4 would be very welcome to support a transition.

I'd like to go on record as agreeing with what Markus wrote about syntax 
issues in Ocaml in the message excerpted above.  In addition, the 
paragraph I chose to quote represents an opinion that I, too, hold quite 
strongly.


--
j h woodyatt <jhw@wetware.com>
"The plainest print cannot be read through a solid gold sovereign,
or a ruble, or a golden eagle." --sam cummings, famous arms dealer

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

[Caml-list] Tail recursion detection

[John Max Skaller]

I'm in the process of writing a tail recursion detector for 
Felix, and many of the routines are tail recursive (heh!).
However, in a few places, there are multi-way branches
each of which terminate in identical tail calls:

let rec f x y = match .. with
   | .. -> 
      if .. then 
      if .. then
      if .. then
	f x' y'
      else f x' y'
      else f x' y'
      else f x' y'
..

My question is: how smart is the Ocaml tail call detector?
Can I optimise the above code like:

let rec f x y = 
  let tail () = f x y in
   if .. then
   if .. then
   if then tail()
   else tail()
   else tail()
   else tail()


for example? [More likely, the 'tail' function will
fix arguments which are commonly invariant ..]

[If tail detection is done after inlining,
and the tail() calls are inlined, the tail calls
should be detected even if the tail call detector
is fairly dumb. In that case, how can I be sure
to inline tail() calls?]

-- 
John Max Skaller, mailto:skaller@ozemail.com.au
snail:10/1 Toxteth Rd, Glebe, NSW 2037, Australia.
voice:61-2-9660-0850




-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Tail recursion detection

[Alain Frisch]

On Mon, 20 May 2002, John Max Skaller wrote:

> I'm in the process of writing a tail recursion detector for
> Felix, and many of the routines are tail recursive (heh!).
> However, in a few places, there are multi-way branches
> each of which terminate in identical tail calls:
>
> let rec f x y = match .. with
>    | .. ->
>       if .. then
>       if .. then
>       if .. then
> 	f x' y'
>       else f x' y'
>       else f x' y'
>       else f x' y'
> ..


These would be tail calls even with different x' and y' ...

> My question is: how smart is the Ocaml tail call detector?

As far as I can tell, the detection is quite easy: just replace
during (some kind of intermediate) code generation any call followed
by a return with a tail call (after replacing any jump to a return
with the return). This is enough to detect tail call in your example.
Have a look at the OCaml bytecode generator, it is easy enough to get the
idea.


Does this answer your question ?

-- Alain

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Tail recursion detection

[Benedikt Grundmann]

At 09:46 21.05.02 +0200, Alain Frisch wrote:
>On Mon, 20 May 2002, John Max Skaller wrote:

Maybe you want to have a look at scheme's r5rs (revised ... revised report 
... scheme).   After reading the section on tail calls it's obvious that 
they can be detected by simple pattern matching on the syntax.


Good luck,

Bene

> > I'm in the process of writing a tail recursion detector for
> > Felix, and many of the routines are tail recursive (heh!).
> > However, in a few places, there are multi-way branches
> > each of which terminate in identical tail calls:
> >
> > let rec f x y = match .. with
> >    | .. ->
> >       if .. then
> >       if .. then
> >       if .. then
> >       f x' y'
> >       else f x' y'
> >       else f x' y'
> >       else f x' y'
> > ..
>
>
>These would be tail calls even with different x' and y' ...
>
> > My question is: how smart is the Ocaml tail call detector?
>
>As far as I can tell, the detection is quite easy: just replace
>during (some kind of intermediate) code generation any call followed
>by a return with a tail call (after replacing any jump to a return
>with the return). This is enough to detect tail call in your example.
>Have a look at the OCaml bytecode generator, it is easy enough to get the
>idea.
>
>
>Does this answer your question ?
>
>-- Alain
>
>-------------------
>To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
>Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
>Beginner's list: http://groups.yahoo.com/group/ocaml_beginners


-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Tail recursion detection

[John Max Skaller]

Alain Frisch wrote:

>>My question is: how smart is the Ocaml tail call detector?
>>
>
>As far as I can tell, the detection is quite easy
>
>Does this answer your question ?
>
Well, I was hoping for a definitive answer:  

Perhaps I'm confused, but ..
The problem isn't replacing calls with jumps,
but identifying which closure to reuse. In general,
that is impossible without dataflow analysis.

For example (ignore impossible typing here please)

    let rec f g x = g g x in  f f x

Obviously, the call 'g g x' is at the tail,
but to do a tail call, one must avoid construction
a new closure of f with its argument, and just store the argument
in the slot used by the previous one.  To do that, you
have to know that the function being applied is actually f.
Clearly this is impossible in this example until
you see the 'f f x' after the 'in' keyword.

In Felix, this problem is nasty. Consider recursive
procedure calls. Naturally, to avoid an infinite recursion,
such a call is going to be one branch of a conditional.
My problem is the recommended technique for doing
this is like:

    proc f(x:int) {
         if x == 0 then { print "end"; }
        else { f(x-1); }
        endif;
    }

which is equivalent to

    proc f(x:int) {
        proc z() { print "end"; }
        proc nz() { f(x-1); }
        val  g = if x ==0 then z else nz endif;
        g ();
    }

and now you see it it is not at all obvious without dataflow
analysis how to make this all work with only one storage
location for 'x'. The f called in 'nz' cannot be tail called
without analysing all of f, since just examining nz will
not tell you if, after it returns, the old x is still required.
On the other hand, g() can't be tail called either,
without looking inside z and nz, which itself requires
determining the how the value of g arose.


-- 
John Max Skaller, mailto:skaller@ozemail.com.au
snail:10/1 Toxteth Rd, Glebe, NSW 2037, Australia.
voice:61-2-9660-0850




-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Tail recursion detection

[Noel Welsh]

I think you're confusing tail calls with closure
conversion.  Closure conversion determines which
closures can stack allocated, done away with, or must
be heap allocated.  There are simple ways and complex
way to do this. Some references:

Orbit, Kranz et al

'Control Flow Analysis: A compilation paradigm for
functional langauge' Manuel Serrano

'Flow-directed Lighweight Closure Conversion' by the
guy who does the Stalin scheme compiler

'Lightweight Closure Conversion' Paul Steckler and
Mitchell Wand.

Google or CiteSeer with find the above and a zillion
more.

HTH,
Noel

--- John Max Skaller <skaller@ozemail.com.au> wrote:
> Perhaps I'm confused, but ..
> The problem isn't replacing calls with jumps,
> but identifying which closure to reuse. In general,
> that is impossible without dataflow analysis.



__________________________________________________
Do You Yahoo!?
LAUNCH - Your Yahoo! Music Experience
http://launch.yahoo.com
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Tail recursion detection

[John Max Skaller]

Noel Welsh wrote:

>I think you're confusing tail calls with closure
>conversion. 
>
Yes. Seems to me that there's no point detecting
tail calls if you don't achieve constant storage overhead,
so I identified the two concepts. Sorry, my mistake.

>Closure conversion determines which
>closures can stack allocated, done away with, or must
>be heap allocated.  There are simple ways and complex
>way to do this. 
>
Yes. What I need is something that will "undo" some of
my syntactic sugaring. If it is too hard, I will be forced
to complicate the compiler by adding extra terms to retain
the required information (which is don't like much,
since I just eliminated them .. :)

Thanks for the references!

-- 
John Max Skaller, mailto:skaller@ozemail.com.au
snail:10/1 Toxteth Rd, Glebe, NSW 2037, Australia.
voice:61-2-9660-0850




-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Tail recursion detection

[Noel Welsh]

Tail calls are a syntactic property of the language
hence there should be no need for a tail recursion
detector beyond a trivial syntactic analysis.  I.e. it
should get 'em all.

E.g. Page 329 of 'Modern Compiler Implementation in
ML'

... the B_i are in tail contexts, but the C_i are not:

 ...
3. if C_1 then B_1 else B_2
 ...

Noel

--- John Max Skaller <skaller@ozemail.com.au> wrote:
> I'm in the process of writing a tail recursion
> detector for 
> Felix...
> 
> My question is: how smart is the Ocaml tail call
> detector?
> Can I optimise the above code like:


__________________________________________________
Do You Yahoo!?
LAUNCH - Your Yahoo! Music Experience
http://launch.yahoo.com
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Camlp4/OCaml [was: Generating C stubs]

[Alessandro Baretta]

Pierre Weis wrote:
>>FAIW, let me say I'm shedding blood to make my code compile 
>>when I raise exceptions that have non banal type lists: I 
>>always misplace my parentheses.
> 
> 
> Have you ever read the programming guidelines that explain the
> ``secrets'' of Caml parentheses ?
> 
> http://pauillac.inria.fr/caml/FAQ/pgl-eng.html
> 
> Section IV: When to use parentheses within an expression
> 
> If you learn the rules, if you follow those guidelines, and still
> experience problems, please let me know, since I used those simple
> principles for years with thousands of students (I really mean several
> thousands students not several students) and they had no problems once
> they had understood and learned those rules.

Thanks for mentioning them. All the documentation I have on 
Ocaml now is the "official" html manual, but the syntax part 
is not human-readable. I was never actually taught Ocaml, 
but rather I learned it (if I ever did) by writing code and 
trying to get it to compile. I never had problems figuring 
out the meaning and usage of type lists in constructors, 
with the sole exception of exceptions. Somehow, they have 
always escaped my inductive learning ability. I'll try 
reading the guidelines.

> On the other hand, I agree with you that if you don't know the rules
> for parens in Caml, you certainly should have problems to write your
> programs. This is the same problems as the one of young people at
> school that use to claim that mathematics _HAVE_ (*) syntactic
> problems because they never know where to put parens in

I have absolutely no authority to criticize the syntax; I 
just claim that some aspects of it are not user-friendly. 
Math transcends user-friendliness. It simply is not meant to 
be used in any definite way. It just sits there, exists. (I 
once heard an algebraist wonder if category theory had any 
*real* use.) Software systems, on the other hand, must be 
used by humans in order to be worth creating, and, for this 
reason, they ought to be as intuitive as possible. I still 
have not had time to mess with CamlP4 and cannot say much 
about it, but if its syntax is more intuitive than the 
native one, then welcome CamlP4.

Regards,
Alex Baretta

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

[Caml-list] Re: Camlp4/OCaml

[Christopher Quinn]

How can camlp4 be unimportant or a waste of time!

Here are some things I find useful about it:

o conditional compilation

o ability to add command line options to switch between one's own 'safe' 
modules and their 'unsafe' versions which can only be done in the case 
of Arrays and Strings with the standard compiler.

o one can always modify one's own copy of the parser,
but that's a bother when something in the original changes, and besides, 
camlp4's extension mechanism allows a compact and manageable format.

o no matter how one redefines the syntax, just running the source 
through camlp4 can reconstruct it in the vanilla form. So no one ever 
needs to suffer another's idea of perfection!

o camlp4 seems to me to be one way to avoid the endless creation of 
mini-languages for specific tasks that end up trying to do stuff beyond 
their limited design. Better to start with the expressivity of the likes 
of caml, maybe cutting down, and augment with p4 extensions. I'm 
planning to embed some sql style DDL for my project.

o I can write code without_the_god_damn_awful_underscore character 
stressing my hands and use-an-alternative-even (though-I-am-no-fan-of-lisp)!


I felt these reasons were compelling enough to justify  switching to 
camlp4 as my default parser.

The above doubtless has no bearing on the technical arguments for not 
having camlp4 in the distribution.
I just want to say I think camlp4 is important and indispensible.

- chris

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Re: Camlp4/OCaml

[Daniel de Rauglaudre]

Hi,

On Fri, May 17, 2002 at 12:22:13AM +0100, Christopher Quinn wrote:

> How can camlp4 be unimportant or a waste of time!

Ok, I went too far a little bit: not Camlp4 has been considered as a
waste of time but the revised syntax.

People is allowed not to use it and not to love it, but it is a
proposition, it is an axis of reflexion for possible future ideas.

Mainly, it is the *core* of Camlp4: Camlp4 is completely written with
that syntax and the system of extensible grammars of Camlp4 needs for
the language a syntax with good properties, what the "normal" syntax
does not have (it "works" but with several hacks). Therefore, for me,
telling that the revised syntax is a not serious work is saying that
Camlp4 is not a serious work.

The "officially" that I said in a previous mail means that this
opinion has been told to an important user of OCaml, and that this has
not been denied by the direction of the OCaml team, since two months
(when this story happened).

I have asked for a deny, or for a solution to fix this problem, and
the only answers I got was personal attacks against me, without any
scientific argumentation, and howls where I had no way to give my
opinion.

-- 
Daniel de RAUGLAUDRE
daniel.de_rauglaudre@inria.fr
http://cristal.inria.fr/~ddr/
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Camlp4/OCaml [was: Generating C stubs]

[Daniel de Rauglaudre]

Hi,

On Fri, May 17, 2002 at 04:12:28AM +0000, Brian Rogoff wrote:

> I dread the prospect of a flamewar over this, but I think that removing
> CamlP4 from OCaml is a very bad idea, and a step backwards. Bad news to
> me, indeed...

Right. Divorce is generally a bad idea, but the solution when the
marriage have been done with a bad preparation and lies.

> I would encourage reconsidering this decision. Note that for any
> given feature beyond core ML (labels, variants, objects, higher
> order functors, ...)  I can imagine someone considering that feature
> "not serious".

No decision is definitive, I can change my mind, but I have asked for
propositions since two months, and nothing happened. Separation is the
best compromise I found. If somebody has a better solution (except
hide the problem under the carpet), I am ready to hear it.

-- 
Daniel de RAUGLAUDRE
daniel.de_rauglaudre@inria.fr
http://cristal.inria.fr/~ddr/
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

[Caml-list] Camlp4/OCaml

[Michel Mauny]

Dear all,

I'd like to stop this thread for several reasons:

  1. the *really* bad idea here is to implicate (use?) OCaml users in
     this debate where personal issues overcome technical ones;

  2. There is no such decision, official or not. Daniel's message reflects
     only his personal point of view (and current mood).

  3. Daniel, I am sorry, but you are not the one who decides what is
     official and what is not.

Daniel, if you want to reply to this message, please do it to me
personally.

OCaml users and friends, if and when this problem that we (INRIA
folks) are facing will get solved, you'll be notified if the solution
changes something in the OCaml tree and/or the development model. If
you hear nothing about that, consider it as being good news.

Sincere apologies for this noise.

Sincerely,

-- Michel Mauny, (as head of the INRIA Cristal group)

Daniel de Rauglaudre wrote/écrivait (May 16 2002, 09:44PM +0200):
> On Thu, May 16, 2002 at 03:39:45PM -0400, John Prevost wrote:
> 
> > Really?  Why did someone decide that inclusion was a bad idea?
> 
> I say it. Camlp4 and the attempts to improve the syntax have been
> considered *officially* by the OCaml team as a "not serious" work and a
> "loss of time". As I worried about that, and asked for more information,
> it has been confirmed by the team, moreover with several personnal attacks.
> 
> Sorry for this "human" problem, but I cannot create and have
> imagination in my work when I am considered like that.
> 
> Camlp4 continues and I made many changes, but in the previous CVS
> distribution, directory "camlp4", no more "ocaml/camlp4". It will
> be distributed normally just after OCaml releases and perhaps with
> intermediate releases.
> 
> -- 
> Daniel de RAUGLAUDRE
> daniel.de_rauglaudre@inria.fr
> http://cristal.inria.fr/~ddr/
> -------------------
> To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
> Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

-- 
Michel Mauny
Michel.Mauny@inria.fr
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Camlp4/OCaml

[Daniel de Rauglaudre]

On Fri, May 17, 2002 at 09:54:40AM +0200, Michel Mauny wrote:

>   3. Daniel, I am sorry, but you are not the one who decides what is
>      official and what is not.

Is official what has been told by important members of the team to
important users and not denied this day.

-- 
Daniel de RAUGLAUDRE
daniel.de_rauglaudre@inria.fr
http://cristal.inria.fr/~ddr/
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Generating C stubs

[Benedikt Grundmann]

At 11:13 15.05.02 +0200, you wrote:
>   Hi,
>
>     In order to avoid spending some time on writing C stubs
>     myself, I'd like them to be generated automaticaly.
>     There are currently 3 stub generators: camouflage, ffi
>     and another one I don't recall (IIRC, someone claimed
>     that he was working on a SWIG interface).

That was me and I'm still working on it.  I just started working on 
automatic structure wrapping.  This project (ocaml-swig) is the first time 
I started working on the core of swig which unfortunately is constantly 
changing because Dave and the others trying to improve the C++ support.  So 
I really can't tell you when a working release of the ocaml-swig module 
will be done.



-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

RE: [Caml-list] Generating C stubs

[Jeff Henrikson]

>>     and another one I don't recall (IIRC, someone claimed
>>     that he was working on a SWIG interface).
>
> That was me and I'm still working on it.  I just

No it was me!  ;-)  Actually I basically did write a SWIG
language module.  (How is it that we didn't see each others
work on the list archives?)  Anyway, after writing about
2000 lines of C code but before getting the bugs worked out,
I abandoned it.  My reasoning was:

1) SWIG is not sophisticated enough to get the behavior I
wanted easily.
2) Doing extra work to approach what I wanted was making
massive code bloat (SWIG is written in C and is not
forgiving of changing the "normal" behavior from the
language module end)
3) I hate programming in C, especially when the API has been
constructed to treat _everything_ as a void*.
4) Someone released a binding for the interfaces I needed

So that put the lid on that one for a while.  But I learned
why exactly I find it (and the IDL approach, and other FFI
systems) inadequate.  SWIG tries to be a little bit smarter
than IDL by letting you break away from the "this parameter
is [in], this parameter is [out]" level of abstraction, by
allowing some weak sorts of pattern matching.  In other
words, it can take the names of the parameters in a C header
file and say "make all int parameters named 'point' and
convert them this way.  But make all the int parameters
named 'color' and convert them this other way."   But it's
not general enough, and still makes the mistake of
annotating the header file rather than making the
annotations separate.  So when version 2.0 of your header
files come out, you start from scratch or do some silly
diff3 mucking around.

I started implementing a new header generator based on the
idea of describing the annotations as a caml program.
Basically have a bunch of convienience functions that search
through a C abstract syntax tree to ask things like this:

1) I need to use function FooOp which takes a datatype Foo*.
Read mydefs.h which contains their prototypes into the
current environment.

2) Find me all descendant types which are needed to build
the struct Foo.

3) Generate me constructor functions to build these ones
which I declare to be public members, and any of their
children.  For primitive types, convert using these C code
snippets I give you (ala SWIG typemaps).

4) Find me all functions which take a Foo* as a first
parameter.  Write C wrappers for them, caml external
declarations, and put them together as a class in an OOP
wrapper ala lablgtk.  Truncate the method names from
Foo_happyOperation to just myFoo#happyOperation by a regular
expression substitution, with exceptions which I specify by
hand.

Anyway, needless to say there's a bunch of stuff to be
worked out, but I may get back at the project soon, as I am
needing another API binding.  I really want to short circuit
the writing each function by hand as you go thing.  The
problem is that I usually work with APIs that I don't know
upfront, and want to just generate the stubs in bulk and
learn the API straight from an ML environment.  (This is one
of the areas where caml is definitely not as easy as C yet.)
I think 95% of the necessary information is already
contained in well stylized header files, we just need a way
of systematically cleaning up the last 5% into a complete
IDL level of knowledge.

Two further extensions of such a system would be to

1) produce a language independent output, in other words
write out IDL instead of C wrappers.

2) construct a language independent input, so that non-caml
programmers might be seduced.  :->

Regards,


Jeff Henrikson


-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

RE: [Caml-list] Generating C stubs

[Benedikt Grundmann]

At 12:37 16.05.02 -0400, Jeff Henrikson wrote:
> >>     and another one I don't recall (IIRC, someone claimed
> >>     that he was working on a SWIG interface).
> >
> > That was me and I'm still working on it.  I just

Well, that's interesting news :-).  Do you still have your code around 
somewhere.  If though I would glad to if I could have a look at it.  Will 
your new interface support c++ ?   That's actually the main reason why I 
started writing the swig module.


Bene

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

RE: [Caml-list] Generating C stubs

[Jeff Henrikson]

> Well, that's interesting news :-).  Do you still
> have your code around
> somewhere.  If though I would glad to if I could

I stuck it on the web for you.  Don't laugh, it's the first
thing on my new iDisk.

http://homepage.mac.com/jehenrik/

Hey, 20MB of free WebDAV mountable storage, I'm not
complaining.

Cheers,


Jeff Henrikson

PS- Mr. Grundmann, I can't send you email directly as your
server blocks things with an @yahoo.com from address.  I'm
not even using a yahoo SMTP server.  You might want to look
into it if it seems to you also as a bit too restrictive.




> -----Original Message-----
> From: Benedikt Grundmann [mailto:bgrundmann@gmx.net]
> Sent: Thursday, May 16, 2002 12:31 PM
> To: Jeff Henrikson; Jérôme Marant
> Cc: caml-list@inria.fr
> Subject: RE: [Caml-list] Generating C stubs
>
>
> At 12:37 16.05.02 -0400, Jeff Henrikson wrote:
> > >>     and another one I don't recall (IIRC,
> someone claimed
> > >>     that he was working on a SWIG interface).
> > >
> > > That was me and I'm still working on it.  I just
>
> Well, that's interesting news :-).  Do you still
> have your code around
> somewhere.  If though I would glad to if I could
> have a look at it.  Will
> your new interface support c++ ?   That's
> actually the main reason why I
> started writing the swig module.
>
>
> Bene
>

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Camlp4/OCaml [was: Generating C stubs]

[Joshua D. Guttman]

[-- Attachment #1: Type: message/rfc822, Size: 2143 bytes --]

From: guttman@mitre.org (Joshua D. Guttman)
To: Daniel de Rauglaudre <daniel.de_rauglaudre@inria.fr>
Cc: guttman@mitre.org (Joshua D. Guttman)
Subject: Re: [Caml-list] Camlp4/OCaml [was: Generating C stubs]
Date: 16 May 2002 19:21:12 -0400
Message-ID: <nhak7q38ys7.fsf@banjara.mitre.org>

Daniel de Rauglaudre <daniel.de_rauglaudre@inria.fr> writes:

>   > Really?  Why did someone decide that inclusion was a bad idea?
>   
>   I say it. Camlp4 and the attempts to improve the syntax have been
>   considered *officially* by the OCaml team as a "not serious" work and a
>   "loss of time".

I'm sorry to hear this.  It's regrettable.  Camlp4 seems so useful to
me.

        Joshua 


-- 
	Joshua D. Guttman		<guttman@mitre.org> 
	MITRE, Mail Stop S119		Office:	+1 781 271 2654
	202 Burlington Rd.		Cell:	+1 781 526 5713
	Bedford, MA 01730-1420 USA	Fax:	+1 781 271 8953





[-- Attachment #2: Type: text/plain, Size: 187 bytes --]



-- 
	Joshua D. Guttman		<guttman@mitre.org> 
	MITRE, Mail Stop S119		Office:	+1 781 271 2654
	202 Burlington Rd.		Cell:	+1 781 526 5713
	Bedford, MA 01730-1420 USA	Fax:	+1 781 271 8953