conditionals in elisp

conditionals in elisp

[Harry Putnam]

I'm hoping someone will be kind enough to demonstrate a couple of
brief conditionals in elisp... if and if else.

This may be a chintzy way to do it but I really do not want to pound
away at elisp intro and the elisp manual for hours.  I usually
start seeing red at the 4-5 paragraph and usually have been able to
learn what I needed to know in things like perl and shell scripting
from  just a few real live examples that do something at least close
to what I am trying then I can edit and tinker until I start to sort
of `get it'.

In this case, I thought I'd like to start 2 instances of emacs and in
each instance start the server on different names. 1 to do nothing but
run gnus from several remotes and the localhost.. and 2, for a
programming/editing instance also to connect from several remotes and
local.

That is, not try to do both in the emacs running gnus.

I know how to start daemons with different names... from cmdline or on
X start up or whatever, ... but here I want to start them from a running
instances of emacs.

Anyway cutting to the chase... tried writing an  *.el file to load
when I'm ready,  that would be something like:

cat .srvr.el

  (load-library "server")
  (setq server-name "gnus")
  (server-mode)

Then from each emacs instance do: Eval: (load-file "/home/reader/.srvr.el")

I learned that things need to happen in that order (from a running
emacs) from devs on the devel list. 

However since `server-mode' is a toggle... I thought I probably should
test for whether it is already enabled, so I don't end up turning it off. 

Maybe test to see if `server.el' is already loaded too... if that
makes sense to do.

That's when I bumped into my ignorance, realizing I had no idea how to
write simple conditionals that would do this: (over verbosified for
clarity)

(The variable in the if clause is imaginary)

  (load-library "server")
  (setq server-name "name")
  if (! server-mode-enabled){  
     (server-mode)
  }

Probably at risk of showing the horrible bleak depths of my
ignorance... but I hope you get the idea... and hope further that it
even makes any sense at all...

Even if doing it the way I mention above makes no sense.. I would like
to know the better way of course, but would still like to see a couple
of simple elisp conditionals that do something simple.

Re: conditionals in elisp

[Pascal J. Bourguignon]

Harry Putnam <reader@newsguy.com> writes:

> I'm hoping someone will be kind enough to demonstrate a couple of
> brief conditionals in elisp... if and if else.
>
> This may be a chintzy way to do it but I really do not want to pound
> away at elisp intro and the elisp manual for hours.  I usually
> start seeing red at the 4-5 paragraph and usually have been able to
> learn what I needed to know in things like perl and shell scripting
> from  just a few real live examples that do something at least close
> to what I am trying then I can edit and tinker until I start to sort
> of `get it'.

Then why wouldn't you write a perl script to find some .el files on
your hard disk, and see if there's not some instances of if
expressions in them?


-- 
__Pascal Bourguignon__

Re: conditionals in elisp

[Richard Riley]

Harry Putnam <reader@newsguy.com> writes:

> I'm hoping someone will be kind enough to demonstrate a couple of
> brief conditionals in elisp... if and if else.
>
> This may be a chintzy way to do it but I really do not want to pound
> away at elisp intro and the elisp manual for hours.  I usually
> start seeing red at the 4-5 paragraph and usually have been able to
> learn what I needed to know in things like perl and shell scripting
> from  just a few real live examples that do something at least close
> to what I am trying then I can edit and tinker until I start to sort
> of `get it'.

I recommend Xah Lee's elisp tutorial if you are already a programmer and
just want to dive in.

RE: conditionals in elisp

[Drew Adams]

> I'm hoping someone will be kind enough to demonstrate a couple of
> brief conditionals in elisp... if and if else.

We are plenty kind enough. Kindness is not the problem.

> This may be a chintzy way to do it but I really do not want to pound
> away at elisp intro and the elisp manual for hours. 

You're exaggerating. Did you even try "pounding away" at it for the 2 minutes it
took you to write your question and mail it?

> That's when I bumped into my ignorance, realizing I had no idea how to
> write simple conditionals that would do this: (over verbosified for
> clarity)
>
>   (load-library "server")
>   (setq server-name "name")
>   if (! server-mode-enabled){  
>      (server-mode)
>   }

There's no shame in ignorance. Laziness is another matter.

1. Don't waste people's time here if you are unwilling to even look up `if' or
`conditional' in the Elisp manual. That's ridiculous.

2. Learn to find your way around Emacs _before_ trying to learn Emacs Lisp. This
means learning, at a minimum, `C-h i', then `i' in a manual to look things up in
the index.

3. There is no substitute for this. No matter how much people here try to "help"
you, you will waste your _own_ time if you don't learn how to _ask Emacs_. And
sooner or later, people here will tire of answering, if they see you making zero
effort.

Here's how hard it is:

1. `C-h i'
2. Click the link to the `Elisp' manual.
3. `i', then `if', then Enter.
4. Read one page of doc about `Conditionals'.

Can you handle that?

If you only partially understand what you read, try something based on what you
think you understand: `M-:', then type some expression you think might work,
from what you read. Emacs and Emacs Lisp are 100% interactive - you get
immediate feedback. Best way to learn.

If you don't understand what you read at all, and you need more help, ask here.
There's no shame in asking, ever. But for your _own_ sake, learn to interact
with Emacs itself. You will not regret it.

The best rule, for _you_, is this: _ask Emacs_. It's the best rule in the long
run, because it will mean that your questions here will be more informed, which
means people will be more willing to help you.

HTH.

Re: conditionals in elisp

[LanX]

Joe Brenner has a nice elisp <-> perl comparison table, which helped
me a lot:

http://obsidianrook.com/devnotes/elisp-for-perl-programmers.html

BTW: first hit googling "elisp perl" 8)

Re: conditionals in elisp

[Harry Putnam]

"Drew Adams" <drew.adams@oracle.com> writes:

> 3. There is no substitute for this. No matter how much people here try to "help"
> you, you will waste your _own_ time if you don't learn how to _ask Emacs_. And
> sooner or later, people here will tire of answering, if they see you making zero
> effort.

> Here's how hard it is:
>
> 1. `C-h i'
> 2. Click the link to the `Elisp' manual.
> 3. `i', then `if', then Enter.
> 4. Read one page of doc about `Conditionals'.
>
> Can you handle that?

Drew, not to be a smartmouth here but do you really know for sure that
what you say is the absolute best way for me to learn reall is?

Are you really so sure I don't know myself better than you do?

I can say for certain that after just half a page under 10.2
Conditionals and my head is spinning.

The stuff there does not match up to what little programming I've
learned of perl shell etc.  Or if it does... I'm not seeing it yet.

You have no idea, really of how slow and painful the little computer
literacy I've acquired has come.

You think I haven't looked here before... your wrong.

I've tried to follow a few things in that manual for yrs.  I know it
looks and sounds like gibberish to me after just a little reading.

That hasn't stopped me from doing lots of work with emacs over the last
10-12 yrs.  At least work at my level..  I'm talking hobby level.
I've never aimed at employment or the like... I made my living with my
hands... and now retired..

I must have some kind of learning problem or such and a pretty deep
seated one too ... but at my age I do know something about how
learning works for me.  I'm not going anywhere reading the manual with
out some simple examples I can look at and see how they work.

I don't really care to go on making an argument... and I appreciate
you taking time to try to help.. as you have with me and others many
many times before.  

Examples work best for me, I tried to explain that in OP.  The fact
that you think that manual page should do it for me, does not make it
so.  

Thanks for your time.  That will be the end of my comments on this.

I have yet to go through all the other suggestions.  Many thanks for
the input posters...

Re: conditionals in elisp

[tomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mon, Oct 26, 2009 at 07:08:13PM -0500, Harry Putnam wrote:
> I'm hoping someone will be kind enough to demonstrate a couple of
> brief conditionals in elisp... if and if else.

While the other posters sound harsh, they just are trying to provide you
with some fishing rods, instead of the fish you asked for (sorry, I
couldn't resist).

Lest you starve in the process, and because I have the suspicion that
there is just a little specific tangle between you and the docs, here is
a fish (with a bit of fishing line attached to it): in Lisp, everithing
is an expression. There are no "statements", as you might be accustomed
to from other languages. All those "control staatements" are just
expressions. If looks like that:

  (if lunchtime
    (eat fish)
   (work this)
   (work that)
   (procrastinate a-bit))

The meaning of that is: if the value of the variable "lunchtime" can be
interpreted as "true" (i.e. is not nil), evalate the first expression
(i.e. (eat fish). Otherwise evaluate the sequence coming after that
(i.e. first (work this) and so on). The whole thing returns a value (you
don't really say that in Lisp world: you rather say "the if expression
evaluates to"). This is the value of (eat fish) in the first case, the
value of the last expression in the else part (i.e. (procrastinate a-bit) 
in the second case.
 
Of course you may replace the variable lunchtime by a more grown-up
expression:

  (if (eq (current-time) 'lunchtime)
    (whatever)
   (others))

If you want to do more work than one expression, have a look at prog1
and progn, which allow you to wrap a whole sequence of expressions in
one.

Of course, the pointers given to you in this thread are all very
valuable. Especially, the tutorials by Xah mentioned will take you much
further than this, and peeking into all the sources provided with Emacs
can't be substituted by any well meaning post.

Regards
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFK5ooMBcgs9XrR2kYRAogWAJoChrDGFCWUpQvfqzcEUAYddO13MQCeJbkZ
vUsrlFC4J3iJ2sP9aHCPQcA=
=eocn
-----END PGP SIGNATURE-----

RE: conditionals in elisp

[Drew Adams]

>> If you only partially understand what you read, try
>> something based on what you think you understand:
>> `M-:', then type some expression you think might
>> work, from what you read. Emacs and Emacs Lisp are
>> 100% interactive - you get immediate feedback.
>> Best way to learn.
>> 
>> If you don't understand what you read at all, and
>> you need more help, ask here. There's no shame in
>> asking, ever. But for your _own_ sake, learn to
>> interact with Emacs itself. You will not regret it.

> I can say for certain that after just half a page under 10.2
> Conditionals and my head is spinning.
> The stuff there does not match up to what little programming I've
> learned of perl shell etc.  Or if it does... I'm not seeing it yet.

OK. I apologize for assuming that you were looking for a quick answer here
instead of looking to learn.

Learning from examples is fine - very good, in fact. Others have already
provided you examples, so I hope that helped. The quick and easy answer would
have been to just give you a couple examples to learn from. You can evaluate
each expression by typing it after `M-:' and hitting Enter.

(if) raises an error: wrong number of arguments - 0 
(if nil) raises an error: wrong number of args - 1
(if nil 3)                -> nil
(if t   3)                -> 3
(if nil 3 4)              -> 4
(if t   3 4)              -> 3
(if nil 3 4 5)            -> 5
(if t   3 4 5)            -> 3
(if nil 3 4 5 6)          -> 6
(if "anything but nil" 3) -> 3
(if "nil" 3)              -> 3
(if 99 3 "anything")      -> 3
(if nil 3 (setq a 5) a)   -> 5

And maybe some more would help. But I'm sure others have helped enough on this
score.

The point remains, however: to learn, you need to dialog with Emacs itself. Not
to try that is to not learn the first thing about Emacs: it's helpful and
interactive.

Even if reading manuals is not your thing, you need to learn how Emacs itself
can help you: how to find the value of a variable; how to find what the
arguments to a function are; and so on. `C-h v' and `C-h f' are your friends.
These and other friends are all in the `Help > Describe' menu.

`M-:' is your friend. You can use it to evaluate any Emacs-Lisp expression, just
to see what happens. Try it - you can't break anything. If you find yourself in
the debugger because evaluation raised an error, just hit `q' to get back out.
Try it:

M-: (if)
M-: (if t)
M-: (if some-variable)

The error messages can also help you learn. Try, fail, succeed, fail, learn.
Know too that `C-g' cancels the action in progress and any crazy state you might
find yourself in - it returns you to the top level, where you want to be. Repeat
it if necessary: `C-g C-g'...

Even so, you will do yourself a big favor if you make occasional forays into the
Emacs manual, and even the Elisp manual. Run away when it seems to be gibberish,
sure, but keep diving back into it - some places are easier than others. Things
that are more helpful when you're starting out are generally nearer the
beginning of the manual.

In this case, if the `Conditionals' page was gibberish to you, try to understand
why. Maybe you lack some more basic understanding, so it would help to first get
some info about more basic stuff in Emacs Lisp. What does a truth (boolean)
value look like in Lisp, for instance? What are the paretheses all about? What
does a string look like? a variable?

There are a lot of such basic questions that are helpful places to start. And
yes, the manual is your friend for such things. In this case, asking the
manual's index about `true' would help you: `i true' takes you to the page that
explains truth values in Emacs Lisp, page `nil and t'. `i false' takes you to
the same page. The page is short, and I'll bet it clears up a few questions you
might have.

But if even that page is too hard, then ask Emacs questions about the terms
there that seem confusing to you. Ask about `variable'. Ask about `list'. Ask
about `quote'. You get the idea. The answers to your questions are really there,
and in some cases in language that you can understand. The problem is to find
the right pages to read - pages that make sense to you at your current level of
knowledge/ignorance. Skip over any stuff you cannot yet understand, and try to
find stuff you do understand.

But to do that you need, as a start, to feel comfortable asking Emacs. So the
first step is to find out how to ask Emacs. That's why I stressed learning that
first - before trying to learn Emacs Lisp. I don't mean learning Emacs; I
meaning learning to use Emacs to ask Emacs itself questions. Then you can ask it
about Emacs Lisp, for example.

`C-h i' is your friend; it puts you into a manual. But how to get around inside
a manual? If that's a problem, then start with the manual about reading manuals:
`Info'. (It's a bit verbose, but it can help.) In general, `i' (the index) is
your best friend inside a manual. `i variable', `i list' `i quote', `i
evaluation', even `i give up' - Emacs lets you know you cannot give up: "No
`give up' in index" - there ain't no such thing.

If the language and formatting of the Elisp manual is itself confusing, see page
`Conventions' (`g conventions'; `i conventions' won't get you there,
unfortunately). Page `nil and t' is part of the `Conventions' explanation.

You can also start with the Emacs tutorial: `C-h t' (menu Help > Emacs
Tutorial). That leads you through practice exercises. Again, it's a bit verbose,
but it can help.

Believe me, my intent was not to just throw the book at you, but to help. You
need to interact with Emacs itself _about learning Emacs_ and Lisp - that's the
key. There is nothing Emacs likes to talk more about than itself. And there's no
one who knows Emacs better than Emacs knows itself. The doc is sometimes wrong
or poorly worded, but `M-:' never lies.

A lot of Emacs's explanations will not be verbose gibberish. Explore the `Help >
Describe' menu, and you will see that much of that help is short and to the
point. `C-h b' gives you a list of all key bindings currently in effect - few
wasted words. `C-h k' tells you what any key, mouse action, or menu item does.

The first thing to try to find out about Emacs is not the syntax of particular
Emacs-Lisp expressions. It's how Emacs can help you find out about Emacs and
Lisp. Start with the `Help' menu (or the tutorial or the `Info' manual).

And please continue to ask questions here. Don't misunderstand my reply as
simply `RTFM'. My message is to bring Emacs itself into your circle of friends -
s?he can help; you just need to know how to ask.

 

Re: conditionals in elisp

[Pascal J. Bourguignon]

LanX <lanx.perl@googlemail.com> writes:

> Joe Brenner has a nice elisp <-> perl comparison table, which helped
> me a lot:
>
> http://obsidianrook.com/devnotes/elisp-for-perl-programmers.html
>
> BTW: first hit googling "elisp perl" 8)

Obviously, google is too hard for the OP, if he cannot be bothered to
read the minimum about emacs...

-- 
__Pascal Bourguignon__

Re: conditionals in elisp

[Richard Riley]

pjb@informatimago.com (Pascal J. Bourguignon) writes:

> LanX <lanx.perl@googlemail.com> writes:
>
>> Joe Brenner has a nice elisp <-> perl comparison table, which helped
>> me a lot:
>>
>> http://obsidianrook.com/devnotes/elisp-for-perl-programmers.html
>>
>> BTW: first hit googling "elisp perl" 8)
>
> Obviously, google is too hard for the OP, if he cannot be bothered to
> read the minimum about emacs...

The OP was looking for a quick lookup programmers guide to common elisp
constructs. The elisp manual is not really quite so convenient : good
though it can be.

People frequently want to modify an existing feature without learning
the entire emacs infrastructure.

Pointing to existing code is one such way to help. Suggesting he parse
it all with perl probably not quite so helpful ..

Personally whenever I revisit elisp I find Xah Lee's tutorial helpful at
times.

Re: conditionals in elisp

[Pascal J. Bourguignon]

Richard Riley <rileyrgdev@gmail.com> writes:

> pjb@informatimago.com (Pascal J. Bourguignon) writes:
>
>> LanX <lanx.perl@googlemail.com> writes:
>>
>>> Joe Brenner has a nice elisp <-> perl comparison table, which helped
>>> me a lot:
>>>
>>> http://obsidianrook.com/devnotes/elisp-for-perl-programmers.html
>>>
>>> BTW: first hit googling "elisp perl" 8)
>>
>> Obviously, google is too hard for the OP, if he cannot be bothered to
>> read the minimum about emacs...
>
> The OP was looking for a quick lookup programmers guide to common elisp
> constructs. The elisp manual is not really quite so convenient : good
> though it can be.
>
> People frequently want to modify an existing feature without learning
> the entire emacs infrastructure.
>
> Pointing to existing code is one such way to help. Suggesting he parse
> it all with perl probably not quite so helpful ..
>
> Personally whenever I revisit elisp I find Xah Lee's tutorial helpful at
> times.

Whatever.  Results 1 - 50 of about 151,000 for emacs lisp cheatsheet. (0.58 seconds) 
                                                                       ^^^^^^^^^^^^
Notice how google is much faster than typing one's question on the newsgroups...

-- 
__Pascal Bourguignon__

Re: conditionals in elisp

[Richard Riley]

pjb@informatimago.com (Pascal J. Bourguignon) writes:

> Richard Riley <rileyrgdev@gmail.com> writes:
>
>> pjb@informatimago.com (Pascal J. Bourguignon) writes:
>>
>>> LanX <lanx.perl@googlemail.com> writes:
>>>
>>>> Joe Brenner has a nice elisp <-> perl comparison table, which helped
>>>> me a lot:
>>>>
>>>> http://obsidianrook.com/devnotes/elisp-for-perl-programmers.html
>>>>
>>>> BTW: first hit googling "elisp perl" 8)
>>>
>>> Obviously, google is too hard for the OP, if he cannot be bothered to
>>> read the minimum about emacs...
>>
>> The OP was looking for a quick lookup programmers guide to common elisp
>> constructs. The elisp manual is not really quite so convenient : good
>> though it can be.
>>
>> People frequently want to modify an existing feature without learning
>> the entire emacs infrastructure.
>>
>> Pointing to existing code is one such way to help. Suggesting he parse
>> it all with perl probably not quite so helpful ..
>>
>> Personally whenever I revisit elisp I find Xah Lee's tutorial helpful at
>> times.
>
> Whatever.  Results 1 - 50 of about 151,000 for emacs lisp cheatsheet. (0.58 seconds) 
>
^^^^^^^^^^^^

cheatsheet? I would never have thought of using that word. Would many
programmers? Most people look up "reference" or "tutorial". Sometimes
people get flustered and lost and need human interaction. The op was
polite and looking for pointers.

> Notice how google is much faster than typing one's question on the
> newsgroups...

Makes one wonder why the groups are here eh? You know .. to ask people
in the know and maybe pick up a few pointers and friendly suggestions on
how best to proceed. That kind of thing.

You should set up an auto "RTFG" response.

cheers,

r.

Re: conditionals in elisp

[Pascal J. Bourguignon]

Richard Riley <rileyrgdev@gmail.com> writes:

> pjb@informatimago.com (Pascal J. Bourguignon) writes:
>
>> Richard Riley <rileyrgdev@gmail.com> writes:
>>
>>> pjb@informatimago.com (Pascal J. Bourguignon) writes:
>>>
>>>> LanX <lanx.perl@googlemail.com> writes:
>>>>
>>>>> Joe Brenner has a nice elisp <-> perl comparison table, which helped
>>>>> me a lot:
>>>>>
>>>>> http://obsidianrook.com/devnotes/elisp-for-perl-programmers.html
>>>>>
>>>>> BTW: first hit googling "elisp perl" 8)
>>>>
>>>> Obviously, google is too hard for the OP, if he cannot be bothered to
>>>> read the minimum about emacs...
>>>
>>> The OP was looking for a quick lookup programmers guide to common elisp
>>> constructs. The elisp manual is not really quite so convenient : good
>>> though it can be.
>>>
>>> People frequently want to modify an existing feature without learning
>>> the entire emacs infrastructure.
>>>
>>> Pointing to existing code is one such way to help. Suggesting he parse
>>> it all with perl probably not quite so helpful ..
>>>
>>> Personally whenever I revisit elisp I find Xah Lee's tutorial helpful at
>>> times.
>>
>> Whatever.  Results 1 - 50 of about 151,000 for emacs lisp cheatsheet. (0.58 seconds) 
>>
> ^^^^^^^^^^^^
>
> cheatsheet? I would never have thought of using that word. Would many
> programmers? Most people look up "reference" or "tutorial". Sometimes
> people get flustered and lost and need human interaction. 

Of course, normal people search tutorials or references.   
People in a hurry may look at cheatsheets.

I can hardly qualify people who ask something mentionning that they
don't care to learn the first thing about what they ask.  I find this
behavior quite irritating.


> The op was polite and looking for pointers.

He has received polite answers.


>> Notice how google is much faster than typing one's question on the
>> newsgroups...
>
> Makes one wonder why the groups are here eh? You know .. to ask people
> in the know and maybe pick up a few pointers and friendly suggestions on
> how best to proceed. That kind of thing.
>
> You should set up an auto "RTFG" response.

Well, we'd have to assume that usenet users would be interested in the
topic of the discussion.  Again, what do you think of somebody who
starts by stating that they're not interested by the topic of the
discussion?


Otherwise, the heuristic would be to first try several keywords
combinations with google, and if nothing comes out, then go to the
concerned newsgroup to ask for help (mentionning the keywords tried
with google).  

The answer may then be a hint on the right keywords, or may have more
semantic contents, when indeed it's not a purely syntactic question
that could be answered by google.  

Asking google first would save everybody a lot of time, resources and
energy, allowing us to give even better answers when they indeed
cannot be found in the existing "literature".



-- 
__Pascal Bourguignon__

Re: conditionals in elisp

[Sean Sieger]

    The OP was looking for a quick lookup programmers guide to common elisp
    constructs. The elisp manual is not really quite so convenient : good
    though it can be.

    People frequently want to modify an existing feature without learning
    the entire emacs infrastructure.

    Pointing to existing code is one such way to help. Suggesting he parse
    it all with perl probably not quite so helpful ..

    Personally whenever I revisit elisp I find Xah Lee's tutorial helpful at
    times.

Look at me!  I can challenge a knowledgeable contributor!  (One whose
depth of knowledge is clearly illustrated in the archives.)

One day you'll get off the fence and know your limitations as a
contributor or as a troll and become decidedly one or the other.  My
guess is that you need a role model that is a better fit than Xah.

Re: conditionals in elisp

[Harry Putnam]

pjb@informatimago.com (Pascal J. Bourguignon) writes:

[...]

> Whatever.  Results 1 - 50 of about 151,000 for emacs lisp
> cheatsheet. (0.58 seconds) ^^^^^^^^^^^^

Aside from being horribly lazy, not to mention stupid... I'm also
apparently blind.... I asked about `if else conditionals'... and using
a string I would never have thought of to search for that topic I
repeated your search..finding in a blazing .58 second... exactly 0
references to that topic (at least in the first two pages).

I'll admit I gave up after the second page... Oh, wait I take it
back, there is mention of your posts on this thread.  But then, those
don't mention anything about the topic either.

> Notice how google is much faster than typing one's question on the
> newsgroups...

I think your confusing lookup time with the time it will really take
to find a recognizable `if else' example with that search... or many
others, I'd already tried myself.

That time (for me) would be vastly larger than posting here.

I wasn't thinking, tutorial either, since, again I've tortured myself
with a few in the past. And a tutorial by its nature will take in a
lot more than what I was after.  I wanted examples... and that is what I
posted about.

In fact I see now that looking for something similar to `if else' in
perl or shell scripting is really a mistake.  It looks quite different
in elisp (at least syntactically). . I'm not sure I ever would have
recognized it ... had I found examples.

What I saw was mostly about emacs commands.  Something I actually know
a fair bit about after over a decade using emacs..  Maybe not by
standards of this list, but by a wider standard I do.

Thanks for your input. Pascal, I seem to have reached beyond your
patience level.. this time.  But you have provided many helpful posts
to me direct and indirect over the yrs and I thank you for that.

And to the other posters here... also thanks for your patience and
help. Xah Lee's stuff is helpful
Thanks to Xah too.

Richard R seems to be one person who saw what I tried to phrase in the
OP.  That is, examples... not getting someone to write the thing for
me. Thanks Richard

Re: conditionals in elisp

[Pascal J. Bourguignon]

Harry Putnam <reader@newsguy.com> writes:

> pjb@informatimago.com (Pascal J. Bourguignon) writes:
>
> [...]
>
>> Whatever.  Results 1 - 50 of about 151,000 for emacs lisp
>> cheatsheet. (0.58 seconds) ^^^^^^^^^^^^
>
> Aside from being horribly lazy, not to mention stupid... I'm also
> apparently blind.... I asked about `if else conditionals'... and using
> a string I would never have thought of to search for that topic I
> repeated your search..finding in a blazing .58 second... exactly 0
> references to that topic (at least in the first two pages).

Why can't you see these links on the first page returned by Google?

http://steve-yegge.blogspot.com/2008/01/emergency-elisp.html

There's even the "Emacs Lisp for Perl Programmers"
http://obsidianrook.com/devnotes/elisp-for-perl-programmers.html on
it.


Granted, contrarily to what I expected, there's no cheat sheet for
emacs lisp, just for emacs.  This is not bad, since the later would
help you know how to get help about the if operator, (typing C-h f if
RET).

In anycase, you should have been able to find at least the two links
above that are accessible from the first page of results given by
google.


> I'll admit I gave up after the second page... Oh, wait I take it
> back, there is mention of your posts on this thread.  But then, those
> don't mention anything about the topic either.

Yes, that's a funny side effect.   That's why google search should be
done first! ;-)



> I wasn't thinking, tutorial either, since, again I've tortured myself
> with a few in the past. And a tutorial by its nature will take in a
> lot more than what I was after.  I wanted examples... and that is what I
> posted about.

The problem is that you shouldn't have to ask what syntax is if in
lisp, if you knew the first thing about lisp.  You can realy learn all
there is to know about lisp in five minutes. (Of course, then you need
a lifetime to ponder the consequences, but nonetheless, five minutes
is all you need to know it all).


> In fact I see now that looking for something similar to `if else' in
> perl or shell scripting is really a mistake.  It looks quite different
> in elisp (at least syntactically). . I'm not sure I ever would have
> recognized it ... had I found examples.
>
> What I saw was mostly about emacs commands.  Something I actually know
> a fair bit about after over a decade using emacs..  Maybe not by
> standards of this list, but by a wider standard I do.
>
> Thanks for your input. Pascal, I seem to have reached beyond your
> patience level.. this time.  But you have provided many helpful posts
> to me direct and indirect over the yrs and I thank you for that.

Just tell us when you have five minutes to learn all there is to know
about lisp ;-)


-- 
__Pascal Bourguignon__

Re: conditionals in elisp

[Harry Putnam]

pjb@informatimago.com (Pascal J. Bourguignon) writes:

[...]

> Why can't you see these links on the first page returned by Google?

Be damned if I know..  Maybe I do need new glasses...

> http://steve-yegge.blogspot.com/2008/01/emergency-elisp.html

There they are, if/else examples... NICE!

[...]

> Just tell us when you have five minutes to learn all there is to know
> about lisp ;-)

OK, I'll bite, the only risk is looking a fool, and I'm so far into that
at this point, it can't matter.

Re: conditionals in elisp

[Pascal J. Bourguignon]

Harry Putnam <reader@newsguy.com> writes:

> pjb@informatimago.com (Pascal J. Bourguignon) writes:
>
> [...]
>
>> Why can't you see these links on the first page returned by Google?
>
> Be damned if I know..  Maybe I do need new glasses...
>
>> http://steve-yegge.blogspot.com/2008/01/emergency-elisp.html
>
> There they are, if/else examples... NICE!
>
> [...]
>
>> Just tell us when you have five minutes to learn all there is to know
>> about lisp ;-)
>
> OK, I'll bite, the only risk is looking a fool, and I'm so far into that
> at this point, it can't matter.

Ok. It's quite simple really.  
Here the 5-minute all you need to know about lisp:


There are two kinds of data:

- atoms, and
- lists.

Atoms are numbers of various sort such as: 123 1.23 1.2e.3,  vectors
such as [1 2 3], strings such as "abc", and other kind of objects such
as functions, predefined data structures (eg. hash-tables), or user
defined structures or objects, and  symbols such as: foo print if
what-a-nice-day, +, -, etc, that are used to name the various things
such as variables or functions.  (Symbol can contain mostly any
character that wouldn't be interpreted as another kind of atom or
list, including spaces (just escape them with \)).


Lists are sequences of data enclosed in parentheses:

(a list containing only symbols)
(a list containing (a sub list))
(1 list containing 2 numbers and a "string")


Programs are data of a certain form that is evaluated.  
The evaluation rules are:

- symbols alone are considered to be variable references, so the value
  bound to the variable named by the symbol is returned.

- the other atoms are self evaluating, that is, their value is themselves.

- lists are considered to be operator applications and have always the form:

      (operator  arguments...)

   There are three kinds of operators:

      - functions,
      - macro,
      - special operators.

   When the operator is a function, all the arguments are evaluated in
   turn (from left to right), then the function is called with the
   values of the arguments passed as parameters.
   
       (sin (/ pi 2))

       sin is a function, so we evaluate the argument:
            (/ pi 2)
            
             / is a function so we evaluate the arguments:

               pi is a symbol, so we get the value bound to the variable named pi.
               It's 3.141592

                  2 is a atom that is not a symbol, so its value is itself.
                  2

             We call the function / with the argument 3.141592 and 2
             We get the result: 1.570796

       We call the function sin with the argument 1.570796  
       We get the result: 1.


   When the operator is a macro, then the arguments ARE NOT evaluated,
   but are passed directly to the macro function.  The macro function
   must return a new expression that will be evaluated instead of the
   macro call.  By consequence, the meaning and possible order of
   evaluation of the arguments depend on the macro function itself:
   you have to lookup the documentation or source of the macro to know
   what the argument should be, and whether and when they are
   evaluated.

       For example, in: (dotimes (i 3) (insert "hi "))
       dotimes is a macro, therefore the two arguments, the lists (i 3) and
       (insert "hi ") are passed as-is to the macro function dotimes.
       What this macro function will do, is to generate an expression that:

       - will evaluate the second element of the first argument (eg. 3,
         returning 3),

       - will create a variable named i (the first element of the first
         argument, 

       - and that will evaluate the remaining arguments (the form (insert
         "hi "), and others if there were) the number of times indicated
         by that value, by binding a counter from 0 to the variable named
         i, for use by the body.

       You can see that by using the macroexpand function:
           (macroexpand '(dotimes (i 3) (insert "hi ")))
           --> (let ((--dotimes-limit-- 3) 
                     (i 0))
                   (while (< i --dotimes-limit--)
                      (insert "hi ")
                      (setq i (1+ i))))


   A special operator is like a primitive macro: the evaluation of the
   arguments depends on a rule specific to each special operator.  


There is a small number of special operators (about 20 to 30), and
while macros are used to extend the language beyond this small number
of special operators, they represent only a small percentage of the
operators available in a typical lisp system.


That's it, that's all there is to know about lisp. (It could be
expressed more shortly, in two pages of lisp code for the eval
function too ;-)).



All the rest is rather accidental, it could be different, and it would
still be lisp.  It may change from one kind of lisp to another too
(emacs lisp, Common Lisp, ISO-Lisp, Scheme, and older variants).
There's some operators that are common to most lisps, such as if, let
and lambda, and of course there's a whole culture,  quite endearing
and interesting, that may take however some time to learn and integrate.



To know what an operator is (function, macro or special operator), and
how to use it in emacs lisp, use the C-h f command.

For if:  C-h f if RET 

    if is a special form in `C source code'.
    (if cond then else...)

    If cond yields non-nil, do then, else do else...
    Returns the value of then or the value of the last of the else's.
    then must be one expression, but else... can be zero or more expressions.
    If cond yields nil, and there are no else's, the value is nil.


Try the same on dotimes and on insert.


-- 
__Pascal Bourguignon__

Re: conditionals in elisp

[Thien-Thi Nguyen]

() "Drew Adams" <drew.adams@oracle.com>
() Tue, 27 Oct 2009 00:37:38 -0700

   Learning from examples is fine - very good, in fact. Others have already
   provided you examples, so I hope that helped. The quick and easy answer
   would have been to just give you a couple examples to learn from. You can
   evaluate each expression by typing it after `M-:' and hitting Enter.

   (if) raises an error: wrong number of arguments - 0 
   (if nil) raises an error: wrong number of args - 1
   (if nil 3)                -> nil
   (if t   3)                -> 3
   (if nil 3 4)              -> 4
   (if t   3 4)              -> 3
   (if nil 3 4 5)            -> 5
   (if t   3 4 5)            -> 3
   (if nil 3 4 5 6)          -> 6
   (if "anything but nil" 3) -> 3
   (if "nil" 3)              -> 3
   (if 99 3 "anything")      -> 3
   (if nil 3 (setq a 5) a)   -> 5

If these (nicely formatted) examples are useful, they could be added to
the documentation.

Also (to Harry Putnam): You can help avoid misunderstanding from other
list members by stating explicitly "i read the Emacs Lisp manual node
"Conditionals" and couldn't understand it".

In any case, in addition to M-:, the *scratch* buffer is also a nice
place to interact with Emacs.  There, the values of the expressions are
inserted into the buffer and so are less fleeting than the output of
M-: in the echo area.

To play:

- C-x b *scratch* RET
- M-x lisp-interaction-mode RET
- type an expression:
    (if 99 3 "anything")
- make sure cursor is immediately after the close-paren:
    (if 99 3 "anything")-!-   ;;; -!- represents the cursor
- type C-j; emacs displays evaluates the expression and inserts it;
  you see:
    (if 99 3 "anything")
    3
    -!-

Another benefit of experimenting via the *scratch* buffer is that if
something perplexes you there, it is very easy to mail the relevant
fragment when asking for help.

Overall, being explicit when asking for help is helpful to everyone.

thi

Re: conditionals in elisp

[Richard Riley]

Sean Sieger <sean.sieger@gmail.com> writes:

>     The OP was looking for a quick lookup programmers guide to common elisp
>     constructs. The elisp manual is not really quite so convenient : good
>     though it can be.
>
>     People frequently want to modify an existing feature without learning
>     the entire emacs infrastructure.
>
>     Pointing to existing code is one such way to help. Suggesting he parse
>     it all with perl probably not quite so helpful ..
>
>     Personally whenever I revisit elisp I find Xah Lee's tutorial helpful at
>     times.
>
> Look at me!  I can challenge a knowledgeable contributor!  (One whose
> depth of knowledge is clearly illustrated in the archives.)

Hold on one second there. I was not challenging Pascal's knowledge of
Emacs or Elisp.

I was merely suggesting that telling someone to write a perl script to
parse elisp to find examples of conditionals was maybe not as helpful as
pointing out a good resource for learning other than the elisp manual.

>
> One day you'll get off the fence and know your limitations as a
> contributor or as a troll and become decidedly one or the other.  My
> guess is that you need a role model that is a better fit than Xah.

I have no idea what you're talking about. While I realise Xah rattles
some people his elisp "get going" tutorial is very good IMHO.

Still, horse for courses,

regard,

r.

RE: conditionals in elisp

[Drew Adams]

> If these (nicely formatted) examples are useful, they could 
> be added to the documentation.

Perhaps. My main suggestion in this regard was that one can explore - try things
interactively, to see what happens.

> In any case, in addition to M-:, the *scratch* buffer is also a nice
> place to interact with Emacs.  There, the values of the 
> expressions are
> inserted into the buffer and so are less fleeting than the output of
> M-: in the echo area....
> 
> Another benefit of experimenting via the *scratch* buffer is that if
> something perplexes you there, it is very easy to mail the relevant
> fragment when asking for help.

I second what Thi says here. I'd also suggest an alternative to using *scratch*
- visit a new Emacs-Lisp file and use that buffer, which will be in Emacs-Lisp
mode: `C-x C-f whatever.el'.

I think Emacs-Lisp mode is generally easier to experiment in than is
Lisp-Interaction mode (the mode of buffer *scratch*). In particular, in
*scratch*, I too often get caught by the gotcha that `C-j' evaluates, instead of
just indenting. But that's probably a problem of habit.

In any case, either *scratch* or an Emacs-Lisp buffer is generally better than
`M-:' for extended experimenting, because, as Thi said, you can see the input
and output, compare results from one evaluation to the next, and easily
copy+paste to repeat things or report them.

The general point is that Lisp helps you learn Lisp, by being *very*
interactive. And one mustn't be afraid to break things or get lost. Just
remember that `C-g' cancels what's in progress, and if you fall into the white
hole of the debugger, `q' will yank you back out like a bungee cord.

Re: conditionals in elisp

[David Kastrup]

pjb@informatimago.com (Pascal J. Bourguignon) writes:

> Ok. It's quite simple really.  
> Here the 5-minute all you need to know about lisp:
>
>
> There are two kinds of data:
>
> - atoms, and
> - lists.

Actually, conses.

> Atoms are numbers of various sort such as: 123 1.23 1.2e.3,  vectors
> such as [1 2 3], strings such as "abc", and other kind of objects such
> as functions, predefined data structures (eg. hash-tables), or user
> defined structures or objects, and  symbols such as: foo print if
> what-a-nice-day, +, -, etc, that are used to name the various things
> such as variables or functions.  (Symbol can contain mostly any
> character that wouldn't be interpreted as another kind of atom or
> list, including spaces (just escape them with \)).

You forgot the atom nil which is also a list, though not a cons.

> Lists are sequences of data enclosed in parentheses:
>
> (a list containing only symbols)
> (a list containing (a sub list))
> (1 list containing 2 numbers and a "string")

Lists are nil or a cons...  Data enclosed in parentheses is a shortcut
for a certain kind of conses.

(cons 1 (cons 2 (cons 3 nil)))

is short for (list 1 2 3).

> All the rest is rather accidental, it could be different, and it would
> still be lisp.  It may change from one kind of lisp to another too
> (emacs lisp, Common Lisp, ISO-Lisp, Scheme, and older variants).

Scheme is quite different: in Lisp, a symbol has a name, a property
list, a value cell, a function cell.  In Scheme, there are just name and
value cell, and I am not sure that the name leads as much a life of its
own as in Lisp.

-- 
David Kastrup

Re: conditionals in elisp

[LanX]

> In any case, either *scratch* or an Emacs-Lisp buffer is generally better than
> `M-:' for extended experimenting, because, as Thi said, you can see the input

I'm wondering why nobody mentions M-x ielm for experimenting?

It just needs a setting the arrow movements to history-navigation
(i.e. swapping <C-up> and <up>) and it gets look and feel of  a
"normal" REPL-shell.

Very beginner friendly!

Cheers
  Rolf

Re: conditionals in elisp

[Harry Putnam]

David Kastrup <dak@gnu.org> writes:
pjb@informatimago.com (Pascal J. Bourguignon)

Thanks to both for a concise, and helpful, though not totally
understood, look into what experts consider the guts of elisp.

I suspect it will become even more helpful as some small knowledge of
elisp finally accrues in my head.

Oh yeah, and Pascal you outdid yourself I think... the reading time is
well under 5 minutes.... hehe.

Re: conditionals in elisp

[Harry Putnam]

Thien-Thi Nguyen <ttn@gnuvola.org> writes:

>
> If these (nicely formatted) examples are useful, they could be added to
> the documentation.

Yes nice examples all, and helpful.  I guess I came at this more in
line with what is posted at one of the hits Pascal pointed to:

  http://steve-yegge.blogspot.com/2008/01/emergency-elisp.html

This fellow says he was looking to demonstrate examples comparable to
other languages.

His examples of if/else seem to ring a bell for me. 

> Also (to Harry Putnam): You can help avoid misunderstanding from other
> list members by stating explicitly "i read the Emacs Lisp manual node
> "Conditionals" and couldn't understand it".

Throughout this thread I've been a little amazed at how my OP comments
seem to have been taken.

I thought I said with some clarity that I didn't understand reading
the elisp manual.  And laid out further what I was after... simplified
examples of if/else in elisp.

Is the following paragraph really so devoid of intent?

> This may be a chintzy way to do it but I really do not want to pound
> away at elisp intro and the elisp manual for hours.  I usually
> start seeing red at the 4-5 paragraph and usually have been able to
> learn what I needed to know in things like perl and shell scripting
> from  just a few real live examples that do something at least close
> to what I am trying then I can edit and tinker until I start to sort
> of `get it'.
> 

What followed that was a fairly detailed account of what I was trying
to do then asked for simplified examples that did something at least
similar.

But, it certainly did not come across as intended.

Thanks for the examples and tips about testing tinkering etc.

Oh, and do experts here think that page cited above... in particular
the if/else examples, are good?   not so good..?

Reprint of a couple here but there were several more (about 1/3 of the
way down the page cited above and below, if anyone has a mind to look):

  http://steve-yegge.blogspot.com/2008/01/emergency-elisp.html

From Steve Yegge's pages:
,----
|     if/else
| 
| Case 1: no else clause: (if test-expr expr)
| 
| Example:
| 
| (if (>= 3 2)
|   (message "hello there"))
| 
| 
| Case 2: else clause: (if test-expr then-expr else-expr)
| 
| (if (today-is-friday)         ; test-expr
|     (message "yay, friday")   ; then-expr
|   (message "boo, other day")) ; else-expr
| 
| 
| If you need multiple expressions (statements) in the then-expr, you
| wrap them with a call to progn, which is like curly-braces in C or
| Java:
| 
| (if (zerop 0)
|     (progn
|       (do-something)
|       (do-something-else)
|       (etc-etc-etc)))
`----
 [...]

Re: conditionals in elisp

[Pascal J. Bourguignon]

David Kastrup <dak@gnu.org> writes:

> pjb@informatimago.com (Pascal J. Bourguignon) writes:
>
>> Ok. It's quite simple really.  
>> Here the 5-minute all you need to know about lisp:
>>
>>
>> There are two kinds of data:
>>
>> - atoms, and
>> - lists.
>
> Actually, conses.

Right.  Oops!  More than five minutes!


>> Atoms are numbers of various sort such as: 123 1.23 1.2e.3,  vectors
>> such as [1 2 3], strings such as "abc", and other kind of objects such
>> as functions, predefined data structures (eg. hash-tables), or user
>> defined structures or objects, and  symbols such as: foo print if
>> what-a-nice-day, +, -, etc, that are used to name the various things
>> such as variables or functions.  (Symbol can contain mostly any
>> character that wouldn't be interpreted as another kind of atom or
>> list, including spaces (just escape them with \)).
>
> You forgot the atom nil which is also a list, though not a cons.
>
>> Lists are sequences of data enclosed in parentheses:
>>
>> (a list containing only symbols)
>> (a list containing (a sub list))
>> (1 list containing 2 numbers and a "string")
>
> Lists are nil or a cons...  Data enclosed in parentheses is a shortcut
> for a certain kind of conses.

Way more than five minutes!


> (cons 1 (cons 2 (cons 3 nil)))
>
> is short for (list 1 2 3).
>
>> All the rest is rather accidental, it could be different, and it would
>> still be lisp.  It may change from one kind of lisp to another too
>> (emacs lisp, Common Lisp, ISO-Lisp, Scheme, and older variants).
>
> Scheme is quite different: in Lisp, a symbol has a name, a property
> list, a value cell, a function cell.  In Scheme, there are just name and
> value cell,  and I am not sure that the name leads as much a life of its
> own as in Lisp.

No, in scheme (r5rs), symbols don't even have a value (this would be
useless, since there is only lexical bindings in scheme).  But now we
need one hour to explain...



-- 
__Pascal Bourguignon__

Re: conditionals in elisp

[Harry Putnam]

LanX <lanx.perl@googlemail.com> writes:

>> In any case, either *scratch* or an Emacs-Lisp buffer is generally better than
>> `M-:' for extended experimenting, because, as Thi said, you can see the input
>
> I'm wondering why nobody mentions M-x ielm for experimenting?
>
> It just needs a setting the arrow movements to history-navigation
> (i.e. swapping <C-up> and <up>) and it gets look and feel of  a
> "normal" REPL-shell.
>
> Very beginner friendly!

Well, there's something I didn't even know existed... thanks.

Re: conditionals in elisp

[Joseph Brenner]

Harry Putnam <reader@newsguy.com> writes:

> Oh, and do experts here think that page cited above... in particular
> the if/else examples, are good?   not so good..?

>   http://steve-yegge.blogspot.com/2008/01/emergency-elisp.html

Yes, they're pretty good, but arguably if you're interested in just
writing some working code you should be pointed at "cond" first,
which is almost always a better choice than "if".

On the other hand, Steve Yegge does a nice job of quickly explaining
"progn", a piece of fugliness you need to know if only for the sake of
reading existing code.

Note, Yegge's article explains "cond" just after "if", in the section
titled "switch".

He also then talks about "case", bht there the examples aren't complete
without a line to load the cl.el package (something like perl's "use"):

  (require 'cl)
  (case 12
    ...
  )