Hi David, Joe,
Vladimir points out in one of the quoted threads that, while nested defuns
may have made some sense in AutoLisp, they actually degrade performance in
Vlisp.
I started using nested defuns in AutoLisp several years ago to minimize
collisions with other functions. Now, with Vlisp, I suppose the thing to do
is leave the defuns global and compile to a vlx file. By exporting only
those functions that are required to be global; i.e., available outside the
vlx, the rest of the functions remain local.
David, I've added comments to your examples below:
"David Doane" wrote in message
news:01bf92eb$7a023c80$36876ace@lms-1...
> Joe,
>
> You probably know more than I about AutoLISP, and everything you know
> about VLISP is more that I know about it, but let's just throw
> something out here for the experts to correct us on. 🙂
>
> This is the way I see it:
>
> (defun C:FUNC (/) a global function - may be called as (c:func) or
> as a command
Agreed
>
> (defun (FUNC (/) a local function - may be called as (func)
Most lisp object snaps are defined this way.
>
> (defun C:FUNC (/ func2) or (defun FUNC (/ func2)
> (defun func2 (/) a nested function that cannot be called except
> from within FUNC as (func2). I would also think that func2 would
> return to nil when the program finished, whereas C:FUNC or FUNC would
> remain in the drawing memory space once loaded.
>
Yes, func2 is declared as local and ceases to exist once C:FUNC or FUNC
completes.
> (defun C:FUNC (/ var1 var2) or (defun FUNC (/ var1 var2)
> (setq var1 ......) a local variable that would return to nil
> (setq var2 ......) a local variable that would return to nil
> (setq var3 ......) a global variable that would remain in the
> drawing memory space.
You've got it.
>
> (defun C:FUNKY (var2 / var4) or (defun FUNKY (var2 / var4)
> var2 is a variable [argument] that must be passed with C:FUNKY or
> FUNKY when calling it, as:
>
Using functions that require arguments, as you've shown here, can greatly
simplify your code. I often use no global vars between my subroutines,
instead passing arguments and returning values. Often my arguments and
return values consist of lists of data. One of the challenges that I find
in using VBA is the difficulty in passing and returning complex argument
lists.
> (c:funky var2) or (funky var2), although the names don't seem to
> have to match. a function such as:
> (defun C:FUNKY (x / var4) or (defun FUNKY (x / var4), or even
> (defun C:FUNKY (nil / var4) or (defun FUNKY (nil / var4) would work
> when called as above.
When I try to load a function with nil as a declared argument, I get an
error message (A2K). A delcared argument must follow AutoLisp's symbol
naming conventions. If nil were allowed as a declared argument it would
result in changing nil's value to something other than nil, resulting in
bugs that would be very difficult to find.
>
> Well, let's see how all that horse pucky flies.
> --
> Dave D
>
>
>
> Joe Funk wrote in article
> <8b6nmo$r8r40@adesknews2.autodesk.com>...
> > Still wondering.
> >
> > I am using VLISP R2000, not AutoLISP.
> <....>
>
