English version
Accueil     À propos     Téléchargement     Ressources     Contactez-nous    

Ce site est rarement mis à jour. Pour les informations les plus récentes, rendez-vous sur le nouveau site OCaml à l'adresse ocaml.org.

Browse thread
Typesystem and Parsers
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2010-10-23 (02:25)
From: oliver@f...
Subject: Re: [Caml-list] Typesystem and Parsers
On Fri, Oct 22, 2010 at 04:43:46PM -0700, Norman Hardy wrote:
> On 2010 Oct 22, at 7:59 , Oliver Bandel wrote:
> > Also with arranging a parser (e.g. with ocamlyacc) both ways can be walked along, either by just accepting everything and build up the tree, and later detect erros in syntax or type... (for example all scanned entities given back as strings or string lists)...
> Let me describe an advantage that I see for Scheme over OCaml which pushes in the opposite direction to your proposal.
> Analyzing a Scheme  program such as (let ( ... (r ...) ...) ...) where the ellipses may be pages of code, I can put the cursor just to the right of the r and type splat B twice on at least the Mac and learn the scope of r.
> There are few more frequent steps for me as I study Scheme code.
> Any of several editors that are not Scheme savvy can do this and even the Mac's Terminal program (a glass TTY for the shell) knows this trick.
> I miss this in OCaml.
> Perhaps this is because the gross parsing of Scheme is carried out at the lexical level—parentheses first!
> As I reason about the scope of an OCaml variable, the whole cache of program logic in my head is flushed!
> And them I am not sure of the result.
> A systematic algorithm to determine scope is complex and error prone.
> I want simple syntactic rules to determine scope, rules that fairly general editors can help with.

Hmhh, ok that's a convenience thing you like in Scheme.

But I really meant not how to work with Ocaml vs. other languages
(which tools are there and IDEs).

I meant the tradeoff between either using the type system (and how the parser is written)
to make the code robust but  that it will break the compilation on the one side
on the other side making the parser (and used types) less rigid and rather
going a weakly typed way (or using for example reinvocation of the parser with
"error" catching in ocamlyacc for example, to just ignore errors) 
so that the tokens can be picked up, and the decision if the e.g. a found string
should have been an int.

So it's rather about parsing techniques.

Maybe I'm too much off-topic here.

Sorry if I am.

But somehow I think when using OCaml things behave different than doing it in
C, and if I want to take the advantages of OCaml and the type system (to use
the type system as constraints to program structure, pushing invariants into
the program via type system), how can I nevertheless do a complete parse - as
far as possible - and after creating a parse tree, analyze the tree (instead of
being forced to stop at the first error).

Should there be error-tokens inserted into the parse tree?
Or will this become a big mess and I better just stop at the first error
of my input language?

For example in a book I found mentioned, that type checking is a very late stage
in parsing. But I doubt this was written with OCaml in mind, even though
it was stated as general.