How can I create an empty list?

[lucic]

How can I create an empty list?
I need to construct a list of strings, and i need an empty list at first time. I've try with (list ' ) but return a list with nil item > (nil) and i don't know how can i remove it from this list.

Many thanks!
Lucian Crisan )

 

[Tom Berger]

How can I create an empty list?
I need to construct a list of strings, and i need an empty list at first time. I've try with (list ' ) but return a list with nil item > (nil) and i don't know how can i remove it from this list.

You don't need an empty list to start building a list.

(setq mystr "Test")
(setq mylist (cons mystr mylist))

If you really want to have an empty list (there is definitely no reason for it, then use (setq mylist ')

Tom Berger

 

[Tom Smith]

You're doing the same thing twice.

Either (set mylist (list)) or (setq mylist ') will create an empty list. An empty list always evaluates nil, you won't see the empty parentheses.

Your (setq mylist (list ') is actually creating ().

How can I create an empty list?
I need to construct a list of strings, and i need an empty list at first time. I've try with (list ' ) but return a list with nil item > (nil) and i

don't know how can i remove it from this list.

 

[lucic]

Thanks a lot Mr. Smith, this information really help me! I was wondered and surprised for the feedback time!

Thanks again!
Lucian Crisan )

 

[Jason Piercey]

You probably don't need any empty list to start with.
I see people here start with an empty list all the time, not really needed.

Command: !lst
nil

Command: (setq lst (cons "b" lst))
("b")

Command: (setq lst (cons "c" lst))
("c" "b")

How can I create an empty list?
I need to construct a list of strings, and i need an empty list at first time. I've try with (list ' ) but return a list with nil item > (nil) and i don't know how

can i remove it from this list.

 

[David Bethel]

By default, nil is an empty list

(null nil)
T

(listp nil)
T

-David

 

[ECCAD]

Jason,
I use 'lists' within a function, called several times. I always use (setq lst nil) on entrance. Reason, if I have been there, the 'lst' contains 'old' data. Best to nil, then (setq lst (cons var lst)) - when stacking var strings. Assures fresh data each time.

Bob

 

[Jason Piercey]

Bob,

If I understand you correctly, also not necessary as
the arguments and variables are local to the function.

Example:

the variable lst is already defined
Command: !lst
("c" "b")

(defun test (arg / lst)
(setq lst (cons arg lst))
)

Command: (test "d")
("d")

Command: !lst
("c" "b")

Notice you do not get ("d" "c" "b")

Jason,
I use 'lists' within a function, called several times. I always use (setq lst nil) on

entrance. Reason, if I have been there, the 'lst' contains 'old' data. Best to nil, then (setq lst (cons var lst)) - when stacking var strings. Assures fresh data each time.

 

[Tom Smith]

Not necessary if lst is declared local to the function and the variable name isn't reused. Reusing a variable name (there's a technical term for that, which I forget) might theoretically be a small efficiency, but IMHO it can make the code less readable and adds the extra necessity of nulling out the variable for reuse.

It's partly a personal style thing, but over the years I've found that giving mnemonic names to variables - as long as they need to be to be clear - is a huge benefit to being able to understand and reuse or modify the code in the future. What seems cleverly efficient today can be a big time-killer 3 years from now.

I'd rather use "layer_name_list" and "ename_list" (for example, selecting the variable names to be meaningful in the context of the function) and declare them both local than use "lst" for both.

Jason,
I use 'lists' within a function, called several times. I always use (setq

lst nil) on entrance. Reason, if I have been there, the 'lst' contains 'old' data. Best to nil, then (setq lst (cons var lst)) - when stacking var strings. Assures fresh data each time.

 

[Tom Smith]

If I understand correctly, you're using lst as a global variable to pass data between functions. Again, it's partly a matter of style, but I prefer to avoid globals, and if I really need to use one, I use a very distinctive name to keep the variable from being stomped by another function, for example "*machine_parts_list*" -- I use the convention that any global has asterisks so it stands out in the code.

In your example, all you need to do is force the list to BE the return value of the function, then it can be local.

(defun read_parts ( / rd_lin lst)
;etc
;etc
(close fil)
lst
)

 

[Jason Piercey]

Not sure I completely understand... but couldn't you
put 'lst' at the end of the function and localize it?

(defun read_parts ( / rd_lin lst)
(setq lst nil); return new list each time
(setq fil (open filename "r"))
(while (setq rd_lin (read-line fil))
(if (= part rd_lin)
(setq lst (cons rd_lin lst)); parsed later
))
(close fil)
lst
)

 

[Doug Broad]

Bob,
Though I sometimes use global vars in that manner, it
is not a good general practice. Each function can return a value to its calling function without using globals. The last expression in the function becomes its return value.

Using local variables has big advantages in large systems. Instead of passing by globals, take advantage of the last expression in the function to return a value. If a function returns more than one value, consider a list or consider dividing the function into parts.

 

[ECCAD]

Ya,
I could I suppose. Either way does the job.
Bob

 

[Tom Smith]

Jason, great minds ...

 

[ECCAD]

Doug, Tom, Jason,
Let's not beat this to death. In my sample, I could have just returned the 'lst. Not the real name of the list anyway. I set a global 'list' of machine parts, sometimes 4000 to 5000 records. Pass this to a function that parses (text), and makes (7) more lists..Detail_number, Manufacturers_Name, Part_number, Part_description, Index_number, Spare_data1, Spare_data2. IF the 'lst is nil, I know I have to read-in the catalog, IF not nil, I have it in memory (for this session). I use these lists to pick a 'part' from a 'catalog' of all parts, by using Dialogs to list by Part_type, then, Manufacturer, then, by Part_number & Description. Last pick (of 3) gets the part I want. Tokens placed in a 'part-stamp' block insert. Your input is GOOD. Just my 'old' habits and the way I code. No problemo. Hope this clears up the questions.

Bob

 

[Jason Piercey]

Bob,

Wasn't my intention to 'beat it to death'. Hope it didn't come off that way. Just trying to pass on the knowledge that I have gained from this group.

Doug, Tom, Jason,
Let's not beat this to death.

<snip>

 

[Phil Kenewell]

An additional thing that I do to clear up memory in Lisp code (especially when I have a large number of routines loaded) is wrap up or "nest" small functions within the body of a larger defun, such as functions design to activate in an (action_tile) statement. Then I name the nested function in the local variable list. When I do this, Visual Lisp treats the nested functions the same as local variables and clears them when the main function has ended. I also run the (gc) function within a standard exit handler I use to clean up as much memory as possible.

 

[Tom Smith]

Bob, I apologize if we seemed to "pile on" -- this thread strayed away from the original empty list! But sometimes it's in the little picky details that good tips gets passed along. I've learned a lot in here, and years ago learned tons from mostly the same group of people, back in the old CompuServe forums. Anne ran that too until it shut down.

One of the downsides of the NG as opposed to the old forums, IMHO, is that there's usually a lot less discussion of programming at the "philosophical" level, which is where I found by far the most benefit. In the NG it's mostly a focus on a quick fix of an immediate problem, and (as in this case) it's unlikely that the original poster will ever look back again, after he thinks he's gotten his question answered.

 

[Doug Broad]

Bob,
The person posting the question was obviously a beginner at coding.

Those of us posting regularly should expect others to
contradict us or point out better ways should our suggestions fall outside the realm of recommended programming practice.

It is even wiser to thank those doing so rather than react negatively or impatiently with them.

As far as the original poster, the empty list can be represented by
1) nil
2)
3) using local variables which are initialized to nil.
4) knowing that any unbound variable equals the empty list.
5)(list)
6) any function that returns nil

Doug, Tom, Jason,
Let's not beat this to death. In my sample, I could have just returned the 'lst. Not the real name of the list anyway. I set a global 'list' of machine parts, sometimes 4000 to 5000 records. Pass this to a function that parses (text), and makes (7)

more lists..Detail_number, Manufacturers_Name, Part_number, Part_description, Index_number, Spare_data1, Spare_data2.

IF the 'lst is nil, I know I have to read-in the catalog, IF not nil, I have it in memory (for this session). I use these lists to pick a 'part' from a 'catalog' of all parts, by using Dialogs to list by Part_type, then, Manufacturer, then,

by Part_number & Description. Last pick (of 3) gets the part I want. Tokens placed in a 'part-stamp' block insert.

 

[Tom Smith]

Phil, I do the same, though it will cause a harmless error on compilation. One advantage is that a variable like Bob's list can be shared among the various functions and still be local to the larger program.

Still, though, it's almost always clearer and less buggy to declare all variables local to whatever function creates them, design each function for an appropriate return, and to pass returned values. If you can figure out a way, that is.