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 WAA23311; Sun, 11 Nov 2001 22:52:27 +0100 (MET) Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id WAA22454 for ; Sun, 11 Nov 2001 22:52:25 +0100 (MET) Received: from mail.mimuw.edu.pl (paf87.warszawa.sdi.tpnet.pl [217.96.225.87]) by nez-perce.inria.fr (8.11.1/8.10.0) with ESMTP id fABLqD515069 for ; Sun, 11 Nov 2001 22:52:15 +0100 (MET) Received: (from news@localhost) by mail.mimuw.edu.pl (PLD/8.9.3) id WAA13914 for caml-list@inria.fr; Sun, 11 Nov 2001 22:54:29 +0100 X-Authentication-Warning: qrnik.zagroda: news set sender to Marcin 'Qrczak' Kowalczyk using -f From: "Marcin 'Qrczak' Kowalczyk" Subject: Re: [Caml-list] A few questions regarding the compiler Date: Sun, 11 Nov 2001 21:54:25 +0000 (UTC) Organization: Klub Nieszkodliwych =?iso-8859-2?Q?Manjak=F3w?= Message-ID: References: <9smdf7$511$1@qrnik.zagroda> X-Trace: qrnik.zagroda 1005515665 13909 192.168.0.1 (11 Nov 2001 21:54:25 GMT) X-Complaints-To: abuse@localhost NNTP-Posting-Date: Sun, 11 Nov 2001 21:54:25 +0000 (UTC) User-Agent: slrn/0.9.7.2 (Linux) To: caml-list@inria.fr Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk Sun, 11 Nov 2001 18:38:30 +0100, Xavier Leroy pisze: > In 3.03 alpha and in the forthcoming 3.03, additional "hooks" were > added to the toplevel so that it can call user-provided functions for > displaying evaluation results, including uncaught exceptions. The > Camlp4 preprocessor makes good use of this new feature. Only toplevel? I would like to have it in standalone executables. It doesn't have high priority though - often exceptions are defined in OCaml, wrapped in objects of my language only when catching, reraised in their original form, so then they are printed reasonably. I was thinking about backtraces. It would be very helpful because the compiled language is dynamically typed so errors are often catched at runtime. Unfortunately translating an OCaml backtrace to something related to source positions would be very tricky. It would even have to be pasted manually to an external tool because the program proper doesn't have access to its backtrace when it fails - it's just printed to stderr when it's too late. >> I think it should be possible to start ocaml (or a custom >> toplevel) in a subprocess and talk with it through a pipe, >> giving it declarations compiled on the fly. > > It can be done this way indeed, although again Camlp4 provides > another alternative where your preprocessor and the Caml toplevel > live in the same process. I don't see how Camlp4 could help. The compiler is not written in OCaml, it only generates OCaml output. > Not easily. You could link with the toplevel and call > "Toploop.use_silently" to execute code from a file, suppressing > the output. I looked closer and realized that it's quite impossible to plug into toplevellib something other than the default Topmain, although it's very close to being possible. For example the Clflags module is not exported (i.e. clflags.cmi is not installed) so I can't set any options. Initialization is hardwired into Toploop.loop, but calling Toploop.loop is too much: it reads from stdin (which must be available to the program so it can't be /dev/null) and writes to stdout. Initializing by hand is not possible because the relevant modules are not exported. I don't want to have to compile a custom OCaml version - it should work with whatever is installed with OCaml. Unfortunately now it's impossible. Another question. Low-level libraries for my language contain many embedded OCaml snippets written by hand, so they often contain errors. Is it possible to tell the OCaml compiler about original source positions for parts of the program, so it reports them in error messages? I mean like '# line_no "filename"' in cpp. Maybe Camlp4 could help? Yet another question. OCaml doesn't accept an identifier as the rhs of let rec (an identifier defined earlier). Why? I had to make a little workaround to not generate such bindings. I guess it's the only difference between "what is accepted in let rec" and "what allows generalization of free type variables"? -- __("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ QRCZAK ------------------- 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