Author Topic: Newbie to world of (Lost in Stupid Parentheses) errr..(List)  (Read 101402 times)

0 Members and 1 Guest are viewing this topic.

daron

  • Guest
Newbie to world of (Lost in Stupid Parentheses) errr..(List)
« Reply #45 on: November 05, 2003, 10:48:25 AM »
(defun layer-p (layer)
(and (tblsearch "layer" layer)))

What you do with that is:
(layer-p "andre")
That then will find and return the layer "andre".

amgirard2003

  • Guest
Newbie to world of (Lost in Stupid Parentheses) errr..(List)
« Reply #46 on: November 05, 2003, 10:59:02 AM »
O.K got it now..

Question

(defun layer-p (layer)

In the line above, what is (layer) signifying?

If i'm frustrating you I'm really sorry... just really new to all of this and like i've said i have no programming background what so ever...

JohnK

  • Administrator
  • Seagull
  • Posts: 10648
Newbie to world of (Lost in Stupid Parentheses) errr..(List)
« Reply #47 on: November 05, 2003, 11:32:53 AM »
An "object".

The "layer" represents an argument to the procedure. The "layer-p" procedure needs an object to perform its process on.

Daron, now I'm not entirely sure about this but... (Smadsen, do you know for sure?) When you create a variable name associated with the value of "nil" you are doing two things; One allocating space for a variable and two, destroying it. So as I see it, the variable 'c' is created and destroyed. By telling the interpreter that we are defining a new variable named 'c' we are telling it to allocate memory space for it, but then when we assign it to a value of 'nil' that tells the interpreter to destroy it. So the 'c' variable is nothing more then a flash in the pan.
TheSwamp.org (serving the CAD community since 2003)
Member location map - Add yourself

Donate to TheSwamp.org

nivuahc

  • Guest
Newbie to world of (Lost in Stupid Parentheses) errr..(List)
« Reply #48 on: November 05, 2003, 11:34:48 AM »
When you define a function ('(defun layer-p...') you can add arguments to your function by including the variable name for your argument in the parentheses following the function name. When you write a LISP routine you are going to set variables. Having one of your variables as a required argument essentially requires that the person running the function set the variable for you.

(defun layer-p (layer)

simply says that when a user runs the function layer-p they'll need to supply an argument to go along with it. The argument that they supply will be the value of a variable called, in this instance layer. So, later on in the function, it will do a tblsearch of the layer named with the value of the variable supplied by the user.

In english, the function is doing this 'Check to see that a layer exists in this drawing.'

Naturally, the function needs to know what layer you are referring to so the argument is, in english 'Which layer am I looking for?'

It could have easily been written as

(defun layer-p (required_argument)

Using 'layer' as a variable name is, in my opinion, a bad habit. I try to never name any variable in any of my functions with terminology common to Autocad.


The same can be done for checking a plethora of items like a block:

Code: [Select]
(defun Block-Exists (x)
(and (tblsearch "Block" x))
)



or a text style:

Code: [Select]
(defun TxtStyle-Exists (x)
(and (tblsearch "style" x))
)


or a dimension style:

Code: [Select]
(defun DimStyle-Exists (x)
(and (tblsearch "Dimstyle" x))
)


In those three examples the variable x is the argument provided when running each function. So, in the 'Block' function the second line is doing this, in english:

Check the drawing to see if there is a block named whatever the value of the variable x is in it.

amgirard2003

  • Guest
Newbie to world of (Lost in Stupid Parentheses) errr..(List)
« Reply #49 on: November 05, 2003, 11:50:21 AM »
I understand that better... was a little confused there for a minute

Couldn't you do this as well

(defun layer-p ()
  (tblsearch "layer" "x"))

Not pass a variable and just let tblsearch function look for the layer x

If it finds it then it will result in being "TRUE"
if not then "NIL"

what are your thoughts?

nivuahc

  • Guest
Newbie to world of (Lost in Stupid Parentheses) errr..(List)
« Reply #50 on: November 05, 2003, 11:56:55 AM »
Absolutely.

Having it as a variable makes the function more versatile, though.

You may be looking for layer 'x' today but tomorrow you may want to search for layer 'z'. And if you intend on writing a function for each separate layer that you want to search for it would be simpler to not make the function in the first place and just run

(tblsearch "layer" "x")

(tblsearch "layer" "y")

(tblsearch "layer" "z")

JohnK

  • Administrator
  • Seagull
  • Posts: 10648
Newbie to world of (Lost in Stupid Parentheses) errr..(List)
« Reply #51 on: November 05, 2003, 12:03:38 PM »
Conditional expressions:

The "if" expression allows us to evaluate a value and preform a process based on the results.

(if [predicate] [consequent] [alternative])

If the Predicate is TRUE then do the consequent, else do the alternative.
Code: [Select]
(if
  (Layer-p "612")                 ; <- Predicate
  (setvar "clayer" "612")         ; <- Consequent
  (command "layer" "m" "612" "")  ; <- Alternative    
 )


The "cond" expression lets us evaluate and preform a set of process if the value evaluates to "True".

(cond [predicate] [consequent] [predicate] [consequent] ...)

If the Predicate is TRUE then do the consequent.
Code: [Select]
(cond
  ((Layer-p "612")                 ; <- Predicate
   (setvar "clayer" "612"))        ; <- Consequent
  ((not (Layer-p "612"))           ; <- Predicate
   (command "layer" "m" "612" "")) ; <- Consequent
 )


Code: [Select]
(cond
  ((Layer-p "612")
   ;; If the layer "612" is present in the drawing
   (setvar "clayer" "612"))
   ;; Then set the curent layer to "612"
  ((not (Layer-p "612"))
   ;; If the layer isnt found
   (command "layer" "m" "612" ""))
   ;; Then create it and set it curent
 );_ end conditional expression


Reason to choose "cond" over "if":
A point was made to me by another lisper a bit ago that the use of the "if" expression is fine and dandy but there are better more flexable solutions out there. The point he made was that; "What happens if you decide to preform some more processes later down the road? You would need to reformat your procedure to accomodate them." That was a good point, and that point alone is worth remebering when you design a program. I've tried to get out of the habit of using the "if" expression.
TheSwamp.org (serving the CAD community since 2003)
Member location map - Add yourself

Donate to TheSwamp.org

amgirard2003

  • Guest
Newbie to world of (Lost in Stupid Parentheses) errr..(List)
« Reply #52 on: November 05, 2003, 12:07:10 PM »
So in this case

(defun layer-p (/ x)
  (or (tblsearch "layer" "x")
       (tblsearch "layer" "y")
       (tblsearch "layer" "z")
  )
)

x would be a passed value by user entering something when prompt to do so..

Ex. Asking the user what layer to create?
     The user would enter y

     y is then passed to x
     tblsearch looks for a match to value of x = y
     if y exists which would result in being True
     then user would be prompt with " Layer already exists.

RCJDavis

  • Guest
Newbie to world of (Lost in Stupid Parentheses) errr..(List)
« Reply #53 on: November 05, 2003, 12:08:02 PM »
You know I don't post much, I mostly lurk and read, but wow this is making so much sense.  You guys are going through this with a fine tooth comb.  It should almost get stickied when done, as a great reference of where to begin.  Thanks to everyone who's working on this I am learning so much!

nivuahc

  • Guest
Newbie to world of (Lost in Stupid Parentheses) errr..(List)
« Reply #54 on: November 05, 2003, 12:12:36 PM »
Another reason, posed to me by the person who taught me about 'cond':

What if, in your infinite wisdom, you hadn't considered something that the user might have done? Your lines and lines of possible scenarios within those if/then statements would be useless.

'Cond' lets you cover all of the bases by adding a final predicate of 'T' which, essentially, means 'if none of my other predicates are true, do this instead'.

nivuahc

  • Guest
Newbie to world of (Lost in Stupid Parentheses) errr..(List)
« Reply #55 on: November 05, 2003, 12:32:02 PM »
Quote from: amgirard2003
So in this case

(defun layer-p (/ x)
  (or (tblsearch "layer" "x")
       (tblsearch "layer" "y")
       (tblsearch "layer" "z")
  )
)

x would be a passed value by user entering something when prompt to do so..

Ex. Asking the user what layer to create?
     The user would enter y

     y is then passed to x
     tblsearch looks for a match to value of x = y
     if y exists which would result in being True
     then user would be prompt with " Layer already exists.


No.

Actually, placing the x after the '/' changes it completely. The function won't be requiring anything from the user.

Required arguments are placed before the '/'.

Check your books and try to find out what the purpose of placing them behind that slash is.

amgirard2003

  • Guest
Newbie to world of (Lost in Stupid Parentheses) errr..(List)
« Reply #56 on: November 05, 2003, 12:36:07 PM »
placing a variable after the / makes it local to that function
placing it in front of the / makes it global.. so therefore other function could refer to the variable..

am i right or wrong on this one?

nivuahc

  • Guest
Newbie to world of (Lost in Stupid Parentheses) errr..(List)
« Reply #57 on: November 05, 2003, 12:41:58 PM »
Close.

You're correct about the local variables. Placing it behind the slash 'empties' that variable once the function is complete.

Placing a variable before the slash declares it as a required argument.

Making a variable global is as simple as not including it in the list following the slash. A mistake that many novice programmers make.

daron

  • Guest
Newbie to world of (Lost in Stupid Parentheses) errr..(List)
« Reply #58 on: November 05, 2003, 12:42:57 PM »
Quote from: Se7en
Daron, now I'm not entirely sure about this but... (Smadsen, do you know for sure?) When you create a variable name associated with the value of "nil" you are doing two things; One allocating space for a variable and two, destroying it. So as I see it, the variable 'c' is created and destroyed. By telling the interpreter that we are defining a new variable named 'c' we are telling it to allocate memory space for it, but then when we assign it to a value of 'nil' that tells the interpreter to destroy it. So the 'c' variable is nothing more then a flash in the pan.


Yes, you allocate memory space for it, but you are also defining it. If you run my three line question on it, the first line sets the variable to nil. The second line (the first append) crashes. The third line runs okay. I stated why I changed a and b to a list, but I'll clarify: They are integer values, or strings, or longs, or whatever, but they are NOT a list. The value of c is nil. What else is it? It works in an append situation without being called as a list, even though there is nothing to append to. So, I ask again, when you define a variable as nil, what is the object (container) of c? What does c become? Not nothing. Not destroyed. Not a flash in the pan.

amgirard2003

  • Guest
Newbie to world of (Lost in Stupid Parentheses) errr..(List)
« Reply #59 on: November 05, 2003, 12:49:49 PM »
Originaly posted by Daron,
Yes, you allocate memory space for it, but you are also defining it. If you run my three line question on it, the first line sets the variable to nil. The second line (the first append) crashes. The third line runs okay. I stated why I changed a and b to a list, but I'll clarify: They are integer values, or strings, or longs, or whatever, but they are NOT a list. The value of c is nil. What else is it? It works in an append situation without being called as a list, even though there is nothing to append to. So, I ask again, when you define a variable as nil, what is the object (container) of c? What does c become? Not nothing. Not destroyed. Not a flash in the pan.
***********************************************************

Wouldn't c always = nil... not empty, not a flash in the pan, not destroyed