predicates on lists

predicates on lists

[David Roderick]

Elisp 5.8

 -- Function: assoc-default key alist &optional test default
     This function searches ALIST for a match for KEY.  For each
     element of ALIST, it compares the element (if it is an atom) or
     the element's CAR (if it is a cons) against KEY, by calling TEST
     with two arguments: the element or its CAR, and KEY.  The
     arguments are passed in that order so that you can get useful
     results using `string-match' with an alist that contains regular
     expressions (*note Regexp Search::).  If TEST is omitted or `nil',
     `equal' is used for comparison.

I am a bit confused. I thought that an element inside of an associated
list is a dotted pair of its CAR and CDR, and the KEY is the CAR.  The
argument as key in the above function confused me.  Having solved this
problem, and realizing that this function is complicated, am I correct
in thinking that an atom is   (atom OBJECT) == (not (consp OBJECT))
This is confusing because an atom is a fundamental building block
outside of Elisp, and a cons cell is a fundamental building block by
Elisp.
It seems that anything which is not a cons cell should be a molecule.
Ok, now that I have got this silly questioning over and done with, a
further query arises in my brain.

     you can get useful
     results using `string-match' with an alist that contains regular
     expressions (*note Regexp Search::).  

Does the string-match contain a regular expression or does the alisp
contain a regular expression?

My guess is the string-match may contain a regular expression, but 
this process of deduction might be
eliminated if the explanation was revised.

-- 
from 
David Roderick

Re: predicates on lists

[Barry Margolin]

In article <u1w5xllsb.fsf@tiscali.co.uk>,
 David Roderick <angel_ov_north@tiscali.co.uk> wrote:

> Elisp 5.8
> 
>  -- Function: assoc-default key alist &optional test default
>      This function searches ALIST for a match for KEY.  For each
>      element of ALIST, it compares the element (if it is an atom) or
>      the element's CAR (if it is a cons) against KEY, by calling TEST
>      with two arguments: the element or its CAR, and KEY.  The
>      arguments are passed in that order so that you can get useful
>      results using `string-match' with an alist that contains regular
>      expressions (*note Regexp Search::).  If TEST is omitted or `nil',
>      `equal' is used for comparison.
> 
> I am a bit confused. I thought that an element inside of an associated
> list is a dotted pair of its CAR and CDR, and the KEY is the CAR.  The
> argument as key in the above function confused me.  Having solved this

The above function allows "singletons" to be elements of the alist, in 
addition to associations.  In that case, it treats the element as its 
own key.

> problem, and realizing that this function is complicated, am I correct
> in thinking that an atom is   (atom OBJECT) == (not (consp OBJECT))
> This is confusing because an atom is a fundamental building block
> outside of Elisp, and a cons cell is a fundamental building block by
> Elisp.
> It seems that anything which is not a cons cell should be a molecule.

The original meaning of "atom" is something that can't be split into 
pieces.  And in early versions of Lisp, conses were the only data types 
that had multiple components, so they used the term "atom" to refer to 
everything else.

> Ok, now that I have got this silly questioning over and done with, a
> further query arises in my brain.
> 
>      you can get useful
>      results using `string-match' with an alist that contains regular
>      expressions (*note Regexp Search::).  
> 
> Does the string-match contain a regular expression or does the alisp
> contain a regular expression?

String-match is a function.  What do you mean by "string-match contain a 
regular expression"?  I think you're asking whether KEY would contain 
the regular expression.  And if they meant that, they would have said it 
rather than "alist that contains regular expressions".

> My guess is the string-match may contain a regular expression, but 
> this process of deduction might be
> eliminated if the explanation was revised.

It's saying that the alist has regular expressions as the keys.  A 
well-known example is auto-mode-alist, which is an alist mapping regular 
expressions to major modes.  It gets used as:

(assoc-default filename auto-mode-alist 'string-match)

-- 
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE don't copy me on replies, I'll read them in the group ***

Re: predicates on lists

[David Roderick]

>  What do you mean by "string-match contain a 
> regular expression"?  
 It think that I was assuming that a regular expression may be passed as
 an argument to string-match.

Thanks for help.  I may understand this fully in time.
-- 
from 
David Roderick