Comment author: administrator

Salut,

On Thu, Feb 07, 2002 at 01:24:51AM +0100, garrigue@kurims.kyoto-u.ac.jp wrote:

Un petit grep Clflags sur parser.mly montre que -unsafe est la seule
option qui influence le parsing. Cette approche n'est pas tres jolie
en soi, mais simplifie pas mal le code.

Moi je pense qu'il faudrait deux nouveaux noeuds d'arbre de syntaxe:
"array access" et "string access". Car -unsafe est un problème de
génération de code, pas de parsing. Ça serait si compliqué à traiter
au typage et à la génération de code?

Si la seule option concernee est -unsafe, pourquoi ne pas juste
emettre un warning quand on utilise simultanement -unsafe et un
preprocesseur qui rend un arbre de syntaxe ?

Effectivement, on pourrait aussi faire ça. C'est un peu bizarre mais
ça a pourtant une certaine logique.

--
Daniel de RAUGLAUDRE
daniel.de_rauglaudre@inria.fr
http://cristal.inria.fr/~ddr/

Comment author: administrator

Bonjour,

Moi je pense qu'il faudrait deux nouveaux noeuds d'arbre de syntaxe:
"array access" et "string access". Car -unsafe est un problème de
génération de code, pas de parsing. Ça serait si compliqué à traiter
au typage et à la génération de code?

Absolument d'accord avec toi. Le plus propre est évidemment deux noeuds de
syntaxe abstraite comme il est naturel en Caml. Le reste me semblerait
trop rustine!

Amicalement,

Pierre Weis

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

Comment author: administrator

From: Francois.Pottier@inria.fr

Il faut écrire, pour qu'elle soit prise en compte,

ocamlopt -pp "camlp4o -unsafe" toto.ml

Ça me paraît relativement subtil. N'est-il pas possible que
ocamlopt attrape les options qui affectent le parsing et les
passe automatiquement au préprocesseur (s'il y en a un) de
façon à ce que les deux commandes ci-dessus aient le même
effet?

Un petit grep Clflags sur parser.mly montre que -unsafe est la seule
option qui influence le parsing. Cette approche n'est pas tres jolie
en soit, mais simplifie pas mal le code. Sinon il faudrait introduite
de nouveaux identificateurs au parsing (Array.get ne convient pas,
puiqu'il faut disting .(i) (depend de -unsafe) de Array.get (ne doit
pas dependre de -unsafe), et les traiter au moment du typage.

Pour parler comme Maxence, ca m'embeterait puisque l'arbre de syntaxe
se mettrait a` contenir des identificateurs inexistants!

Si la seule option concernee est -unsafe, pourquoi ne pas juste
emettre un warning quand on utilise simultanement -unsafe et un
preprocesseur qui rend un arbre de syntaxe ?

Jacques

Comment author: administrator

Salut,

On Thu, Feb 07, 2002 at 05:18:19PM +0900, Jacques Garrigue wrote:

Complique', non. Mais intrinsequement, c'est un hack, et il se trouve
que le parsing est l'endroit ou il s'introduit le plus facilement. Ceci dit on peut toujours le retarder jusqu'au typage, mais dans ce cas la je prefererai n'avoir qu'un seul noeud supplementaire:
Pexp_access(Module, operation).

Il n'y a pas à indiquer de module dans l'arbre de syntaxe: le noeud
doit être Exp_arrayget of expression * expression, et pour vérifier
les types, c'est trivial ('a array et int, résultat 'a), et seul le
générateur de code doit s'occuper de quels modules il s'agit
(Array.get ou Array.unsafe_get) en fonction de l'option -unsafe ou
pas.

--
Daniel de RAUGLAUDRE
daniel.de_rauglaudre@inria.fr
http://cristal.inria.fr/~ddr/

Comment author: administrator

On Thu, Feb 07, 2002 at 10:12:41AM +0100, garrigue@kurims.kyoto-u.ac.jp wrote:

Il y a aussi unsafe_set, donc ca ferait 4 operations.
Ajouter 4 cas supplementaires au verifieur, et peut-etre 8 de plus le
jour ou` il y aura des Bigarray.unsafe, ne me parait pas tres propre.

Et alors? Faut ce qu'il faut.

À la limite, on peut imaginer
Exp_access of access_kind * expression * expression
type access_kind = Array | String | ...

Si la notion existe, il faut la représenter.

Dans mon arbre moi j'utilise un "array access", un "string access",
un "record access" et un (seul) "assign" pour le "<-": il n'y a pas de
"array set", qui est simplement un "assign (array access, expr)".

Donc, moi je dirais même de supprimer le Pexp_setfield et le remplacer
par Pexp_setmutable ou un truc dans ce genre et le typeur se débrouillerait
en pattern matchant ce qu'il faut.

--
Daniel de RAUGLAUDRE
daniel.de_rauglaudre@inria.fr
http://cristal.inria.fr/~ddr/

Comment author: administrator

Un petit grep Clflags sur parser.mly montre que -unsafe est la seule
option qui influence le parsing. Cette approche n'est pas tres jolie
en soi, mais simplifie pas mal le code.

Moi je pense qu'il faudrait deux nouveaux noeuds d'arbre de syntaxe:
"array access" et "string access". Car -unsafe est un problème de
génération de code, pas de parsing. Ça serait si compliqué à traiter
au typage et à la génération de code?

Complique', non. Mais intrinsequement, c'est un hack, et il se trouve
que le parsing est l'endroit ou il s'introduit le plus facilement. Ceci dit on peut toujours le retarder jusqu'au typage, mais dans ce cas la je prefererai n'avoir qu'un seul noeud supplementaire:
Pexp_access(Module, operation). Comme ca ca reste facile a` traiter au
moment du typage (essentiellement en regenerant apres-coup un noeud
Pexp_ident (Module.unsafe_operation)). Sinon on a besoin de savoir
dans le typeur explicitement quelles sont les operations qui peuvent
etre unsafe, ce qui devient lourd.

Le repousser jusqu'a la generation oblige a le traiter specialement
a` toutes les etapes intermediaires, ce qui ne simplifie guere.

Ou alors il faudrait une sorte d'overloading qui permette de declarer
dans le .mli qu'une operation existe en version safe et unsafe. Je ne
sais pas si ca se justifie.

Si la seule option concernee est -unsafe, pourquoi ne pas juste
emettre un warning quand on utilise simultanement -unsafe et un
preprocesseur qui rend un arbre de syntaxe ?

Effectivement, on pourrait aussi faire ça. C'est un peu bizarre mais
ça a pourtant une certaine logique.

Le seul avantage est que ca se fait en une seule ligne.
Mais certains vont dire que c'est une demission :-)

 Jacques

Comment author: administrator

Salut Daniel,

Complique', non. Mais intrinsequement, c'est un hack, et il se trouve
que le parsing est l'endroit ou il s'introduit le plus facilement. Ceci dit on peut toujours le retarder jusqu'au typage, mais dans ce cas la je prefererai n'avoir qu'un seul noeud supplementaire:
Pexp_access(Module, operation).

Il n'y a pas à indiquer de module dans l'arbre de syntaxe: le noeud
doit être Exp_arrayget of expression * expression, et pour vérifier
les types, c'est trivial ('a array et int, résultat 'a), et seul le
générateur de code doit s'occuper de quels modules il s'agit
(Array.get ou Array.unsafe_get) en fonction de l'option -unsafe ou
pas.

Il y a aussi unsafe_set, donc ca ferait 4 operations.
Ajouter 4 cas supplementaires au verifieur, et peut-etre 8 de plus le
jour ou il y aura des Bigarray.unsafe, ne me parait pas tres propre. La methode actuelle n'est peut-etre pas tres propre, mais elle fait simplement quelque chose de simple, sans toucher aux parties sensibles du compilateur (contrairement a printf par exemple).

Jacques

Comment author: administrator

Si la seule option concernee est -unsafe, pourquoi ne pas juste
emettre un warning quand on utilise simultanement -unsafe et un
preprocesseur qui rend un arbre de syntaxe ?

Pourquoi pas, ça pourrait suffire au moins à éviter le piège...

--
François Pottier
Francois.Pottier@inria.fr
http://pauillac.inria.fr/~fpottier/

Comment author: administrator

Salut,

On Fri, Feb 08, 2002 at 09:45:12AM +0100, Francois.Pottier@inria.fr wrote:

Si la seule option concernee est -unsafe, pourquoi ne pas juste
emettre un warning quand on utilise simultanement -unsafe et un
preprocesseur qui rend un arbre de syntaxe ?

Pourquoi pas, ça pourrait suffire au moins à éviter le piège...

Ok, après reflexions et discussions, on fait ça: je m'en occupe.

--
Daniel de RAUGLAUDRE
daniel.de_rauglaudre@inria.fr
http://cristal.inria.fr/~ddr/

Comment author: administrator

Warning added by Daniel (2002-02-08)