I was thinking about how to support multiple files and one approach might be to make it possible to take an lexp and print it to a file, and then read it back.
Then "exporting" the definitions of a particular module could look something like "take those defs, put them into a tuple, and print it to the file", and then importing definitions from a file would be a macro which reads the file and returns the corresponding lexp.
As for how to "print & read", there'd be two ways to go about it:
A- define brand new primitives that go straight from lexp <-> string.
B- rework our lexp <-> sexp code to make it robust enough.
Option B would also be useful in macros, so it's definitely something we should try to do. But it also means that reading would go through "sexp -> lexp" i.e. through elaboration. We could probably arrange for it not to do any macro-expansion and maybe also to avoid any need for unification, but it seems like it'd inherently be clunky/inefficient.
So, I think option A is preferable.
Stefan
Afficher les réponses par date
I was thinking about how to support multiple files and one approach might be to make it possible to take an lexp and print it to a file, and then read it back.
Then "exporting" the definitions of a particular module could look something like "take those defs, put them into a tuple, and print it to the file", and then importing definitions from a file would be a macro which reads the file and returns the corresponding lexp.
To be sure I understand correctly, every defs of each source file would be written to a unique "output" file (which would be read as if there was only one file).
Isn't it a waste of time to write and read to/from a "output" file (in other word, couldn't it be done in memory instead of on the disk) ?
As for how to "print & read", there'd be two ways to go about it:
A- define brand new primitives that go straight from lexp <-> string.
B- rework our lexp <-> sexp code to make it robust enough.
Option B would also be useful in macros, so it's definitely something we should try to do. But it also means that reading would go through "sexp -> lexp" i.e. through elaboration. We could probably arrange for it not to do any macro-expansion and maybe also to avoid any need for unification, but it seems like it'd inherently be clunky/inefficient.
So, I think option A is preferable.
lexp <-> string primitive could useful for other purposes than multiple source file management. So going for option A is not a waste even if it's not used for this feature.
Option B would be nice with some kind of pre-compiled format. Expensive computations would be done only during pre-compilation.
To be sure I understand correctly, every defs of each source file would be written to a unique "output" file (which would be read as if there was only one file).
No. The idea would rather be to write into a file a "tuple" containing the few definitions you want to export from the file (i.e. those that are visible from outside). I.e. one source file turns into one "compiled" file.
Isn't it a waste of time to write and read to/from a "output" file (in other word, couldn't it be done in memory instead of on the disk) ?
It gives you a limited form of separate compilation (the "compiled" file has already been elaborated, so you don't need to macro-expand its code any more nor do you need to do any kind of type-inference).
Stefan