Julia compilation performance

[Scott Jones]

I'd seen some discussion of the performance of Julia compilation on GitHub, and was curious about how the performance of JuliaParser.jl compares to the Scheme parser.

Would it be possible to use a cut-down Scheme parser as part of a bootstrap process, that would have enough in it to compile (a possibly rewritten & simplified) JuliaParser.jl

and enough to get to the point where it starts to load sysimg.jl, and then restart with a kernel that uses the Julia written parser, that has no femto-lisp at all in it, saving some space

and possibly some complications).

Future extensions to the language would then be easier for most Julians (help ameliorate the 5-7 language problem Julia has, since it needs proficiency in Scheme, C, C++, Julia, LLVM IR, Fortran (if you need to fix issues with some of the major libraries), and even some Ruby thrown in if you need to fix table setup in utf8proc).

[Ismael Venegas Castelló]

As much as I like Scheme I think that one lang less for Julia source code would be great, I assume that JuliaParser.jl is supposed to eventually supersede the Scheme parser? I red once that the scheme AT lowering was a bottleneck at some point and that JuliaParser performed better under certain circumstances, but it's difficult to keep up with this kind of news.

Also the Scheme code is under documented and using a Julia version would help a lot in this regard, I think femto-lisp has no knowledge of docstrings in it's implementation for example.

If the scheme parser is not meant to be replaced by a Julia version, I'd like to know the reasoning for this, (I think it's just not critical right now, is this right?)