Since the last post I pushed significant changes on the master branch of Vicare. I did a big clean–up of the expander, removing part of the code for the typed language and replacing it with a new (better) implementation. The old code was ugly, but, with my currently better understanding of the expander, I think I got it right: things are done as they should. Obviously, the “right way” was already there in the original Ikarus’ expander code, but I was not able to recognise it as such.
There are backwards incompatible changes between the current typed language incarnation (which is still under development) and the old one. Life is hard.
This Summer (see C code review) I modified the interface to the garbage collector
to allow disabling GC and I implemented options to configure the heap and stack
sizes. At some point I made some confusion (ugh!) and the associated command line
options disappeared from the code. I have put them back: the command line options
--scheme-heap-nursery-size and --scheme-stack-size select the
sizes; the command line options --option enable-automatic-gc and
--option disable-automatic-gc enable and disable automatic garbage collection.
I have fixed the problems in the master branch that prevented rotating the
prebuilt boot images distributed with the tarballs; I have rotated the boot images,
so it is now possible to use the features in the source code to compile the boot
image itself. I still have to do the same with the typed language
branch; things are more complicated in this branch for reasons I will discuss in
some future.
A Github user asked for help in interpreting an error message from Vicare. I am completely sympathetic: the condition objects are cryptic if one knows nothing of Vicare’s internals and it is quite difficult to determine the origin of the error in the source code.
In the original Ikarus code, the interpretation of r6rs is that some errors must be raised at run–time and only if the code associated to the offending form is evaluated. This is the case of the “wrong number of arguments” and “wrong type of arguments” in function application.
Vicare is changing this to detect as much as possible at expand–time and
compile–time; however it is not there, yet. In particular, the core primitives
(defined by the boot image) have no syntax informations associated to them: in the
master branch’s code base, there is nothing in the expander that allows checking
at expand–time a wrong number of arguments in applying, say, the core primitive
substring. This is not so in the compiler, where I have already added a table
with arguments description for almost all the core primitives.
So it happens that the expander does not detect an error and the compiler does. But
source code informations are present only in the expander, the compiler knows nothing
of source files; hence, when using code from the master branch, we see errors
stating that somewhere substring was applied to the wrong number of arguments.
This is ugly.
The code in the typed language branch is starting to fix this problem by including a table of core primitives in the expander, so that we can see a proper expand–time error with source code informations. It is still a work in progress.
When debugging this kind of errors, we can try to mitigate the problems by enabling
debugging mode and turning on “strict r6rs”; we do this by using -g on
the command line and using the option ‘strict-r6rs’ in program and
library forms. Strict r6rs mode disables reporting of some errors at
expand–time and compile–time, leaving them for run–time; this triggers the
debugger interface when an exception is raised and we can examine the stack trace to
gather some context on the location of the error. It is not much, because the
debugger is still primitive…
The original Nausicaa libraries were intended to run on every r6rs
implementation, but at the end I introduced some Vicare–specific syntaxes
(especially the syntax splice-first-expand); the internals are quite clunky
and the source code expansion times are long. I want the typed language from
(vicare) to be better than the Nausicaa language from (nausicaa); it
want to make it possible to port all the code relaying on (nausicaa) to
(vicare) without loosing features.
In the end, Nausicaa will be removed from the package; the typed language branch already has the Nausicaa libraries excluded from the build infrastructure. Pain! Sorrow! It hurts me to discard code (and documentation!) I have worked on for so much time. It also hurts me the to think of porting the code (and documentation!) to a new language (not completely different, but different). That is life…
I hope that nobody is heavily relying on Nausicaa out there (quite unlikely; anyway, Vicare’s major version number is zero for a reason).
I started distributing tarballs at
Bitbucket. They are
development prereleases from the master branch. Their purpose is to make it
possible to build Vicare without installing the gnu Autotools.
I have read about it; I have thought about it. It is an interesting initiative; it is not easy to implement in Vicare; if it were easy I would implement it right away. There are some minor issues with the build date included in the repl greetings and some gensyms used as property keys. The real issues are:
Most likely there are other problems.