From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id RAA09459; Mon, 4 Feb 2002 17:25:17 +0100 (MET) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id RAA09893 for ; Mon, 4 Feb 2002 17:25:15 +0100 (MET) Received: from fichte.ai.univie.ac.at (fichte.ai.univie.ac.at [131.130.174.156]) by concorde.inria.fr (8.11.1/8.11.1) with ESMTP id g14GPE107051; Mon, 4 Feb 2002 17:25:14 +0100 (MET) Received: from chopin.ai.univie.ac.at (root@chopin.ai.univie.ac.at [131.130.174.170]) by fichte.ai.univie.ac.at (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id RAA32194; Mon, 4 Feb 2002 17:25:13 +0100 Received: (from markus@localhost) by chopin.ai.univie.ac.at (8.9.3/8.9.3/Debian 8.9.3-21) id RAA22636; Mon, 4 Feb 2002 17:25:13 +0100 Date: Mon, 4 Feb 2002 17:25:13 +0100 From: Markus Mottl To: Daniel de Rauglaudre Cc: caml-list@inria.fr Subject: [Caml-list] syntax change (was: camlp4o problem) Message-ID: <20020204162513.GA22263@chopin.ai.univie.ac.at> Mail-Followup-To: Daniel de Rauglaudre , caml-list@inria.fr References: <9BE7FA48-1771-11D6-A336-003065BDAA76@ece.ucsb.edu> <15454.38553.300800.53941@gargle.gargle.HOWL> <20020204155242.B2338@verdot.inria.fr> <20020204150839.GE14738@chopin.ai.univie.ac.at> <20020204164154.D2338@verdot.inria.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020204164154.D2338@verdot.inria.fr> User-Agent: Mutt/1.3.26i Organization: Austrian Research Institute for Artificial Intelligence Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On Mon, 04 Feb 2002, Daniel de Rauglaudre wrote: > It has no chance to become the standard if nobody wants to use it... And unfortunately vice versa... > There are very few users interested in the revised syntax. Because it is not standard. > How much do you estimate the chances that people will accept a major > change of the syntax? If it breaks their previous work and/or if they cannot continue in their old style (at least for a while), ... > You want my opinion? 0% ... then 0%, I agree. > If you have written an application of 50000 lines of OCaml on 60 files > in 5 directories, are you accepting that the new version of OCaml has > a very new syntax, very clean and very incompatible with the previous > one? If I can use camlp4 conveniently to work with my existing sources as if no change had happened, I wouldn't mind, but I fear that not everything would work smoothly right now. It should at least in principle be possible (though a lot of work) to design all language tools in such a way that they accept ASTs annotated with position information (for exact error messages), thus making them completely independent of concrete syntax. This would make later syntax changes much less cumbersome for both the maintainers and the users and allow the language to evolve faster. A rather strategic proposal for the language and environment... > And even if you want to convert to it, what is your reaction if the > new version of OCaml has a bug in a part very important for you? I don't quite understand this argument: bugs can happen during every change, what is the problem with syntax changes in particular? > Well, there is no need to impose a new clean standard syntax, because > there is Camlp4. If most of people use the revised or any-clean syntax, > it becomes a standard de facto. I disagree here. People need a "soft kick" to change. Surely, it shouldn't be a painful one, this would just drive away users, but a strong enough one to make them go and give future users of OCaml the opportunity to start out with an even saner syntax. > I am ok for a definition of a new syntax. I propose the revised syntax > as a start of the discussion. That's ok for me. There may be small details where I could argue about alternatives, but it is probably a good start. > I don't propose to start with the normal syntax because it is too much > difficult to parse with recursive descent technology. I managed to do > it but thanks to hacks. Sounds reasonable. For people who want to learn more about advantages/disadvantages of LL-parsers (= recursive descent) vs. LALR-parsers (= ocamlyacc), see this article: http://compilers.iecc.com/comparch/article/91-06-032 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