Author Topic: To defun or not to defun?  (Read 8224 times)

0 Members and 1 Guest are viewing this topic.

Keith™

  • Villiage Idiot
  • Seagull
  • Posts: 16899
  • Superior Stupidity at its best
To defun or not to defun?
« Reply #15 on: November 24, 2004, 02:23:00 PM »
Quote from: Se7en
I agree with SMadsen, in that that we are saying almost the same thing. But, I was refering to the fact that if you nest your defuns the sub procedure is still availble to you after the main procedure has finished. --For instance:
Code: [Select]
(defun main ()
   (defun sub ()
      (alert "Goodbye!"))
   (alert "Hello there!")
   (sub)
 )

Go ahead and load that up and run 'main'. Now run 'sub'. The procedure isnt localised like a variable is localised. But this is just beating a dead horse...

One of the major reasons for creating 'block-structures' (a procedure with nested procedures) is for creating "true" 'black box' routines/solutions.

Ok im done.


Please note that you DID NOT declare them local. This is exactly what I said previously. If you do not declare them local it makes no difference. This is exactly how the autoload stub function creates the autoload lisp programs.

Quote from: Mark Thomas
Well no one has mentioned compiling yet, so I guess I will. What about compiling with "separate namespace"?

If you compile to a seperate namespace none of the defuns are available EXCEPT those defun'd with C:
It makes absolutely no difference if you declare them local or not in compiled seperate namespace applications.
The location of the defuns are also unimportant (inside vs outside a wrapper function).
Proud provider of opinion and arrogance since November 22, 2003 at 09:35:31 am
CadJockey Militia Field Marshal

Find me on https://parler.com @kblackie

Mark

  • Custom Title
  • Seagull
  • Posts: 28753
To defun or not to defun?
« Reply #16 on: November 24, 2004, 05:50:37 PM »
Quote from: Keith
It makes absolutely no difference if you declare them local or not in compiled seperate namespace applications.
The location of the defuns are also unimportant (inside vs outside a wrapper function).

That's the point I was trying to make.
TheSwamp.org  (serving the CAD community since 2003)

JohnK

  • Administrator
  • Seagull
  • Posts: 10605
To defun or not to defun?
« Reply #17 on: November 26, 2004, 12:32:28 PM »
Ok keith i see what your saying. (Localise the nested procedures in the parameters list.) But I think lazyness has taken over here. (we have been getting lazy when it comes to the correct way to use local procedures.)

There is a lot more to declairing a local procedure then what we have been doing. If your ever in a situation that requires you use defun instead of lambda inside a procedure you need to do a lot more then just declaire a function inside the main. for instance: you dont need to use bound variables. you can then use free variables. making those procedures are truly "local" (In that they opperate on variables inside the main procedure and not on concepts.) That is one of the major points to local procedures.  

There is a lot to this subject; Like other things there are many other ways to accomplish the same task. But if your after a way to "hide" your procedures or create a "true blackbox" routine then you need to read up on the subject more. There is a lot of information on procedure structure(s). look into it if your interisted in it.

Code: [Select]
;;; Create a local function that uses free vars instead of bound.
;;; NOTE: this can be done using lambda alot easier.
;;; Using lambda would make this alot more readable and easier to
;;; maintain in the long run.
(defun main ( / helper var1)
 ;; Create a local function that operates on the variables themselves.
  (defun helper ()
     (setq var1 (+ 1 var1)) )
  ;; Get a number and declaire a variable
  (setq var1 (getint "Enter a number: "))
  ;; chagne the variable
  (helper)
  ;; promt user the new value of the variable
  (prompt var1)
  (princ)
 )
TheSwamp.org (serving the CAD community since 2003)
Member location map - Add yourself

Donate to TheSwamp.org