Re: [Caml-list] A few questions regarding the compiler

["Marcin 'Qrczak' Kowalczyk" <qrczak@knm.org.pl>]

Tue, 13 Nov 2001 21:36:57 +0100, Xavier Leroy <xavier.leroy@inria.fr> pisze:

> For standalone executables, it is very easy to wrap your generated
> program in a catch-all "try...with" construct, and print the escaping
> exception as you see fit.

Then it would be impossible to dump the backtrace. A backtrace
which shows OCaml source positions might be better than nothing.

Well, I could reraise the exception after printing, but then it would
be printed twice, formatted by me and by OCaml, which is a bit silly
especially when there is no backtrace (the usual case).

It would be ideal to be able to obtain the backtrace programmatically
after I catch an exception. I could even think about translating
positions to real source in this case. Is that possible?

> Camlp4 (among other features) provides an easy way to construct OCaml
> abstract syntax trees and have then compiled or executed by the OCaml
> compilers or toplevel.  It exploits a number of hooks in the compilers
> and toplevel to achieve fairly tight integration with them.  So, I'm
> pretty sure it could help, provided your compiler is written in OCaml
> indeed.

It will be "written" in OCaml after I rewrite it in itself. It's
not going to happen soon, but it would not be much of work. The
gap between being so small to be easily implemented and so big to
implement something is shrinking as I'm completing the library.

>> [toplevel interface not doing what you want]
>> I don't want to have to compile a custom OCaml version - it should
>> work with whatever is installed with OCaml.
> 
> Methinks you're asking for too much here :-)

It's so close... Why else would topmain.cmo be separate? Don't say
that it's because the linker would otherwise throw the library out,
treating it as unused. I know that it's separate for being able to
replace topmain with a customized version :-)

The only problem is that some key features are not exported.

> The ocamlc and ocamlopt compilers honor '# lineno "filename"'
> directives.

Ah, I could have checked before asking.

BTW, I think it's not quite true that special-casing the representation
of float arrays while pretending it's the same type has little cost.
Almost all functions in the Array module do a check in their inner
loop. Since code generated by my compiler uses arrays very often,
I don't call functions like Array.of_list but use inline loops or
specialized functions.

Besides float arrays, I see that writing to an array whose element
type is statically known to be always an immediate word is faster than
the other case which must call 'modify'. Are such details described
somewhere?

I guess that it's fine to initialize an array of non-floats with
'Obj.magic 0' even if the type doesn't have nullary constructors,
provided that I overwrite elements with valid objects before use?
I don't always have a proper element at hand. Is it true that the
Array module cares to always find a valid element for initialization
only because of float arrays? And is it true that 'Obj.magic 0' can be
sometimes more efficient than a pointer because some case in make_vect
uses 'initialize(&Field(res, i), init)' instead of 'Field(res, i)
= init' in its inner loop? Or slightly less efficient because later
initialization must do one round more... Why are small arrays and
large arrays treated differently?

-- 
 __("<  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