This is a programmers library only, not a users utility collection.
This is free software, not shareware and not public domain.
This is not for AutoCAD users, it is for programmers!
Advantages of a proposed Standard Library for AutoLISP:
Keep backward and forward compatibility across old and new versions and platforms.
Disadvantages:
Compatibility:
The STDLIB should provide backward and forward AutoLISP compatibility, that means new extensions are usable in old versions too and old functions should work on new versions too.
This feature is generally not provided by Autodesk, neither backwards nor forwards compatibility. There is not enough documentation how to update old functions to work with new objects such as the LWPOLYLINE or HATCH object or how to handle FUNCTION
or SPECIAL
from ACOMP, or how to use VL extensions with old AutoLISP versions. This library is in my knowledge the only and preferred possibility to keep AutoLISP compatibility in both directions.
Seperate packages:
Supporting R11 and earlier releases has some problems with memory (node space and string space) so we provide a special lightweight version. There exist also packages for R11 and earlier or for ACOMP without inline comments, such as in STDALL.LSP
. All these special version are automatically produced from the original version to assure always uptodate versions.
There exists also a seperate tool, the PACKAGER, which analyses your source code and copies all used externals functions to a special library file. This reduces memory and filesize and enables experimenting with libraries in general, whilst the actual shipped copy is saved in one big package for reference and immediate fixes.
Implementation:
The STDLIB should be platform and release independent as much as possible.
In detail it should honor those key features: Stability, Compatibility, Readability, Performance and Extendability
See the special chapter about the key features.
Implementations of all functions will be provided by myself but everybody is invited to improve these as long as the interface is same (same number of arguments, argument types, described behavior, return values, side effects)
The implementations of presented functions are not solid as rock, just examples how I implemented them in the last 5 years. Only the definitions, return values and side-effects should be defined very strict. Of course everybody may and do define its own function implementations, some will be spread as protected or compiled versions or even be built-in in future releases of AutoLISP or Visual Lisp.
Enhancements:
Samples for enhancements are outlined with Tables User Input functions for example. I just defined the simplest framework and gave tips how I implemented it by myself.
Another purpose is to bring AutoLISP nearer to a real lisp system, with similar lisp function names. Optional arguments, defmacro, setf, reader-macros, lexical scoping, an object system and a type system is unfortunately out of discussion or the STDLIB, but not for certain extensions. But better a small step forwards than nothing.
Some functions are designed for extensions and future enhancements. Such as STD-COPY-TREE
which would only make sense if AutoLISP would support destructive list operations, or the order of arguments for possibly setf'able functions. SETF
is already available as extension so we have to pay attention to provide a common style for the order of arguments in the get and setter functions.