From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by yquem.inria.fr (Postfix) with ESMTP id 4F45CBC57 for ; Sat, 23 Oct 2010 04:25:47 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4BAB7kwUzAbSoIe2dsb2JhbACDH55LFQEBFiIEHqsWkXoNgRWDMnQE X-IronPort-AV: E=Sophos;i="4.58,226,1286143200"; d="scan'208";a="75083167" Received: from einhorn.in-berlin.de ([192.109.42.8]) by mail4-smtp-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 23 Oct 2010 04:25:46 +0200 X-Envelope-From: oliver@first.in-berlin.de Received: from first (e178021239.adsl.alicedsl.de [85.178.21.239]) (authenticated bits=0) by einhorn.in-berlin.de (8.13.6/8.13.6/Debian-1) with ESMTP id o9N2Phfv003349; Sat, 23 Oct 2010 04:25:43 +0200 Received: by first (Postfix, from userid 1000) id F2506442023; Sat, 23 Oct 2010 04:25:42 +0200 (CEST) Date: Sat, 23 Oct 2010 04:25:42 +0200 From: oliver@first.in-berlin.de To: Norman Hardy Cc: caml-list@yquem.inria.fr Subject: Re: [Caml-list] Typesystem and Parsers Message-ID: <20101023022542.GA17861@siouxsie> References: <20101022165950.13786wcej1xp31eu@webmail.in-berlin.de> <02EDD7B5-BB14-4A51-878F-D3020C7B5FE7@cap-lore.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <02EDD7B5-BB14-4A51-878F-D3020C7B5FE7@cap-lore.com> User-Agent: Mutt/1.5.20 (2009-06-14) X-Scanned-By: MIMEDefang_at_IN-Berlin_e.V. on 192.109.42.8 X-Spam: no; 0.00; in-berlin:01 parsers:01 bandel:01 arranging:01 parser:01 ocamlyacc:01 syntax:01 ocaml:01 ocaml:01 parser:01 compilation:01 ocamlyacc:01 tokens:01 invariants:01 glass:98 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 vs. 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. Ciao, Oliver