Jump to content

defun inside another defun


samifox

Recommended Posts

Hi

 

i saw some programmers use (defun) inside (defun),

what is the use of it?

 

i were thinking using it when interacting with user like so :

 

(defun C:de1()
 (setq f t)
 (while f
   (initget 7 "Shay Dan")
   (setq s (getkword "enter a name[shay/Dan]"))

   (cond
     ((eq s "Shay") (shay))
     ((eq s "Dan") (dan))
     (T s)
     )

     )
  

 (defun shay()
   (princ "enter shay")
   (setq f nil)
   )

 (defun dan()
   (princ "enter dan")
   )
)

 

but i get error : no function definition

 

Thanks

Shay

Link to comment
Share on other sites

That's because once the main function is started it loads all data according to its position in the function, if you moved your defun's ahead of the setq's and other code then all should be good. Typically all internal functions are placed above all calling code.

Link to comment
Share on other sites

The example above is not really what I would call a defun inside a defun I have global defuns that get autoloaded so when inside another lisp you do not need the code to be continually repeated. A very simple example could be a global make line defun (linemake pt1 pt2). The sort of thing I used defun inside defun was for a large suite of intergrated lisps so that objects or steps or interface was always consistent across any program in the suite. Often I see better ways of doing things so a global defun means its straight away available for an existing variety of lisps.

 

A better example is using a pline defun to provide all the details about the pline even if it gives extra stuff thats not used. Just copy and paste or call it globally. A 100 plines a 100 calls to the defun.

Link to comment
Share on other sites

what is the use of it?

 

It allows you to create a lisp routine that has no side effects on your drawing namespace.

If you localise names of sub-functions (like you would a local variable) then once the lisp has completed the symbol names that you used will revert to whatever value they were prior to running the lisp. Most of the time that will be 'nil, but not always. And that becomes very important if you are operating in a customised corporate environment. It is common with corporate customisations to define global functions that are available (like a library) to be called from other functions. I think BIGAL is referring to this practice. But countless times I have seen secondary lisps (not part of the corporate customisation) that have the potential to redefine corporate functions with unpredictable side-effects.

I think that the best practice is to define global functions only if they form part of a customisation, but when doing so, use a naming convention that is unlikely to be used by others. eg. use the company name as a prefix to all global functions.

For lisp routines that are not part of a corporate customisation, keep the side-effects of the routine to a minimum. Localise everything you can.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...