Julia: export flisp in libjulia?

[stevengj]

Would it be crazy to export fl_* in libjulia?

I was thinking of putting together a Scheme mode in the Julia REPL that called the built-in Scheme interpreter, partly for fun (for the greater glory of Scheme!) and mostly because it would make it a lot easier to hack on the parser (the julia --lisp REPL sucks). But I'm stuck because I can't call the flisp API from Julia code.

(A few of the flisp functions are missing the fl_ prefix, but those should probably be renamed anyway.)

[ViralBShah]

While a good idea, does this bind us to long term support for the scheme APIs? Perhaps they can be undocumented and the modes can be added in packages? Of course, APIs can also be deprecated if we switch to JuliaParser or something, if ever.

[yuyichao]

I think we can export a minimum amount of flisp api for a possible FlispREPL package that helps parser hacking like https://github.com/JuliaLang/julia/pull/17108

[lobingera]

@stevengj
There are some rumors, that julia tries to solve the two-language problem with one language. Adding more languages follows a strange logic.

[ViralBShah]

I see this more in the direction of having a scheme FFI, just like we do for many other languages.

In fact having a high level Julian API for working with the parser will even allow for a non scheme parser in the future.

[JeffBezanson]

@stevengj Using julia --lisp with rlwrap helps its repl situation.

[stevengj]

Thanks Jeff, though rlwrap doesn't give tab completion.

Maybe I should just write a Guile.jl package instead, though I'd have to provide some Julia extensions in order to call the parser. (Jeff, besides the stuff in julia_extensions.c, how much of flisp deviates from standard Scheme?)

[StefanKarpinski]

How about exposing the fl_ namespace if a compile-time option is set and if you've got Julia compiled that way, you get a Femtolisp mode?

[stevengj]

@StefanKarpinski, it seems like too much work to implement a femtolisp mode that almost no one will be able to use.

[stevengj]

It would still be nice to have this. I don't think we need to commit to supporting the API indefinitely; just leave it undocumented for use in a package, if only to provide a full-featured lisp REPL for hacking on the parser.

[ihnorton]

If we really don't want to expose everything as an exported API, we could conditionally stick the function pointers in a struct.