How can I create an empty list?

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 )

 

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

 

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 (()).

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

 

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

Thanks again!
Lucian Crisan )

 

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")



--

-Jason
Member of the Autodesk Discussion Forum Moderator Program

can i remove it from this list.

 

By default, nil is an empty list

(null nil)
T

(listp nil)
T

-David

 

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

 

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
Member of the Autodesk Discussion Forum Moderator Program

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.

 

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.

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.

 

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
)

 

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
)

 

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.

 

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

 

Jason, great minds ...

 

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

 

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.


--

-Jason
Member of the Autodesk Discussion Forum Moderator Program

<snip>

 

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.

 

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.

 

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

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

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

 

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.