Preface

Open points

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:

Disclaimer
1) Should it be allowed to sell the library alone?

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.


Sources: Order of importance
Common Lisp over AutoLISP?

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 Prefixes?
I don't really want to discuss this topic but it will come for sure.

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.


Prefixes for Globals
Other ideas?

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


Provide Table User Input Functions?
I really don't know if these user input functions should be provided or not. These are very likely to be highly customized. A primitive implementation might hurt, an advanced might be overkill. I think it should be left to the developer.

Status:

The signatures are fixed, but the documentations and implementions not


Provide SSGET User Input Functions?
The SSGET function should be extended to provide a prompt, react on keywords and filter certain entoity-types. However it is probably not a libraries job.

Status:

Some signatures are written down, but the documentations and implementions not. No external function provided.


EED-: StdLib or external?
Should it be included the StdLib or in an StdLib extension?

There are already some EED- functions in the FAQ. Is this enough?

I implemented better accessors, modifiers and some utils.

Status:

not decided yet


ENTMAKE-: StdLib or external?
Internal or external, STD prefix or none.

Status:

Included as external, but supported and documented module.

STD- prefixed


List, String: "Destructive" versions
"Destructive" is a misnomer, but I hope you understand what I mean. It accepts a quoted argument and sets the symbol value of the provided symbol. The return value is not important but returned nevertheless. In AutoLISP there exist no real destructive list functions like rplacd, sort or nreverse.
(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 modifying list functions

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

List: std-head, std-tail?
Should it be included or not?

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


Complexity: case, typecase, stdx-format
Should it be defined in a StdLib or is it too complex?

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


String: stdx-format, ...
Should stdx- functions with optional arguments be defined or is it too complex?

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.


Errors: support stdx-format?.
Should the error functions support extended format strings as in CL?

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.


Filelib: Findfile
It's a good idea and I implemented it this way, to put a user-defined path in front of (findfile) to be able to find your own file before a conflicting version.

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.


Filelib: Functions dependant on external libraries
Should they have a distinguishable name even if included in the StdLib?

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-)

Filelib: Binary File Support?
Should this be supported?

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.


Filelib: INI File Handling?
Should this be 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.


Filelib: Registry Access?
Should this be supported or is it too special?

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.


Math: std-logbitp or std-bitsetp
Should we define either logbitp or bitsetp?

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.


Math: Support for complex and rational numbers?
Algebraic functions often return multiple values and some of them may be complex. How should algebraic functions return multiple values and complex cases?
If only complex cases are valid should nil be returned?
Should the first found solution, the best or a list of all solutions be returned?

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.


Math: How to deal with exceptions?
"division by zero" or "NaN" for example if correctable. I guess the error should not be attempted to be corrected.

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


Math: Keep exotic functions or provide seperate modules?
There a lot of exotic function rarely used in STDMATH. (elsewhere probably too)

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.


Input: entsel filter list?
(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.


Modules: std-module-unbind deleting symbols?
Should (STD-MODULE-UNBIND module-name) also delete all symbols prefixed with "<module-name>-" and "*<module-name>" and ending "*"?

Such as with the module name "TEST":

TEST-a TEST-x ... and *TEST* *TEST1* ...


Usage:
It should only be used for testing modules, not inside lisp sources!
Pro:
This way strict module and symbol names are forced.
Contra:
It may be the cause of strange errors.

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.