I included discussible topics in this document formatted in italic letters.
This is a preliminary version for discussion only. The italic parts and this section will be removed from the release version.
Overview
Consider this: Too much functionality can be bad too.
In the current status my most concerns are Provide Table User Input Functions? and Provide SSGET User Input Functions?
The rest seemed to be pretty nailed down in the current status.
To summarize my current problems:
2) Should the use be restricted? (morality?)
Status:
ad 1) Granted, if the cost doesn't exceed the usual fees for the media and shipping only. It does require my written permission however.
ad 2) No usage restrictions whatsoever. You use it to design atom bombs, genetic mutants or chemical factories. Life is so bad and immoral.
AutoLISP programmers developed bad habits over the years. Complexity increased. AutoLISP programs became unreadable.
Pro: I see no real name conflicts.
Contra: AutoLISP is in common knowledge.
Status:
Some functions still use short names, but most names are hyphenated and use long names instead of abbrevations.
Ex: std-mark-entity instead of std-markent or std-mark-ent
std-filename-split instead of fnsplit
Why are there a few functions are not prefixed with STD-?
They are in particular stringp, consp, function, first, second, third, ..., rest,
as well as x-of, y-of, z-of, xy-of.
Mainly of historic reasons I wrote. Well, that's not 100% correct.
What means mainly of historic reasons?
If we want consistency shouldn't we define all names in a consistent manner?
All but x-of,... and dxf, modes, moder are in my eyes terrible omissions from the language. They are so simple and their names should be short that they should be defined without the prefix.
function is normally defined as #' reader-macro in CL similar to quote. Hopefully #' will be supported in the next release of AutoLISP. In the meantime we'll have to write (function func) instead of 'func.
x-of, x-min, ... are very useful in accessing parts of points and should be kept short too. Keeping x-min,... without prefix is questionable. I prefixed it for now.
modes, moder and dxf are often used internally in Autodesk samples but never made it to AI_UTILS.LSP unfortunately. modes and moder without prefix is questionable and could be enhanced, but dxf is in common knowledge and quite simple in comparison to std-getval. In my eyes modes and moder should be replaced with a better construct (std-var-init), that's why I didn't prefix it. dxf as (defun dxf (n l) (cdr (assoc n l)))
cannot be broken and is common knowledge.
Status:
moder, modes and dxf didn't make it into the STDLIB so far. Too poor. I may watch bad movies but I cannot stand bad functions. Everything else is as described.
I think it's a good idea to divide STDLIB and internal globals (**) from application globals, which are mainly defaults.
I wrote: "Application dependent default values may be prefixed with your app-prefix and ":" like my:def-lengthen-dist"
Status:
External STDLIB globals: * name *
Internal STDLIB globals: *STD: name *
External user defined globals: * name *
Internal user defined globals: * user-prefix : name * or just user-prefix : name
Status:
The signatures are fixed, but the documentations and implementions not
Status:
Some signatures are written down, but the documentations and implementions not. No external function provided.
There are already some EED- functions in the FAQ. Is this enough?
I implemented better accessors, modifiers and some utils.
Status:
not decided yet
Status:
Included as external, but supported and documented module.
STD- prefixed
(setq s "test") (std-string-upcase 's) => "TEST" !s => "TEST"
Should it be defined for all canditates also listed below?
Should they have a distinguishable name?
Those functions are very useful when only called because of their side-effects and not in a functional context.
(std-default 'x 10)
is shorter than a similar
(setq x (std-default x 10))
but means the same.
But string conversions like (write-line (std-string-upcase (read-line fin) fout)))
are mainly used in functional context and should therefore not support the "destructive" feature. This has to be discussed for every single function probably. Anyway the scheme is the same for each function.
I would vote for leaving it as it is. Destructive versions are faster than non-destructive, but not being used in functional context looks confusing. Clarity is more important here than performance.
Possible canditates for "destructive" versions (accepting quoted symbols) are:
all string conversion functions
all string formatting functions
Yet the following functions are defined "destructive":
std-default, std-default-type, std-push, std-pop, std-pushnew, std-string-upcase, std-string-downcase, std-string-capitalize
Against:
Status:
not decided yet
They are not defined in CL but sometimes found in AutoLISP. Their arguments are different then the standard firstn and nthcdr and often misleading. Should be deprecated.
Status:
No
State of the art functions may frighten beginners as nowadays extensive use of cond as or-replacement, apply or mapcar. This would apply to case, typecase, stdx-format, and similar hard to understand functions.
On the other hand these are the advantages of lisp.
A StdLib would have wide distribution.
Status:
No
Standardize external library dependant code? (just because of the benefit of optional arguments)
(stdx-format dest fmtstr args...)
(stdx-printf fmtstr args...)
(stdx-write args...)
The problems are here that is highly depends on an external library, which must support optional arguments and different types of destinations, which might be a string, a stream or the console. It will need someone to create and support this library for all versions, my versions may only be used with Vital Lisp or Visual Lisp. I and Vladimir Nesterovsky have similar stuff as an ADS module. So the code is there, but who will support old versions?
Prefix:
Cannot think of any useful now. Therefore I used stdx-
Status:
Not decided yet. Maybe just include it with the book. Optional arguments are too hard to support for all platforms.
The error messages could be instead of being static print current values.
Same problem as above with optional arguments above.
(stdx-error format-string args...)
Sample: (stdx-error "Error: Cannot open ~A" fname)
Status:
Not decided yet. Maybe just include it with the book. Optional arguments are too hard to support for all platforms.
There are two possibilities.
1) The easy one goes like this:
(defun my-findfile (fname) (cond ((findfile (std-force-path *my-path* fname))) ((findfile fname))))
2) The other one re-implements findfile with tokenizing the Acad Library Path into a list. This list may be manipulated and searched then. You would be able to define default extensions over default paths and such.
Then we could also implement a findfile finding an executable in the current PATH environment or anywhere, like doslib dos_search which searches paths from any environment variable and not only in the Acad Library Path.
The problem is that this may be too complex for the average user. And the simple version should not be standardized because it uses a global variable, which may cause problems. Not using a global variable would require a second argument which is different from findfile.
Status:
So far a similar functions for searching paths and for extensions are included.
Should it be in the StdLib or in an StdLib extension?
An external library is either doslib by McNeel or the vl-, vlx- or my urx- VLisp extensions.
The point is if the external libraries will be in common accessibility. If so the names could stay simple, if not the names should be distinguishable.
Prefixes:
More see below.
Status:
STDFILE extensions defined in FILEEXT have no distinguishable name.
Others have the filename prefixed to the function name. (BINIO-, REGISTRY-, INIFILE-)
Should it be in the StdLib or in an StdLib extension?
So far this is only supported by my own Vital Lisp Extensions (BINIO.FAS at
http://xarch.tu-graz.ac.at/autocad/stdlib/binio.zip
) and by an old ADS module of mine, acaddoom:
http://xarch.tu-graz.ac.at/home/rurban/software/acaddoom.zip
used for ArsDOOM for R12/DOS and R12/Windows
The problem is that an ADS or ARX module is AutoCAD is version specific. For every different Release and Platform we will need a different library.
The FAS module is not version specific, but we'll need the Vital Lisp Runtime system, which will be standard for R15, but the StdLib is designed for all releases R12+
Prefix:
If in StdLib STD-FB- and omit the F like STD-FB-OPEN
If as extension BINIO-.
Status:
BINIO as as external FAS and as ads/adsrx/arx is supported.
Should it be in the StdLib or in an StdLib extension?
So far this is supported by doslib and I have a similar implementation. The ADGE in its lisp libraries too if I remember it correctly.
Prefix:
If in StdLib STD-INIFILE-
If as extension INIFILE-
Status:
INIFILE as external FAS and ads/adsrx/arx is supported.
Should it be in the StdLib or in an StdLib extension?
If in the StdLib with STD-REG- prefix or STD-REGISTRY-?
If not use the REGISTRY- prefix? Vital Lisp has a VLX-REGISTRY- prefix.
Either support uniformly only one key argument and split this to the vl-specific path-key or leave the two arguments as in VL?
Currently supported by Vital Lisp and setreg.arx.
I would vote for an external REGISTRY library.
Status:
REGISTRY as external FAS and ads/adsrx/arx is supported.
VL argument style supported so far to make porting easier, plus a helper function to split the key to path+key.
logbitp is the common lisp function. It is defined like (logbitp index integer) where index is the position of the bit.
(bitsetp bit-value integer) fits better to the bit operating functions, because we do better use bit-values and not bit-indices.
That means checking for flag 128 we would write either
(logbitp 7 flag)
or better (bitsetp 128 flag)
27 = 128 or the 7th bit indicates 128
I would vote for bitsetp.
Status:
Implemented and documented as std-bitsetp.
Status:
Support for multiple values is included as sample but not supported by the STDLIB. It does not use any STDLIB function.
Complex numbers are not supported.
Status:
Numeric exceptions throw the AutoLISP error.
(std-fclose nil) is ignored when *DEBUG* is nil..
Safe versions using unsafe AutoLISP versions throw their own errors. STD-ELT
I'm somehow concerned about the size and loading time. Some exotic functions maybe provided in external modules.
STD-PRIME*, => PRIMES
STD-MAKE-RANDOM-STATE, STD-RANDOM-STATE-P,
std-%*-rand-* => RANDOM
Status:
Moved to those external modules with v0.3012.
(std-inp-entsel <flag> <kwd> <msg> <def>)
could be enhanced to require a certain entity type as with (ssget filter-list)
. Same for std-inp-nentsel of course.
It would then be defined as (std-inp-entsel <flag> <kwd> <msg> <def> <ent-filter>)
Such a filter list would look like the ssget filter list. If nil every entity is accepted.
Advantages would be getting rid of loops in the code, but on the other hand those loops are often highly customized.
Status:
Not implemented yet.
Such as with the module name "TEST":
TEST-a TEST-x ... and *TEST* *TEST1* ...
Status:
Deletion is dependent on the global boolean variable *STD:UNBIND-SYMBOLS* which defaults to nil. So they are not deleted by default for now.