Re: [Caml-list] syntax

Re: [Caml-list] syntax

[Michael Vanier]

I've looked at the revised syntax, and I like most of what I see (except
for the use of x.val instead of !x).  One question: how many shift-reduce
conflicts does the revised syntax have?  

Mike
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

Re: [Caml-list] syntax

[Daniel de Rauglaudre]

Hi,

On Tue, Feb 05, 2002 at 01:47:31PM -0800, Michael Vanier wrote:

> I've looked at the revised syntax, and I like most of what I see (except
> for the use of x.val instead of !x).  One question: how many shift-reduce
> conflicts does the revised syntax have?  

There is no notion of shift-reduce in recursive descent parsing: the
system tries to shift until it cannot do it any more.

To decide to "reduce", you must know which non-terminal called you,
but you don't have this information, exactly like in a function, you
don't know which function called you.

To know if there are shift-reduce or reduce-reduce conflicts in the
revised syntax, one should rewrite it under yacc.

-- 
Daniel de RAUGLAUDRE
daniel.de_rauglaudre@inria.fr
http://cristal.inria.fr/~ddr/
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

Re: [Caml-list] syntax

[Achim Blumensath]

Hello,

On Tue, Feb 05, 2002 at 01:47:31PM -0800, Michael Vanier wrote:
> I've looked at the revised syntax, and I like most of what I see (except
> for the use of x.val instead of !x).

Since I also dislike the syntax for references, I wrote the following
parser extension:

open Pcaml;

EXTEND
  expr: LEVEL "~-"
  [ [ "!"; x = expr -> <:expr< $x$.val >> ] ];
END;

That way, I can write

  !x := !x + 1

which IMHO combines the benefites of both syntaxes.

Achim
-- 
________________________________________________________________________
                                                              | \_____/ |
   Achim Blumensath                                          \O/ \___/\ |
   Mathematische Grundlagen der Informatik                   =o=  \ /\ \|
   www-mgi.informatik.rwth-aachen.de/~blume                  /"\   o----|
____________________________________________________________________\___|
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

[Caml-list] Syntax

[brogoff]

On Fri, 11 Oct 2002, Kontra, Gergely wrote:
> Another thing, that
> bothers me is the do { } syntax. It seems a bit silly mixture of some
> shell and C syntax, I think either do ... done or { ... } would be a
> good choice 

Actually, more like Haskell to me. 

Originally, the syntax was 

do e1; e2; e3; return e4

and 

while e1 do e2; e3; e4 done 
for v = e1 to e2 do e3; e4 done

As noted in the tutorial, not using "done" would save a keyword. So that would 
argue for using {} or some other non-alphanum bracketing tokens, and saving "do" 
as well. 

A counterargument is that the keyword may make it more readable, as the 
imperative sections of the code stand out more, and that's probably what you 
want in an ML family language, which while, imperative, supports a functional 
programming style well. 

I think the "do {}" is fine, and better than both the OCaml syntax and the 
previous Revised one. I could be convinced that {} or the like is better, 
but only by a little if at all. 

> Ok, I know, you'll say: "Then why don't you write your own syntax?"

No, I perfectly understand that there are people who aren't keen on OCaml 
syntax but would still prefer to be in a community of programmers using the 
same syntax. And, since Revised has such a relatively small community, 
that you may feel that you may influence it's development to be more to your 
liking. 

Feel free, argue for your choices. 

-- Brian


-------------------
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] Syntax

[Diego olivier FERNANDEZ PONS]

> Bonjour
>
> [...] Utiliser Prolog, c'est se tirer une balle dans le pied au départ.
> Les industriels comme Xerox utilisent plutôt C++, mais je connais au
> moins un autre effort en Ocaml, et Aarne Ranta qui utilise Haskell
> 
> Cordialement Gérard Huet
> 

Mes affirmations au sujet de Prolog et Lisp méritaient en effet quelque
nuance... 

Aucun doute à ce sujet, les industriels utilisent C++. Même pour faire de
la programmation logique par contraintes ils utilisent du C++ d'ailleurs,
on pourra s'en convaincre avec le succès d'Ilog Solver !

Il est cependant difficile d'exiger d'un étudiant en lettres qui a dévié
vers la linguistique de manier avec brio le pointeur, l'allocation
dynamique de mémoire, les templates, l'héritage multiple, etc.  Raison
pour laquelle les universités (littéraires) ou du moins celle dans
laquelle je suis, ont entrepris d'enseigner la linguistique informatique à
force de Prolog et Lisp. 

Les références auxquelles nous sommes habitués portent des titres
semblables à "Introduction au traitement des langues naturelles en Prolog
et Lisp". A titre d'exemple, l'ouvrage de Catherine Fuchs précédemment
cité comporte après de multiples explications sur les bienfaits de Prolog
un chapitre complet sur l'analyse syntaxique descendante et ascendante
avec Prolog, le tout assorti d'exemples.

(extrait du programme de Licence de Sciences du langage)  

Programme :
- Logique et langage
- Calcul des propositions, calcul des prédicats.
- Introduction au TALN, mise à niveau, algorithmique (notions de bases),
initiation à la programmation (Langage PROLOG Syntaxe d'Edimbourg)
- Traitement automatique des langues naturelles : Initiation au Langage PERL

(extrait du programme de Maîtrise de Sciences du langage)

Logique et théorie des automates (Calcul des prédicats, automates et
machines de Turing)
· 2 heures hebdomadaires de travaux dirigés : Jacques Courcier

Algorithmique, PROLOG, représentations informatiques (Algorithmes sur les
arbres, Logique du 1er ordre et PROLOG, Représentations sémantiques et
PROLOG) 
· 2 heures hebdomadaire de travaux dirigés : Pascal Boldini

	Diego Olivier
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

Re: [Caml-list] Syntax

[Diego olivier FERNANDEZ PONS]

On Wed, 6 Feb 2002, Francisco Valverde-Albacete wrote: 

> Bonjour,
> 
> Je serais aussi extrêmement interessé par une telle librairie. 
> Malheureusement, je crois que je raterais tous les details si vous
> répondiez en français. Quand vous ferez publiques ces informations,
> pouvez-vous le faire en Anglais, svp ?
> 
> Merci d'avance
> 
>         Francisco J. Valverde
>
(J'ai opéré quelques retouches) 

I'm awfully sorry for posting in french, I only do because of my poor
english... and usually people do not care much about what I may want to
say.

Are there many persons working on computational linguistics in this list ?

I said that most of computational linguistics were made in Prolog and Lisp
because of the handly way you can use grammars in Prolog and the list
facilities in Lisp.

Actually, I believe Caml could be an excellent substitute for this two
languages in computational linguistics since it not has only list and
symbolic facilities but a lot of other useful features and librairies.  I
suppose Gerard Huet must agree, otherwise would not be developing in Caml,
would he ? 

It could be very interesting to know which languages you have been working
with, which features you find the most important and would like to see in
a linguistic library.

	Diego Olivier
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

Re: [Caml-list] Syntax

[Diego olivier FERNANDEZ PONS]

J'avais en effet lu que le développement de modules linguistique en Caml
était prévu, et je crois me souvenir qu'il y était question de Sanskrit.

Si j'ai bonne mémoire par ailleurs, la plupart des logiciels de
manipulation linguistique écrits jusqu'à présent l'ont été en Prolog
(éventuellement en Lisp). Les linguistes estimant que les systèmes de
réécriture sont ceux qui modélisent le mieux la syntaxe de la langue
naturelle : 

P -> SN SV
SN -> art N
SV -> V SN
V -> écrit | regarde
N -> linguiste | grammaire
art -> le | la

(extrait de "Linguistique et traitements automatique des langues" 
Catherine Fuchs et alii - livre d'introduction pour le grand public) 

Leurs grammaires ne sont pas toujours algébriques (ie non contextuelles)
mais ils se débrouillent avec quelques manipulations locales pour ce
ramener à cette classe.

Dans quelle mesure pensez-vous que votre plateforme linguistique puisse
être réutilisée pour quelques petites applications simples en compilation
? Pourriez-vous donner une idée sommaire des fonctionnalités prévues ?

	Cordialement, 
		
		Diego Olivier
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

Re: [Caml-list] Syntax

[Jean-Francois Monin]

> I shall have a look at otags, which, being built
> with camlp4 support, ought to be parametrizable (?).

Sure, use option -pa :

$ otags -help
Available commands:
  [...
  -pa <str>      add camlp4 parser (default: pa_o.cmo; pa_op.cmo)

Jean-Francois
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

Re: [Caml-list] Syntax

[Markus Mottl]

On Tue, 05 Feb 2002, Gerard Huet wrote:
> Until recently there was no point in pushing the revised syntax, because it 
> was very hard to teach the language when the system's printer used another 
> syntax than what you typed in. Now that there is smooth integration of 
> camlp4 with ocaml with the 3.04, there is no excuse not to use the much 
> superior revised syntax, in my opinion. Which does not mean that there 
> should be a big concerted effort to switch all our code from one syntax to 
> the next. 

The merging of camlp4 into the standard distribution and its integration
with the toplevel was definitely an important step. I also don't think
that there should be a "big concerted effort", but it might be a good
idea to provide for a "travel plan". Maybe something in the spirit of
the introduction of the Euro, e.g. "We are considering making revised
(or whatever) syntax the default on 01.01.2004." ;)

This would give people an incentive to start new projects in the new
syntax. Surely, it may be necessary to clean up revised syntax before,
too, to make it really shine.

> The crucial point is that we need good tutorials, reference manuals, and
> books in the revised syntax before being serious about "standardizing"
> in something else than the usual syntax. Once this material exists,
> then we can talk.

I agree that this is an absolutely necessary prerequisite. Pushing people
into the cold water without previous preperation will not make them happy.

> I suggest this syntax problem should be seriously considered, but as
> a long-term effort, encompassing development tools and documentation
> and training material. This is not a battle that can be won by one
> round of email flame.

Definitely. I somehow had the impression that the topic of discussion was
being pushed into the direction of "Let's change syntax now (or not).",
which was never my intention. I was merely asking for a plan concerning
future and possibly major syntax changes. The language maintainers would
be surely well-advised to consider this in the long-term.

Regards,
Markus Mottl

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

[Caml-list] Syntax

[Gerard Huet]

At 13:05 05/02/02 +0100, Daniel de Rauglaudre wrote: 
>Hi, 
> 
>On Tue, Feb 05, 2002 at 12:53:39PM +0100, Remi VANICAT wrote: 
> 
>> So the fact that a library or a tool is written in revised or 
>> standard library doesn't change anything for those who use it. The 
>> only problem is for those who want to change the source, but it's 
>> not so hard to learn this syntax if you want to use it. 
> 
>Exactly.
Yessir. 
It is trivial to switch to revised syntax. It will take you one week to 
get used to True/False vs true/false, to use square brackets in [x :: l], 
and to write (list int) instead of (int list). I never missed the double 
semicolon, and many problems will ill-parenthesised matches just went into 
oblivion. What I missed most is that you can't anymore step through the 
toplevel with mouse cut-and-paste, because the inner let's are not accepted 
at toplevel, you have to write the godamn "value" keyword instead.
Until recently there was no point in pushing the revised syntax, because it 
was very hard to teach the language when the system's printer used another 
syntax than what you typed in. Now that there is smooth integration of 
camlp4 with ocaml with the 3.04, there is no excuse not to use the much 
superior revised syntax, in my opinion. Which does not mean that there 
should be a big concerted effort to switch all our code from one syntax to 
the next. 
I am currently developing a computational linguistics platform in ocaml, now
around 12000 loc in about 50 modules, mostly in revised syntax, some others 
borrowed from other sources or mechanically produced and still in vanila 
syntax, so what. The makefile does what is needed, and I never have any 
problem reading other people's programs from libraries or the hump, etc. 

The crucial point is that we need good tutorials, reference manuals, and
books 
in the revised syntax before being serious about "standardizing" in something 
else than the usual syntax. Once this material exists, then we can talk. 

Let me tell you about an experience I did recently, in using Ocaml as a 
publication language. In the first version of my paper, I said "we shall 
use as algorithmic meta-language OCaml under so-called revised syntax". 
Now one referee got very interested in the code, tried it on his machine
with ocaml 3.02, missed my remark about revised syntax, and said "it is too
bad these are not real programs which people can directly use". Another
referee got completely turned off by the code and said "remove all
proselytism about this weird Ocaml stuff, and use some pidgin algorithmic
language". Typical dilemna. 

What I ended up was writing a short presentation of an algorithmic 
meta-language which I called "Pidgin ML", without any proselytism about 
existing programming languages; it is only in the evaluation part of the 
paper that I reveal that Pidgin ML can be compiled and executed as such by
OCaml+Camlp4. So everybody is happy !

Just as a short plug for revised syntax, here is my introduction:
____________________________________

We shall use as {\sl meta language} for the description of our algorithms 
a pidgin version of the functional language ML. Readers familiar with ML 
may skip this section, which gives a crash overview of its syntax and 
semantics.

The core language has types, values, and exceptions. 
Thus, \verb:1: is a value of predefined type \verb:int:, whereas 
\verb:"CL": is a \verb:string:. 
Pairs of values inhabit the corresponding product type. Thus: 
\verb|(1,"CL") : (nat * string)|. 
Recursive type declarations create new types, 
whose values are inductively built from the associated constructors. 
Thus the Boolean type could be declared as a sum by: 
\verb:type bool = [True | False];:\\ 
Parametric types give rise to polymorphism. 
Thus if \verb:x: is of type \verb:t: and \verb:l: is of type 
\verb:(list t):, we construct the list adding \verb:x: to \verb:l: 
as \verb|[x :: l]|. The empty list is \verb:[]:, of (polymorphic) type 
\verb:(list 'a):. Although the language is strongly typed, explicit type 
specification is rarely needed from the designer, since principal types 
may be inferred mechanically.

The language is functional in the sense that functions are first class 
objects. Thus the doubling integer function may be written as 
\verb:fun x -> x+x:, and it has type \verb:int -> int:. It may be associated 
to the name \verb:double: by declaring: \verb:value double = fun x -> x+x;:\\ 
Equivalently we could write: \verb:value double x = x+x;:\\ 
Its application to value \verb:n: is written as \verb:(double n): or even 
\verb:double n: when there is no ambiguity. Application associates to the 
left, and thus \verb:f x y: stands for \verb:((f x) y):. 
Recursive functional values are declared with the keyword \verb:rec:. 
Thus we may define the factorial function as:\\ 
\verb:value rec fact n = n*(fact (n-1));:\\ 
Functions may be defined by pattern matching. Thus the first projection of 
pairs could be defined by:\\ 
\verb:value fst = fun [ (x,y) -> x ];:\\ 
or equivalently (since there is only one pattern in this case) by:\\ 
\verb:value fst (x,y) = x;:\\ 
Pattern-matching is also usable in \verb:match: expressions which generalise 
case analysis, 
such as: \verb:match l with [ [] -> True | _ -> False ]:, which 
tests whether list \verb:l: is empty, using underscore as catch-all 
pattern.

Evaluation is strict, which means that \verb:x: is evaluated before 
\verb:f: in the evaluation of \verb:(f x):. The \verb:let: expressions 
permit to sequentialise computation, and to share sub-computations. Thus 
\verb:let x = fact 10 in x+x: will compute \verb:fact 10: first, 
and only once. 
An equivalent postfix \verb:where: notation may be used as well. Thus 
the conditional expression \verb:if b then e1 else e2: is equivalent to: 
\verb:choose b where choose = fun [ True -> e1 | False -> e2]:.

Exceptions are declared with the type of their parameters, like in: 
\verb:exception Failure of string;:
An exceptional value may be raised, like in: 
\verb:raise (Failure "div 0"): and handled by a \verb:try: switching on 
exception patterns, such as:
\verb:try expression with [ Failure s -> ... ]:.
Other imperative constructs may be used, such as 
references, mutable arrays, while loops and I/O commands, 
but we shall seldom need them. Sequences of instructions are 
evaluated in left to right regime in \verb:do: expressions, such as: 
\verb:do {e1; ... en}:. 

ML is a {\sl modular} language, in the sense that sequences of type, value 
and exception declarations may be packed in a structural unit called a 
\verb:module:, amenable to separate treatment. 
Modules have types themselves, called {\sl signatures}. Parametric 
modules are called {\sl functors}. The algorithms presented in this paper 
will use in essential ways 
this modularity structure, but the syntax ought to be self-evident.

Readers uninterested in computational details may think of ML 
definitions as recursive equations over inductively defined algebras. Most 
of them are simple primitive recursive functionals. 
___________________________________________________
At this point, note that Pidgin ML has no objects (not even records!) nor
labels.

And later on I spill the beans:
Pidgin ML definitions may actually be directly executed as Objective Caml 
programs \cite{ocaml}, under the so-called revised syntax \cite{camlp4}. 

>> By the way, is there any caml-mode for Emacs and the revised syntax ? 
> 
>I don't think so but there is a request for that (Gérard Huet asked 
>me yesterday). I use a very old caml-light-or-what emacs mode and I 
>am too lazy to look at emacs-lisp to create my mode.

This is an important point. I myself use a slighly hacked version of Tuareg 
as an interim solution. I shall have a look at otags, which, being built 
with camlp4 support, ought to be parametrizable (?).

I suggest this syntax problem should be seriously considered, but as a 
long-term effort, encompassing development tools and documentation and 
training material. This is not a battle that can be won by one round of 
email flame.

Gerard


-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr