Se7en & Jeff: Thanks for the interest. Greatly appreciated!
I guess the "best" way would be to go with an ARX route, since those .Net stuff isn't actually "portable" as M$ claims (at least not to Mac/Linux). AFAICT the only way to get something truly "upgraded" for lisp would be to redo the entire Lisp interpreter in ARX. I cannot find any hint anywhere on how to start that!
Anyway, I have been looking at other Lisp dialects and come across
ECL (which seems to have promise). Though my C++ skills are rusty to say the least! The last time I did anything in it was in 1998. Recently I've started adding such Lisp-callable functions through .Net, but as there's some issues ... I'm starting to have the opinion that .Net's just not good enough! E.g. not running on Mac (need to compile to dylib through Mono -
which still has an issue), unable to call a lisp routine directly (i.e. events / reactors can't be implemented), worse code security than Lisp (since .Net's
too easy to decompile), etc. If anyone knows of a way to run DotNet from ACad for Mac, please share! That would make this a whole lot simpler.
The closest thing I could find about implementing a new language in ACad is
Kean's block on Python. But again that uses .Net :ugly:
I was thinking it would be possible to use ECL directly through C++. And it "shouldn't" be a huge transition, since ECL can be incorporated into C. It can even load C libraries/
dylib/so directlyso liking to ObjectARX classes would be possible directly from the ECL interpreter. Thereafter the ACad specific defuns (like entget, entmod, etc.) could be implemented in ECL itself - basically wrapping the ObjectARX methods. That way you'd have an AutoLisp/VisualLisp -backwards-compatible interpreter which can now extend and run ObjectARX code. And since ECL is a near full implementation of CL you get the "new" functions from there as bonus!
But the biggest reason I'm starting to think ECL is the way to go is it can already run as interpreter, compile to portable bitcode (i.e. FASL), or use a C compiler to compile to native executable. That way performance would be on par with all the current extension possibilities (even those of direct ObjectARX in C++). Not to mention the code obfuscation requirement (as with .Net's code security issues) becomes a non-issue when you compile.
IMO it should be a way of getting the best of all worlds: Allow old LSP code to run as-is; make new much more powerful addons directly in Lisp; run such as true portable (no need to try and steer clear of the vl stuff which doesn't run on Mac); have a way to get true code security; have near full C++ optimizations; etc. All I can see which might cause hassles is old code using ActiveX connection to outside programs, since wrapping the vla functions to directly connect to ObjectARX could be done direct in ECL; but wrapping to the CreateObject is an infinite task.
Then to go further and redo the VLIDE by replacing it with something like
Scintilla. It already has CL code formatting / completion / etc. And finally speaking to the guys from OpenDCL about making an embeddable version of their suite so we can have a visual dialog IDE.
So it should be a way of compiling an ARX library per ACad version, per OS/environment - which should overwrite the Lisp interpreter
This thread is basically me trying to do the idea from the opposite end, though I know it's doomed to failure as much will simply be unavailable! It's like an attempt at making some of the full CL functions available to the distant (read left in the gutter) cousin AutoLisp.