To `boundp' or not to `boundp'?

To `boundp' or not to `boundp'?

[Alexander Shukaev]

Hello,

I often see code like this

(when (and (boundp 'xxx-mode) xxx-mode)
  ...)

I personally prefer to do it shorter

(when (ignore-errors xxx-mode)
  ...)

Are those equivalent?  Are there any pitfalls associated with my approach?

Regards,
Alexander

Re: To `boundp' or not to `boundp'?

[Dmitry Gutov]

On 09/01/2015 06:50 PM, Alexander Shukaev wrote:

> I often see code like this
>
> (when (and (boundp 'xxx-mode) xxx-mode)
>    ...)

The "proper" way to do that is to use bound-and-true-p.

Re: To `boundp' or not to `boundp'?

[Alexander Shukaev]

>> I often see code like this
>>
>> (when (and (boundp 'xxx-mode) xxx-mode)
>>    ...)
>
>
> The "proper" way to do that is to use bound-and-true-p.

Interesting, thanks, Dmitry.

RE: To `boundp' or not to `boundp'?

[Drew Adams]

> > I often see code like this
> > (when (and (boundp 'xxx-mode) xxx-mode) ...)
> 
> The "proper" way to do that is to use bound-and-true-p.

That certainly is *not* proper for the more general case
(and (boundp 'xxx)  xxx), where the value of `xxx' is
not necessarily Boolean or is not used only as a Boolean.

Well, it works the same, but the _name misleads_ terribly
in this case, even if the doc does let you know that the
variable value (not t or nil) is returned, when bound.

`bound-and-true-p' is defined as the exact _same thing_:

(defmacro bound-and-true-p (var)
  "Return the value of symbol VAR if it is bound, else nil."
  `(and (boundp (quote ,var)) ,var))

So it cannot be more "proper".

And in fact its definition (expansion) is much, much
clearer in the case where the var value is not Boolean.
Unlike (bound-and-true-p VAR), (and (boundp 'VAR) VAR)
is always clear and never misleads.  It makes clear
that you are testing the symbol for variableness and
returning the variable value if bound.

In sum, your "proper" is my "improper, misleading, and
useless."  Why Emacs bothered to introduce this silly
macro, I cannot imagine.  Perhaps it was to save some 
characters when the variable name is long.  Bof.

If they really wanted a macro for this, it should have
been called something that reflects what it does, e.g.,
`var-value-or-nil' or `if-bound-then-value-else-nil'.

> > I personally prefer to do it shorter
> > (when (ignore-errors xxx-mode) ...)
> > Are those equivalent?

Yes, pretty much.

> Are there any pitfalls associated with my approach?

Not really.  But it is not as readable, IMHO.  `boundp'
shouts to a reader that this is test for a variable.

Re: To `boundp' or not to `boundp'?

[Michael Heerdegen]

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

> If they really wanted a macro for this, it should have been called
> something that reflects what it does, e.g., `var-value-or-nil' or
> `if-bound-then-value-else-nil'.

One needs this quite often, so it's good to factor it out.

I've no strong opinion about the name, but I guess the macro was indeed
intended for cases where the return value is used as a boolean.  There
are other use cases where the name then is confusing.  Maybe
`symbol-value-safe' in analogy to `car-safe' would be better?  Then it
would have to be a function, though.


Regards,

Michael.

RE: To `boundp' or not to `boundp'?

[Drew Adams]

> > If they really wanted a macro for this, it should have been called
> > something that reflects what it does, e.g., `var-value-or-nil' or
> > `if-bound-then-value-else-nil'.
> 
> One needs this quite often, so it's good to factor it out.

And so it was.  I'm not convinced it helps.  But if it helps you, great.
(and (boundp 'VAR) VAR) works for me.

> I've no strong opinion about the name, but I guess the macro was indeed
> intended for cases where the return value is used as a boolean.  There
> are other use cases where the name then is confusing.  Maybe
> `symbol-value-safe' in analogy to `car-safe' would be better?  Then it
> would have to be a function, though.

I don't see why it would have to be a function, just due to a name
change.  But the name is what it is, and likely won't be changed.

(And whatever the name, I will likely use (and (boundp 'VAR) VAR).)

Re: To `boundp' or not to `boundp'?

[Barry Margolin]

In article <mailman.331.1441125765.19560.help-gnu-emacs@gnu.org>,
 Drew Adams <drew.adams@oracle.com> wrote:

> > > I often see code like this
> > > (when (and (boundp 'xxx-mode) xxx-mode) ...)
> > 
> > The "proper" way to do that is to use bound-and-true-p.
> 
> That certainly is *not* proper for the more general case
> (and (boundp 'xxx)  xxx), where the value of `xxx' is
> not necessarily Boolean or is not used only as a Boolean.
> 
> Well, it works the same, but the _name misleads_ terribly
> in this case, even if the doc does let you know that the
> variable value (not t or nil) is returned, when bound.

The name isn't misleading if you use it in a boolean context, like the 
WHEN call in the OP.

It's no more misleading than MEMBER, which intuitively seems like it 
would just return a boolean, but actually returns the tail of the list 
where the element was found.

-- 
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

member returns list (was: Re: To `boundp' or not to `boundp'?)

[Emanuel Berg]

Barry Margolin <barmar@alum.mit.edu> writes:

> ... MEMBER, which intuitively seems like it would
> just return a boolean, but actually returns the tail
> of the list where the element was found.

Yes, and I have wondered about that. Is it useful,
perhaps with the use of `car' (?) as in:

    (car (member 2 '(1 2 3))) ; 2
    (car (member 0 '(1 2 3))) ; nil

Or is it some "leftover optimization" thing where
`cdr' is faster than returning `t', and can be used
the same way?

Or is it something else?

-- 
underground experts united
http://user.it.uu.se/~embe8573

RE: member returns list (was: Re: To `boundp' or not to `boundp'?)

[Drew Adams]

> Yes, and I have wondered about that. Is it useful,
> perhaps with the use of `car' (?) as in:
>     (car (member 2 '(1 2 3))) ; 2
>     (car (member 0 '(1 2 3))) ; nil

Yes, extremely useful.

> Or is it some "leftover optimization" thing where
> `cdr' is faster than returning `t', and can be used
> the same way?  Or is it something else?

No and no.

It's an access function, like `assoc' or `elt'.
If no such member can be found then it returns nil,
which means that it can also function as a simple
membership test.

Re: member returns list (was: Re: To `boundp' or not to `boundp'?)

[Emanuel Berg]

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

> If no such member can be found then it returns nil,
> which means that it can also function as a simple
> membership test.

OK then, what does it do when it doesn't function
like that?

-- 
underground experts united
http://user.it.uu.se/~embe8573

RE: member returns list (was: Re: To `boundp' or not to `boundp'?)

[Drew Adams]

> > If no such member can be found then it returns nil,
> > which means that it can also function as a simple
> > membership test.
> 
> OK then, what does it do when it doesn't function
> like that?

I don't understand the question.  It always functions
the same way.  Whether code uses it only to test membership
or to access the first tail that corresponds is up to that
code.  But `member' behaves ("functions") the same.

Re: member returns list (was: Re: To `boundp' or not to `boundp'?)

[Emanuel Berg]

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

> I don't understand the question. It always functions
> the same way. Whether code uses it only to test
> membership or to access the first tail that
> corresponds is up to that code. But `member' behaves
> ("functions") the same.

It looks like this:

    (member ELT LIST)

When is it beneficial to, instead of just getting
a `t' on a hit, to get a list that consists of ELT and
everything eastward of ELT, in LIST?

The `car' example I provided may look cool (?) but it
isn't anything that cannot be done with "memberp",
because obviously the car is known, otherwise one
wouldn't be able to search for it.

-- 
underground experts united
http://user.it.uu.se/~embe8573

RE: member returns list (was: Re: To `boundp' or not to `boundp'?)

[Drew Adams]

> It looks like this: (member ELT LIST)
> 
> When is it beneficial to, instead of just getting
> a `t' on a hit, to get a list that consists of ELT and
> everything eastward of ELT, in LIST?

When that is what you want/need. ;-)

> The `car' example I provided may look cool (?) but it
> isn't anything that cannot be done with "memberp",
> because obviously the car is known, otherwise one
> wouldn't be able to search for it.

Sure, if you just want the element you're testing for, then
(car (member 'foo xs)) is no better than
(and (memberp 'foo xs)  'foo)

(In the second example, if the element needs to be
computed, let-bind it to avoid computing it twice.)

But maybe you want the next element after `foo':
(cadr (member 'foo xs))

Or the element after `foo' or the first element if `foo' is
not in the list:
(or (cadr (member 'foo xs))  (car xs))

Or maybe you want to change `foo' to `bar' in the list:
(setcar (member 'foo xs) 'bar)

Or maybe you want to truncate the list after `foo':
(setcdr (member 'foo xs) ())

Or maybe you want to ensure that 'foo is at the head of
the list, adding it there if not already in the list:
(if (null xs)
    (setq xs  (list 'foo))
  (let ((tl  (member 'foo xs)))
    (unless (eq tl xs)
      (when tl (setcdr (nthcdr (1- (- (length xs) (length tl))) 
                               xs)
                       (cdr tl)))
      (setq xs  (cons 'foo xs))))
  xs)

Or the same thing for any list variable and element:
(defun put-at-head (list-var element)
  (let* ((lis  (symbol-value list-var))
         (tl   (member element lis)))
    (cond ((null lis) (set list-var (list element)))
          ((not (eq tl lis))
           (when tl (setcdr (nthcdr (1- (- (length lis) (length tl)))
                                    lis) 
                            (cdr tl)))
           (set list-var (cons element lis)))))
  (symbol-value list-var))

You get the idea.  Often, if you care about the list structure
it is because you are modifying it (destructive operations).
(Not always - e.g., (cadr (member 'foo xs)).)
 
And yes, most other uses of `member' (and `memq') are just tests
for membership.  You can see this by grepping the Emacs Lisp sources.

Re: member returns list (was: Re: To `boundp' or not to `boundp'?)

[Emanuel Berg]

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

>> The `car' example I provided may look cool (?) but
>> it isn't anything that cannot be done with
>> "memberp", because obviously the car is known,
>> otherwise one wouldn't be able to search for it.
>
> Sure, if you just want the element you're testing
> for, then (car (member 'foo xs)) is no better than
> (and (memberp 'foo xs) 'foo)
>
> (In the second example, if the element needs to be
> computed, let-bind it to avoid computing it twice.)

Agreed: the first example is better unless you do
that. Better style, and sometimes even better
performance tho in most cases equal or a negligeable
difference. However, as the trained eye does, it
automagically associates beauty with speed and power :)

> But maybe you want the next element after `foo':
> (cadr (member 'foo xs))

I tried to visualize such use but as for me I am still
unable, probably because I would instead do something
else that is practically equivalent in that situation.

> You get the idea. Often, if you care about the list
> structure it is because you are modifying it
> (destructive operations). (Not always - e.g., (cadr
> (member 'foo xs)).)
>
> And yes, most other uses of `member' (and `memq')
> are just tests for membership. You can see this by
> grepping the Emacs Lisp sources.

Most definitely a good method in cases such as this
and many others. If I find any Elisp-kung-fu-ish use
of `member', I'll post it here faster than a Bruce Lee
finger jab.

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: member returns list

[Pascal J. Bourguignon]

Emanuel Berg <embe8573@student.uu.se> writes:

> Drew Adams <drew.adams@oracle.com> writes:
>
>> I don't understand the question. It always functions
>> the same way. Whether code uses it only to test
>> membership or to access the first tail that
>> corresponds is up to that code. But `member' behaves
>> ("functions") the same.
>
> It looks like this:
>
>     (member ELT LIST)
>
> When is it beneficial to, instead of just getting
> a `t' on a hit, to get a list that consists of ELT and
> everything eastward of ELT, in LIST?
>
> The `car' example I provided may look cool (?) but it
> isn't anything that cannot be done with "memberp",
> because obviously the car is known, otherwise one
> wouldn't be able to search for it.

But member* is like CL:MEMBER, and take :KEY and :TEST arguments that
could make the matched element quite different from the target.

    (member* 1 '(2 4 6 5 7 9) :test (lambda (a b) (evenp (- a b))))
    --> (5 7 9)

    (member* 3 '(1 4 9 16 25) :key (function sqrt) :test (function =))
    --> (9 16 25)


An other example:

    ;; define an order on colors:
    (defvar *order* '(red orange yellow green blue indigo violet))
    (defun le (a b) (member b (member a *order*)))
    (le 'orange 'blue)   --> (blue indigo violet)
    (le 'orange 'orange) --> (orange yellow green blue indigo violet)
    (le 'blue   'orange) --> nil


Yet another example, not using car, but second:

    (defun rps-wins-over (a b)
       (eql b (second (member a '(paper rock scissors paper)))))

    (rps-wins-over 'scissors 'paper) --> t
    (rps-wins-over 'paper 'scissors) --> nil


Another example:

    (let ((list '(1 2 3 4 5 6))
          (terminator 4))
       (ldiff list (member terminator list)))
    --> (1 2 3)


Another example: in the algorith to process include CPP directories, I
have a use of member value such as:

    (let ((include-directories (include-directories kind)))
      (when (eq directive :include-next)
        (setf include-directories (cdr (member (context-directory context)
                                               include-directories
                                               :test (function equal)))))
      (multiple-value-bind (path directory)
          (search-file-in-directories include-file include-directories kind directive)
        (cond ((eq t path) #|done|#)
              (path        (include path directory))
              (t           (cpp-error …)))))

Another example: since member returns the cons cell where the target
object is stored, we can update it.  For example, when implementing a
cache, I used something like:

    (defun update-cache (name)
      (let ((sl (member* name *cache* :key 'object-name  
                                     :test 'string-equal)))
        (if sl
           (setf (car sl) new-data)
           (push new-data *cache*))))




In CL, there's another predicate that returns a very useful value:
digit-char-p is specified to return the integer value of the digit
character:

   (digit-char-p #\4) --> 4
   (digit-char-p #\!) --> nil

In general, in CL, predicates are specified to return _generalized_
booleans, so implementation may return useful values for them too (but
it would be non-conforming to take advantage of those "useful" values).

-- 
__Pascal Bourguignon__                 http://www.informatimago.com/
“The factory of the future will have only two employees, a man and a
dog. The man will be there to feed the dog. The dog will be there to
keep the man from touching the equipment.” -- Carl Bass CEO Autodesk

Re: member returns list

[Emanuel Berg]

"Pascal J. Bourguignon" <pjb@informatimago.com>
writes:

>     (defun rps-wins-over (a b) (eql b (second (member
> a '(paper rock scissors paper)))))
>
>     (rps-wins-over 'scissors 'paper) -->
> t (rps-wins-over 'paper 'scissors) --> nil

Good example!

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: member returns list

[Michael Heerdegen]

Emanuel Berg <embe8573@student.uu.se> writes:

> Or is it something else?

The `car' of the result of `member' is the actual element you were
searching.  Since `member' tests with `equal', that can be a different
object.  So it can be useful to have access to it.

But `member' returns a whole sublist.  This gives you also a simple mean
to modify a list, like in this example:

(let ((list '(1 2 3 4 5)))
  (let ((list1 (member 3 list)))
    (when list1 (setcar list1 -3))
    list))

   ==> (1 2 -3 4 5)


Michael.

Re: member returns list

[Emanuel Berg]

Michael Heerdegen <michael_heerdegen@web.de> writes:

> The `car' of the result of `member' is the actual
> element you were searching. Since `member' tests
> with `equal', that can be a different object.

OK, so the `car' is the object, however ELT is
searched for with `equal', which compares objects'
"structure and contents". An object obviously have the
same structure and contents when compared to itself,
but nonetheless two objects can have the same
structure and contents in what case the `car' and ELT
are identical but still two objects. Ha! I'm smart...

So then, is there a "member-whatever" that doesn't use
`equal' but one of the many other functions available
to compare items? Is there a "member" to which you can
provide this function yourself?

> But `member' returns a whole sublist. This gives you
> also a simple mean to modify a list, like in this
> example:
>
> (let ((list '(1 2 3 4 5))) (let ((list1 (member 3
> list))) (when list1 (setcar list1 -3)) list))
>
>    ==> (1 2 -3 4 5)

Yes, already mentioned but true nonetheless. It would
be interesting to see what programs you guys write
because I never did stuff like that. Perhaps in HPC
with tons of data, or old-school batch "data
processing", this type of stuff is/was legio?

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: member returns list

[Michael Heerdegen]

Emanuel Berg <embe8573@student.uu.se> writes:

> So then, is there a "member-whatever" that doesn't use
> `equal' but one of the many other functions available
> to compare items? Is there a "member" to which you can
> provide this function yourself?

Yes, `cl-member' from "cl-lib" allows to provide arbitrary test
predicates via the :test key.


Regards,

Michael.

RE: member returns list

[Drew Adams]

> So then, is there a "member-whatever" that doesn't use
> `equal' but one of the many other functions available
> to compare items? Is there a "member" to which you can
> provide this function yourself?

Not sure what you are asking, but:

1. `memq' is the same as `member', but it compares using `eq'
   instead of `equal'.

2. Common Lisp `member' takes keyword :test, which lets you
   compare using any comparison predicate you like.  The default
   for :test is `eql'.  In Emacs you can get more or less the
   behavior of Common Lisp `meember' using `cl-member'.

   So (member x xs) == (cl-member x xs :test #'equal)
      (memq   x xs) == (cl-member x xs :test #'eq)

Re: member returns list

[Marcin Borkowski]

On 2015-09-02, at 23:47, Emanuel Berg <embe8573@student.uu.se> wrote:

> So then, is there a "member-whatever" that doesn't use
> `equal' but one of the many other functions available
> to compare items? Is there a "member" to which you can
> provide this function yourself?

memq
cl-member

Also related:

cl-member-if
cl-member-if-not

Best,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University

Re: member returns list

[Emanuel Berg]

Marcin Borkowski <mbork@mbork.pl> writes:

> memq

Hot!

Love Emacs and Lisp inconsistency!

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: member returns list

[Marcin Borkowski]

On 2015-09-04, at 03:03, Emanuel Berg <embe8573@student.uu.se> wrote:

> Marcin Borkowski <mbork@mbork.pl> writes:
>
>> memq
>
> Hot!
>
> Love Emacs and Lisp inconsistency!

assq
delq
memq
rassq
remq

...inconsistency?

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University

Re: member returns list

[Emanuel Berg]

Marcin Borkowski <mbork@mbork.pl> writes:

>> Hot!
>>
>> Love Emacs and Lisp inconsistency!
>
> assq delq memq rassq remq
>
> ...inconsistency?

Of course, inconsistency in one direction can be
consistent in another. Then those directions are
collectively inconsistent with each other, one could
say. "Orthogonal" perhaps, in the world
of mathematics?

If we stick to `member' (using `equal') vs. `memq'
(using `eq'), this renaming of those:

    member-equal
    member-eq

would be seen by some people as more consistent than
the actual

    member
    memq

however such inconsistency is *beneficial* because it
makes things stick out more when you read the code,
and it is also less error prone as, if you type
"member-equal" two times, and then you are to type
"member-eq", sometimes you will type "member-equal"
just by the motion of it! That would sure be
a difficult bug to spot because, again, it looks too
much like what it in this case should be, but isn't.

This is parallel to one aspect of interface
programming. For example an interface presenting
physical data. What some people would do is they would
arrange the data display logically. The direction and
strength of the wind in one corner and the temperature
in fahrenheit, celsius, and kelvin in another corner.
This is consistent, no doubt, but is it efficient?
Not necessarily! If this should be used every day, the
most important stuff should be in the middle.
We assume this is in the land of honor and heroes,
i.e., Northen Europe. Then the celsius should be put
in the middle, and the fahrenheit and kelvin can be put
wherever, right next to the wind data, for example.
But how will then people find it in this inconsistent
mess? Because as they use it every day, they will not
navigate it by thinking logically. They will quickly
learn, and thereafter know, where to look!

In a program like Emacs with I don't know how many (?)
functions, variables, etc., "learning and navigating"
is more difficult than finding data on a display.
With completion, it would have been easier for me to
find "member-eq" if `memq' was named like that.
So there are many aspects of this. As for me, I still
prefer the inconsistency for the reasons stated.
I'm not in a rush learning and navigating Emacs.
Everything, and always, in time!

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: member returns list

[Random832]

Emanuel Berg <embe8573@student.uu.se> writes:

> If we stick to `member' (using `equal') vs. `memq'
> (using `eq'), this renaming of those:
>
>     member-equal
>     member-eq
>
> would be seen by some people as more consistent than
> the actual
>
>     member
>     memq

Why not simply eliminate both and have something like
(member-test #'eq object list)

Or
(member-if (lambda (x) (eq object x)) list)?

Re: member returns list

[Emanuel Berg]

Random832 <random832@fastmail.com> writes:

> Why not simply eliminate both and have something
> like
>
>     (member-test #'eq object list)

Because that is not more simple but on the contrary
more complicated, and it would imply the same data
(#'eq) appearing repeatedly in code blocks that
qualitatively do the same thing.

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: member returns list

[Random832]

Emanuel Berg <embe8573@student.uu.se> writes:
> Because that is not more simple but on the contrary
> more complicated, and it would imply the same data
> (#'eq) appearing repeatedly in code blocks that
> qualitatively do the same thing.

How is this different from memq itself appearing repeatedly? Or the
substring -eq appearing repeatedly in your version in symbols like
member-eq and assoc-eq? (Or, for that matter, the letter "q" in the
actual ones) - common data to describe common behavior is a feature, not
a bug.

It's just like using a naming convention, only it makes it possible (and
obvious that it is possible) to substitute the comparison function with
your own function. It's simpler because instead of having two functions
to do two things with no obvious way to do the same thing with anything
else, you have one function that can easily discoverably do anything.

This would enforce being explicit about what comparison function is used
by naming the comparison function no matter what function you are using
it in, and not privilege eq and equal over other comparison
functions. We have memql but not assql; my version would let you pass
eql to anything.

CL allows a keyword-argument :test to accomplish this.

Re: member returns list

[Emanuel Berg]

Random832 <random832@fastmail.com> writes:

> How is this different from memq itself
> appearing repeatedly?

`memq' is a function. What should not be repeated is
data (in your case the a function passed as an
argument).

> Or the substring -eq appearing repeatedly in your
> version in symbols like member-eq and assoc-eq?

Those are not my versions. I made the examples to show
how it could look. It doesn't, which is good.

> It's just like using a naming convention, only it
> makes it possible (and obvious that it is possible)
> to substitute the comparison function with your own
> function. It's simpler because instead of having two
> functions to do two things with no obvious way to do
> the same thing with anything else, you have one
> function that can easily discoverably do anything.

There should be one function that can do everything
but common patterns should be factored out into
interfaces and/or optimizations.

Code shouldn't look like this:

    (do-this 1 2 3)
    (do-this 1 2 3)
    (do-this 1 2 3)

But like this:

    (defun do-the-one-two-three-thing ()
      (do-this 1 2 3) )

    (loop repeat 3 do (do-the-one-two-three-thing))

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: member returns list

[Pascal J. Bourguignon]

Random832 <random832@fastmail.com> writes:

> Emanuel Berg <embe8573@student.uu.se> writes:
>
>> If we stick to `member' (using `equal') vs. `memq'
>> (using `eq'), this renaming of those:
>>
>>     member-equal
>>     member-eq
>>
>> would be seen by some people as more consistent than
>> the actual
>>
>>     member
>>     memq
>
> Why not simply eliminate both and have something like
> (member-test #'eq object list)
>
> Or
> (member-if (lambda (x) (eq object x)) list)?

There were a lot of variants and propositions, amongst all the lisp
dialects.  Then starting from 1984, some interested corporations and
institutes invested a lot of money (in form of salaries to detached
employees), to form a standardization commitee and decide on this all
all similar kinds of discrepancies that made porting lisp programs from
one lisp to the other a PITA. They worked hard, for ten years.  Then
money was exhausted, so they finalized an ANSI Common Lisp standard in
1994.

Therefore nowadays, you write:

  (member element list :test (function eql))
  (member element list :test (function equal))
  (member element list :test (function equalp))
  (member element list :test (function your-own-equivalence-relationship))

or member* in emacs lisp since RMS doesn't want to rejoin the common
community of lispers…

-- 
__Pascal Bourguignon__                 http://www.informatimago.com/
“The factory of the future will have only two employees, a man and a
dog. The man will be there to feed the dog. The dog will be there to
keep the man from touching the equipment.” -- Carl Bass CEO Autodesk

Re: member returns list

[Emanuel Berg]

"Pascal J. Bourguignon" <pjb@informatimago.com>
writes:

> There were a lot of variants and propositions,
> amongst all the lisp dialects.

What was the reason (were the reasons) for this
proliferation of different Lisps, the "Lisp wars"?

> Then starting from 1984, some interested
> corporations and institutes invested a lot of money
> (in form of salaries to detached employees), to form
> a standardization commitee and decide on this all
> all similar kinds of discrepancies that made porting
> lisp programs from one lisp to the other a PITA.
> They worked hard, for ten years. Then money was
> exhausted, so they finalized an ANSI Common Lisp
> standard in 1994.

And somewhere around then, the by far best language in
the world started to be completely marginalized so
that now, when I say it is the language I like the
most without competition, either people (now I talk
computer people) don't know it or are eyes wide
mouth open.

> or member* in emacs lisp since RMS doesn't want to
> rejoin the common community of lispers

What is the story about that?

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: member returns list

[Robert Thorpe]

Emanuel Berg <embe8573@student.uu.se> writes:
>> or member* in emacs lisp since RMS doesn't want to
>> rejoin the common community of lispers
>
> What is the story about that?

I think the Common Lisp vs Emacs Lisp debate is fighting the last war.

In the past Common Lisp was the only major lisp.  Lispers had to use
that and learn it.  Using Emacs was natural and if a Lisper did then
that meant learning Emacs Lisp too.  An obvious solution to this was to
standardize on Common Lisp for Emacs too.

Now though there's Clojure.  By the looks of things most new Lisp
development is going to be done with Clojure not Common Lisp.  There's
also Racket, and I expect quite a bit will be done with that.  So,
switching Emacs to Common Lisp won't help much.

BR,
Robert Thorpe

Re: member returns list

[Pascal J. Bourguignon]

Robert Thorpe <rt@robertthorpeconsulting.com> writes:

> Emanuel Berg <embe8573@student.uu.se> writes:
>>> or member* in emacs lisp since RMS doesn't want to
>>> rejoin the common community of lispers
>>
>> What is the story about that?
>
> I think the Common Lisp vs Emacs Lisp debate is fighting the last war.
>
> In the past Common Lisp was the only major lisp.  Lispers had to use
> that and learn it.  Using Emacs was natural and if a Lisper did then
> that meant learning Emacs Lisp too.  An obvious solution to this was to
> standardize on Common Lisp for Emacs too.
>
> Now though there's Clojure.  By the looks of things most new Lisp
> development is going to be done with Clojure not Common Lisp.  There's
> also Racket, and I expect quite a bit will be done with that.  So,
> switching Emacs to Common Lisp won't help much.

I wouldn't bet on it.  

Clojure is not standardized, it is a proprietary programming language.

It would be foolish and irresponsible for a corporation to use it,
instead of Common Lisp.

-- 
__Pascal Bourguignon__                 http://www.informatimago.com/
“The factory of the future will have only two employees, a man and a
dog. The man will be there to feed the dog. The dog will be there to
keep the man from touching the equipment.” -- Carl Bass CEO Autodesk

Re: member returns list

[John Mastro]

> Clojure is not standardized, it is a proprietary programming language.

Clojure is not standardized, true, but
it is free software.

-- 
john

Re: member returns list

[Emanuel Berg]

Robert Thorpe <rt@robertthorpeconsulting.com> writes:

> I think the Common Lisp vs Emacs Lisp debate is
> fighting the last war.
>
> In the past Common Lisp was the only major lisp.
> Lispers had to use that and learn it. Using Emacs
> was natural and if a Lisper did then that meant
> learning Emacs Lisp too. An obvious solution to this
> was to standardize on Common Lisp for Emacs too.
>
> Now though there's Clojure. By the looks of things
> most new Lisp development is going to be done with
> Clojure not Common Lisp. There's also Racket, and
> I expect quite a bit will be done with that. So,
> switching Emacs to Common Lisp won't help much.

There is a lot of Lisps going on. Just browse
comp.lang.lisp and see.

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: member returns list

[Pascal J. Bourguignon]

Emanuel Berg <embe8573@student.uu.se> writes:

> "Pascal J. Bourguignon" <pjb@informatimago.com>
> writes:
>
>> There were a lot of variants and propositions,
>> amongst all the lisp dialects.
>
> What was the reason (were the reasons) for this
> proliferation of different Lisps, the "Lisp wars"?

Because each implementation worked on a different machine with a
different OS (if an OS was available at all).


>> Then starting from 1984, some interested
>> corporations and institutes invested a lot of money
>> (in form of salaries to detached employees), to form
>> a standardization commitee and decide on this all
>> all similar kinds of discrepancies that made porting
>> lisp programs from one lisp to the other a PITA.
>> They worked hard, for ten years. Then money was
>> exhausted, so they finalized an ANSI Common Lisp
>> standard in 1994.
>
> And somewhere around then, the by far best language in
> the world started to be completely marginalized so
> that now, when I say it is the language I like the
> most without competition, either people (now I talk
> computer people) don't know it or are eyes wide
> mouth open.
>
>> or member* in emacs lisp since RMS doesn't want to
>> rejoin the common community of lispers
>
> What is the story about that?

Ask him.

But basically, he started GNU emacs and designing emacs lisp slightly
beforem the CL standardization process started, and it was far from
obviouos that it would succeed (it took ten years!).


For example, Franz, Inc. switched over to CL only after 1985 and had CL
available only in 1986.

http://franz.com/about/company.history.lhtml
http://emacswiki.org/emacs/EmacsHistory

-- 
__Pascal Bourguignon__                 http://www.informatimago.com/
“The factory of the future will have only two employees, a man and a
dog. The man will be there to feed the dog. The dog will be there to
keep the man from touching the equipment.” -- Carl Bass CEO Autodesk

Re: member returns list

[Emanuel Berg]

"Pascal J. Bourguignon" <pjb@informatimago.com>
writes:

> Because each implementation worked on a different
> machine with a different OS (if an OS was available
> at all).

Yeah, but there were many machines at the time of the
"crazy language" C as well, still, there aren't
a plethora of C dialects. (If you don't count all the
epigone languages that borrowed heavily the syntax
of C.)

But C is famous for its portability (which also
proliferated Unix) - perhaps the exception that
confirms the rule, that Lisp is cooler than C?

> But basically, he started GNU emacs and designing
> emacs lisp slightly beforem the CL standardization
> process started, and it was far from obviouos that
> it would succeed (it took ten years!).

OK, but when it did "succeed", why not then?

And, cannot CL be used from Elisp, with explicit
notation (actually naming), but nonetheless?

I can't say I have a problem with this. As for me,
I wouldn't mind one big Lisp which included everything
from all sound Lisp dialects. In time, people would
still use virtually the same stuff. It would be a
de facto standardization. And whenever it wouldn't
happen, oh my, people just had to learn more.

But one Lisp, one Unix, one Linux distro, etc., It
sure has its appeal. In practice I think the
diversity/divergence is a strength. Only personally
I would never do a new language, a new media player,
or a new <something that already exists>. It is just
the way of the street. Different people are different,
in different ways.

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: member returns list

[Pascal J. Bourguignon]

Emanuel Berg <embe8573@student.uu.se> writes:

> "Pascal J. Bourguignon" <pjb@informatimago.com>
> writes:
>
>> Because each implementation worked on a different
>> machine with a different OS (if an OS was available
>> at all).
>
> Yeah, but there were many machines at the time of the
> "crazy language" C as well, still, there aren't
> a plethora of C dialects. (If you don't count all the
> epigone languages that borrowed heavily the syntax
> of C.)
>
> But C is famous for its portability (which also
> proliferated Unix) - perhaps the exception that
> confirms the rule, that Lisp is cooler than C?

It's not exactly the same time period, and not the same kind of
machines.

Basically, C was running on small machines, that were all the same.
After C the micro-processors appeared, and since they were so bad, they
soon were optimized to run C code efficiently.

On the other hand, Lisp was running on mainframes, each with a different
kind of processor.  Those were machines that could get new instructions
each week!

Granted, the CADR was a prototype:
https://c1.staticflickr.com/5/4040/4456481460_e7ef34f49e_b.jpg
so it wouldn't be surprising if it got new instructions hardwired often.
But it was also the case on other mainframe, commercially
installed.  They got upgrades that changed the instructions.


Also, a variant of what has already been discussed to death, C syntax is
so horrible than you don't dare implement a new parser: you get the
grammar from some previous compiler, and you use a parser generator to
parse the same.  On the other hand, there's no parser in lisp, and you
can implement a lisp reader in half a hour.  You can implement a running
lisp system in an afternoon (remember, EVAL is one page in AIM-8).

Basically, you can implement a lisp without having access to an old lisp
system, just by hearing about it and having a little light bulb going
tilt in your head.

Not so with C.



 
>> But basically, he started GNU emacs and designing
>> emacs lisp slightly beforem the CL standardization
>> process started, and it was far from obviouos that
>> it would succeed (it took ten years!).
>
> OK, but when it did "succeed", why not then?

It would have been too much work for a single programmer, and he
probably already had a lot of users writing emacs lisp code like crazy
demons.


> And, cannot CL be used from Elisp, with explicit
> notation (actually naming), but nonetheless?

Yes. There's emacs-cl.  But it bit-rotted on the passage from emacs 23
to 24 with lexical binding.



-- 
__Pascal Bourguignon__                 http://www.informatimago.com/
“The factory of the future will have only two employees, a man and a
dog. The man will be there to feed the dog. The dog will be there to
keep the man from touching the equipment.” -- Carl Bass CEO Autodesk

Re: member returns list

[Pascal J. Bourguignon]

"Pascal J. Bourguignon" <pjb@informatimago.com> writes:

> Emanuel Berg <embe8573@student.uu.se> writes:
>
>> "Pascal J. Bourguignon" <pjb@informatimago.com>
>> writes:
>>
>>> Because each implementation worked on a different
>>> machine with a different OS (if an OS was available
>>> at all).
>>
>> Yeah, but there were many machines at the time of the
>> "crazy language" C as well, still, there aren't
>> a plethora of C dialects. (If you don't count all the
>> epigone languages that borrowed heavily the syntax
>> of C.)
>>
>> But C is famous for its portability (which also
>> proliferated Unix) - perhaps the exception that
>> confirms the rule, that Lisp is cooler than C?
>
> It's not exactly the same time period, and not the same kind of
> machines.
>
> Basically, C was running on small machines, that were all the same.
> After C the micro-processors appeared, and since they were so bad, they
> soon were optimized to run C code efficiently.
>
> On the other hand, Lisp was running on mainframes, each with a different
> kind of processor.  Those were machines that could get new instructions
> each week!
>
> Granted, the CADR was a prototype:
> https://c1.staticflickr.com/5/4040/4456481460_e7ef34f49e_b.jpg
> so it wouldn't be surprising if it got new instructions hardwired often.
> But it was also the case on other mainframe, commercially
> installed.  They got upgrades that changed the instructions.
>
>
> Also, a variant of what has already been discussed to death, C syntax is
> so horrible than you don't dare implement a new parser: you get the
> grammar from some previous compiler, and you use a parser generator to
> parse the same.  On the other hand, there's no parser in lisp, and you
> can implement a lisp reader in half a hour.  You can implement a running
> lisp system in an afternoon (remember, EVAL is one page in AIM-8).
>
> Basically, you can implement a lisp without having access to an old lisp
> system, just by hearing about it and having a little light bulb going
> tilt in your head.
>
> Not so with C.

Also, an important part was that C is such a bad language, that the only
reason to implement it, is not to write new programs, but to run old
programs like the unix system, so there's an insentive to make compilers
that implement the same language over and over.

On the other hand, the reason to use lisp was to invent new kinds of
programs that have never been done so far, so there were less a reason
why to keep the same language.



Nowadays the situation is a little different. While it's still possible
to invent new kinds of programs (and programming paradygms), with Common
Lisp, people also want to be able to use libraries and reuse old
code.  Hence the standardization.

-- 
__Pascal Bourguignon__                 http://www.informatimago.com/
“The factory of the future will have only two employees, a man and a
dog. The man will be there to feed the dog. The dog will be there to
keep the man from touching the equipment.” -- Carl Bass CEO Autodesk

Re: member returns list

[Emanuel Berg]

"Pascal J. Bourguignon" <pjb@informatimago.com>
writes:

> On the other hand, the reason to use lisp was to
> invent new kinds of programs that have never been
> done so far, so there were less a reason why to keep
> the same language.

With the dialects, I don't see new things, I see
basically the same thing over and over with some small
differences that do not motivate redoing it each time.
But, if it is as simple as you say, they activity
itself may be the reward for doing it, so do it, by
all means.

> Nowadays the situation is a little different.
> While it's still possible to invent new kinds of
> programs (and programming paradygms), with Common
> Lisp, people also want to be able to use libraries
> and reuse old code. Hence the standardization.

What I can see, programming is dead. There are a bunch
of computer people that have everything they need.
Nothing new to do there. Then there are the masses
which must be fooled to consume inferior things which
they actually are not benefited from at all. If you
don't want to do that there really is nothing to do.
This is why I abandoned it. The reason I'm still here
to some extent is I still want to learn more and
perhaps someday the state will change tho I'm not
positive it will happen...

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: member returns list

[Robert Thorpe]

"Pascal J. Bourguignon" <pjb@informatimago.com> writes:

> "Pascal J. Bourguignon" <pjb@informatimago.com> writes:
>
>> Emanuel Berg <embe8573@student.uu.se> writes:
>>
>>> "Pascal J. Bourguignon" <pjb@informatimago.com>
>>> writes:
>>>
>>>> Because each implementation worked on a different
>>>> machine with a different OS (if an OS was available
>>>> at all).
>>>
>>> Yeah, but there were many machines at the time of the
>>> "crazy language" C as well, still, there aren't
>>> a plethora of C dialects. (If you don't count all the
>>> epigone languages that borrowed heavily the syntax
>>> of C.)
>>>
>>> But C is famous for its portability (which also
>>> proliferated Unix) - perhaps the exception that
>>> confirms the rule, that Lisp is cooler than C?
>>
>> It's not exactly the same time period, and not the same kind of
>> machines.
>>
>> Basically, C was running on small machines, that were all the same.
>> After C the micro-processors appeared, and since they were so bad, they
>> soon were optimized to run C code efficiently.

I don't really agree with Pascal's view.

Anyway, there were some other reasons why Lisp implementations differed
between machines.  As Pascal said, the early Lisp implementations were
on mainframes.  Later on people tried to port Lisp to minicomputers and
microcomputers.  But, Lisp was already quite complex and it wasn't
possible to fit all the features.  So, some of the features got
excluded, and which were excluded varied.

Pascal criticizes early micro-processors for being bad.  But, to those
who used them it was often a choice of micro-processor or no processors
at all.  In that situation compile-only languages with a strong emphasis
on efficiency (such as C) were the natural choice.  We're all in a
different situation now.

BR,
Robert Thorpe

Re: member returns list

[Emanuel Berg]

Robert Thorpe <rt@robertthorpeconsulting.com> writes:

> Pascal criticizes early micro-processors for being
> bad. But, to those who used them it was often
> a choice of micro-processor or no processors at all.
> In that situation compile-only languages with
> a strong emphasis on efficiency (such as C) were the
> natural choice. We're all in a different
> situation now.

I'm on Linux which is a C implementation of the UNIX
C. I use the GNU implementation of the UNIX toolchain
- all C (almost). Emacs is C (with Lisp on top of it).
Apart from that I use zsh - C. And so on!

Feel free to verify this with your most basic tools
(e.g., ls(1)) - and up and until the superstar
applications: Emacs, the shell, and so on!

Try the command "get-command-source" from

    http://user.it.uu.se/~embe8573/conf/.zsh/apt

to get the source just by feeding command names (e.g.,
'get-command-source ls' for ls).

I prefer Lisp for several reasons: it is more
advanced, no (re)compilation while debugging, no or
much less bulky type work, the code gets more modular,
no bulky header file work, much less error prone (no
pointers and stuff like that), etc. etc.

But that doesn't mean C is as bad as described.
If I would use a compiled language for an application
that needed it, I would use either C or C++. Those are
just different mindsets than Lisp.

I know from experience that Lisp, C++, and shell
programming can be a killer combo in one and the same
project. It all matters how you use them. If you do
crazy OO inheritance stuff etc. in C++ then of course
"C++" sucks. Stupid is as stupid does. It is not
about that.

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: member returns list

[Pascal J. Bourguignon]

Emanuel Berg <embe8573@student.uu.se> writes:

> I prefer Lisp for several reasons
> But that doesn't mean C is as bad as described.

Somebody is in need of reading the Unix Hater Handbook.
http://web.mit.edu/simsong/www/ugh.pdf

-- 
__Pascal Bourguignon__                 http://www.informatimago.com/
“The factory of the future will have only two employees, a man and a
dog. The man will be there to feed the dog. The dog will be there to
keep the man from touching the equipment.” -- Carl Bass CEO Autodesk

Re: member returns list

[Emanuel Berg]

"Pascal J. Bourguignon" <pjb@informatimago.com>
writes:

>> I prefer Lisp for several reasons ... But that
>> doesn't mean C is as bad as described.
>
> Somebody is in need of reading the Unix Hater
> Handbook. http://web.mit.edu/simsong/www/ugh.pdf

Ha ha, curse me for a servo-droid!

Actually I love when you suggest books, especially
when they are self-contained PDFs which can be printed
free of charge. (Thanks to Drew for the history book
while I'm at it.)

Why don't you do a Lisp OS with Lisp-only software?

Are there any particularly impressive Lisp programs
I can try? A window manager, for example?

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: member returns list

[Emanuel Berg]

Valentijn <valentijn@openmailbox.org> writes:

> I know of four Window Managers made in Lisp and all
> of them are super interesting. You've Common Lisp
> FullScreen Window Manager, Sawfish, Stumpwm, and
> exwm

sawfish and stumpwm has been mentioned. exwm isn't in
my repos. There is one "clfswm" which I'll try next.

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: member returns list

[Emanuel Berg]

Emanuel Berg <embe8573@student.uu.se> writes:

>> I know of four Window Managers made in Lisp and all
>> of them are super interesting. You've Common Lisp
>> FullScreen Window Manager, Sawfish, Stumpwm, and
>> exwm
>
> sawfish and stumpwm has been mentioned. exwm isn't
> in my repos. There is one "clfswm" which I'll
> try next.

clfswm has the same issues I saw with stumpwm (except
for the error messages). So much for the "fullscreen"
stuff, eh?

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: member returns list

[Pascal J. Bourguignon]

Emanuel Berg <embe8573@student.uu.se> writes:

> Why don't you do a Lisp OS with Lisp-only software?

Time. Money.

> Are there any particularly impressive Lisp programs
> I can try? A window manager, for example?

Indeed, there is stumpwm.

There are a lot of CL servers and applications, it would only take time
to integrate them into a system with some kind of kernel (eg. a Linux
kernel, for the drivers), writing a init(1) in lisp.

But I would expect that it would take more time to polish the result
into a really usable system.  I'd bet on having the first integration
done would motivate people to polish it.

On the other hand, there's also Mezzano if you want to try a recent
LispOS written in CL.

-- 
__Pascal Bourguignon__                 http://www.informatimago.com/
“The factory of the future will have only two employees, a man and a
dog. The man will be there to feed the dog. The dog will be there to
keep the man from touching the equipment.” -- Carl Bass CEO Autodesk

Re: member returns list

[Alex Kost]

Pascal J. Bourguignon (2015-09-10 07:21 +0300) wrote:

> Emanuel Berg <embe8573@student.uu.se> writes:
>
>> Why don't you do a Lisp OS with Lisp-only software?
>
> Time. Money.
>
>> Are there any particularly impressive Lisp programs
>> I can try? A window manager, for example?
>
> Indeed, there is stumpwm.

If Scheme is Lispy enough for you, then there is also guile-wm [1].

> There are a lot of CL servers and applications, it would only take time
> to integrate them into a system with some kind of kernel (eg. a Linux
> kernel, for the drivers), writing a init(1) in lisp.
>
> But I would expect that it would take more time to polish the result
> into a really usable system.  I'd bet on having the first integration
> done would motivate people to polish it.
>
> On the other hand, there's also Mezzano if you want to try a recent
> LispOS written in CL.

As for the operating system, there is "Guix System Distribution" [2]
which is based on Guile.  It uses dmd as its init system (also written
in Guile).  You can also try Guix package manager on your current
system; it will not interfere with the package manager of your system.
I would say it's a very "impressive Lisp program".

[1] https://github.com/mwitmer/guile-wm
[2] https://www.gnu.org/software/guix

-- 
Alex

Re: member returns list

[Random832]

Alex Kost <alezost@gmail.com> writes:

> Pascal J. Bourguignon (2015-09-10 07:21 +0300) wrote:
>> Emanuel Berg <embe8573@student.uu.se> writes:
>> Indeed, there is stumpwm.
>
> If Scheme is Lispy enough for you, then there is also guile-wm [1].

And a discussion of Lisp-dialect-based window managers isn't complete
without mentioning Sawfish, which was briefly the default GNOME window
manager. It is built on something called "Librep", which is described as
a cross between elisp and scheme.

Re: member returns list

[Emanuel Berg]

Random832 <random832@fastmail.com> writes:

> And a discussion of Lisp-dialect-based window
> managers isn't complete without mentioning Sawfish,
> which was briefly the default GNOME window manager.
> It is built on something called "Librep", which is
> described as a cross between elisp and scheme.

Both stumpwm and sawfish install with no problems and
executes fine by just putting either of

    stumpwm &
    sawfish &

in ~/.xinitrc - however stumpwm doesn't come with the
familiar M-TAB application menu by default.

sawfish does, tho the menu doesn't look as nice as
with openbox (which is in C, by the way).

But sawfish in one way does this better than openbox,
as it doesn't highlight the to-be-focused window when
you iterate the menu with an annoying border. If I can
find a better looking theme for sawfish, or edit it by
hand, I'll take it.

stumpwm also outputs lots of error messages.

stumpwm also doesn't give focus to the one
fullscreened window unless the mouse pointer is over
it; this can be solved by

    DISPLAY=:0 xdotool mousemove 0 0

tho then you have to live with the annoying pointer
being visible until you start typing.

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: member returns list

[Emanuel Berg]

Emanuel Berg <embe8573@student.uu.se> writes:

> stumpwm doesn't come with the familiar M-TAB
> application menu by default.
>
> sawfish does, tho the menu doesn't look as nice as
> with openbox (which is in C, by the way).

I take that back. sawfish doesn't have a menu - one
can only switch from one window to the next with
M-TAB. Also, with several windows doing mplayer, this
implies a graphic bug when you switch.

So far the Lisp WM experience has left me unimpressed.

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: member returns list

[Random832]

Emanuel Berg <embe8573@student.uu.se> writes:
> I take that back. sawfish doesn't have a menu

I can't test it now, but it looks like Super-Tab and C-Tab are mapped by
default to something called "cabinet-switch" that looks promising.

Re: member returns list

[Pascal J. Bourguignon]

Emanuel Berg <embe8573@student.uu.se> writes:

> Emanuel Berg <embe8573@student.uu.se> writes:
>
>> stumpwm doesn't come with the familiar M-TAB
>> application menu by default.
>>
>> sawfish does, tho the menu doesn't look as nice as
>> with openbox (which is in C, by the way).
>
> I take that back. sawfish doesn't have a menu - one
> can only switch from one window to the next with
> M-TAB. Also, with several windows doing mplayer, this
> implies a graphic bug when you switch.
>
> So far the Lisp WM experience has left me unimpressed.

Then you are unimpressed by yourself.  The point of those, of course, is
to let the user (ie. yourself) be programming in Common Lisp the window
manager to suit your taste, just like you do in GNU emacs.

-- 
__Pascal Bourguignon__                 http://www.informatimago.com/
“The factory of the future will have only two employees, a man and a
dog. The man will be there to feed the dog. The dog will be there to
keep the man from touching the equipment.” -- Carl Bass CEO Autodesk

Re: member returns list

[Emanuel Berg]

"Pascal J. Bourguignon" <pjb@informatimago.com>
writes:

> Then you are unimpressed by yourself. The point of
> those, of course, is to let the user (ie. yourself)
> be programming in Common Lisp the window manager to
> suit your taste, just like you do in GNU emacs.

Not exactly like I do in GNU Emacs! Here, the
application is a hybrid between general things that
are the same everywhere and specific things (the
modes) that relate to a certain task. Even so, stuff
you set up for a specific mode are easily transferred
to another mode, if that should be called for, as
configuration is done the same way everywhere. So the
reward and result from configuration can be big, while
the effort doing it is small and enjoyable, because of
the Elisp familiarity and the "Emacs to improve Emacs"
method.

Because them WMs are in Lisp with a Lisp dynamic
interpreter, I'd say they are much better off with
respect to this than say a WM in C which would have to
be recompiled for each change.

Still, I don't use a WM that much to make it
worthwhile, so I might as well use the WM which is to
the best of my liking the first time I start it, and
that is currently Openbox which, again, is in C, and
there is nothing wrong with that.

This whole discussion tho showed to anyone who didn't
know that yes, there are WMs in Lisp.

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: member returns list

[Ian Zimmerman]

On 2015-09-11 03:28 +0200, Emanuel Berg wrote:

> But sawfish in one way does this better than openbox,
> as it doesn't highlight the to-be-focused window when
> you iterate the menu with an annoying border.

This is totally configurable.  Just read the example commented config
file for openbox.

I used sawfish before I switched to openbox, btw.  Then I was torn
between the two for a while until I stole the sawfish new window
placement algorithm and ported it to openbox [1].  Then the maintainers
made the mistake of making it the default, causing every Tom, Dick &
Harry to request the old broken behavior, but that's another story.

[1]
https://github.com/danakj/openbox/commits/master/openbox/place_overlap.c

-- 
Please *no* private copies of mailing list or newsgroup messages.
Rule 420: All persons more than eight miles high to leave the court.

Re: member returns list

[Emanuel Berg]

Alex Kost <alezost@gmail.com> writes:

> As for the operating system, there is "Guix System
> Distribution" [2] which is based on Guile. It uses
> dmd as its init system (also written in Guile).
> You can also try Guix package manager on your
> current system; it will not interfere with the
> package manager of your system. I would say it's
> a very "impressive Lisp program".

Neither guile-wm nor guix are in my Debian repos. But,
stumpwm is.

The reason I asked for a WM isn't that I use such
extensively. Actually, I use openbox(1), but only so
I can switch between mplayer and xterm with M-TAB (in
Emacs' notation).

The reason is instead that it is easy to see and
experience the functionality and the degree of
polishness. I don't think a package manager can do
the same.

Give me demo party material!

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: member returns list

[Emanuel Berg]

"Pascal J. Bourguignon" <pjb@informatimago.com>
writes:

>> Why don't you do a Lisp OS with Lisp-only software?
>
> Time. Money.

OK, what I meant was actually again why Lisp is so
marginalized. Not only in "industry" (yuk, that is
a stupid word) but also in the systems we use every
day. Every program I ever use is written in C (except
for Emacs which is C and Lisp). Do you think the
association between C and Unix, strong as it may, is
enough to explain this? The only big program which
I use that I can think of which is Lisp-only is Gnus
which is a part of Emacs.

>> Are there any particularly impressive Lisp programs
>> I can try? A window manager, for example?
>
> Indeed, there is stumpwm.

OK, I'll try it tonight.

> There are a lot of CL servers and applications, it
> would only take time to integrate them into a system
> with some kind of kernel (eg. a Linux kernel, for
> the drivers), writing a init(1) in lisp.

init! It is systemd(1) now:

    lrwxrwxrwx 1 root 20 Sep 28  2014 /sbin/init -> /lib/systemd/systemd

But: Keeping the Linux kernel (which is in C) and then
starting to replace the typical components in a Unix
or Linux system (which are all in C) with ditto in
Lisp, I don't see the purpose of that. What would be
interesting is a system that is Lispic, not just
another Unix only written in Lisp, which would be
stupid at best.

> On the other hand, there's also Mezzano if you want
> to try a recent LispOS written in CL.

Do you have hyperlinks to a bootable DVD or USB?

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: member returns list

[tomas]

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

On Fri, Sep 11, 2015 at 02:57:06AM +0200, Emanuel Berg wrote:
> "Pascal J. Bourguignon" <pjb@informatimago.com>
> writes:
> 
> >> Why don't you do a Lisp OS with Lisp-only software?
> >
> > Time. Money.
> 
> OK, what I meant was actually again why Lisp is so
> marginalized. Not only in "industry" (yuk, that is
> a stupid word) but also in the systems we use every
> day [...]

See [1] for the historical perspective. Without Lisp machines
there'd be no Smalltalk (and most of the OO craze these days).
Emacs itself is an echo of those Lisp machines. Java owes a
lot to Lisp. Just go digging and you''ll find Lisp roots
everywhere.

The fact is that Market Forces and the Invisible Hand always
chooses wisely the best altenative (excuse my snark, had a
bad day yesterday ;-)

[1] <https://en.wikipedia.org/wiki/Lisp_machine>

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

iEYEARECAAYFAlXyackACgkQBcgs9XrR2kb2GwCfZSj4tWEb7bMr+BeVY+kg3Imv
RiUAnR8GcUhMmJCS/BC8i5ucFtDVJULT
=QG3u
-----END PGP SIGNATURE-----

Re: member returns list

[Emanuel Berg]

<tomas@tuxteam.de> writes:

> See [1] for the historical perspective. Without Lisp
> machines there'd be no Smalltalk (and most of the OO
> craze these days).

The 90s rather.

> Java owes a lot to Lisp.

That doesn't show :)

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: member returns list

[tomas]

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

On Sat, Sep 12, 2015 at 02:18:07AM +0200, Emanuel Berg wrote:
> <tomas@tuxteam.de> writes:
> 
> > See [1] for the historical perspective. Without Lisp
> > machines there'd be no Smalltalk (and most of the OO
> > craze these days).
> 
> The 90s rather.
> 
> > Java owes a lot to Lisp.
> 
> That doesn't show :)

I wasn't thinking about the "taste" department [1]. They have
accumulated quite a bit of interesting stuff in terms of JIT,
optimization and so on -- but definitely the Big Enterprise Way,
usually by throwing tons of (mostly fungible) developers and money
at it. Have a look at Mike Pall's LuaJIT to see that this can be
done differently. OTOH I'm sure Mike Pall's path would have been
more dangerous and difficult had it not ben blazed earlier
(bulldozed?) by the Java JIT people.

But the pioneers on this path? Self & al. Again Lisp.

[1] I don't want to discuss taste & Java in one context. I've
just had breakfast.

- -- t
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlX1MAkACgkQBcgs9XrR2kZMmACfZmVkl/5aXEmyby6n4EOYmVvV
vOcAn1/rDnWynyG51kGe+vnyeUzdHffC
=yQa7
-----END PGP SIGNATURE-----

Re: member returns list

[Pascal J. Bourguignon]

<tomas@tuxteam.de> writes:

> On Fri, Sep 11, 2015 at 02:57:06AM +0200, Emanuel Berg wrote:
>> "Pascal J. Bourguignon" <pjb@informatimago.com>
>> writes:
>> 
>> >> Why don't you do a Lisp OS with Lisp-only software?
>> >
>> > Time. Money.
>> 
>> OK, what I meant was actually again why Lisp is so
>> marginalized. Not only in "industry" (yuk, that is
>> a stupid word) but also in the systems we use every
>> day [...]
>
> See [1] for the historical perspective. Without Lisp machines
> there'd be no Smalltalk (and most of the OO craze these days).

No Smalltalk -> no lisa -> no Macintosh -> no MS-Windows and no NeXTSTEP
(Apple would be dead by now) -> MacOSX -> no iPad/iPhone.

No Java -> no Android.


Imagine if the bitmap displays were only used on high end workstations
for scientific data representation, and in low-end PC for games.

Most PC would still work with text screens.

> Emacs itself is an echo of those Lisp machines. Java owes a
> lot to Lisp. Just go digging and you''ll find Lisp roots
> everywhere.
>
> The fact is that Market Forces and the Invisible Hand always
> chooses wisely the best altenative (excuse my snark, had a
> bad day yesterday ;-)
>
> [1] <https://en.wikipedia.org/wiki/Lisp_machine>
>
> Regards
> -- tomás

-- 
__Pascal Bourguignon__                 http://www.informatimago.com/
“The factory of the future will have only two employees, a man and a
dog. The man will be there to feed the dog. The dog will be there to
keep the man from touching the equipment.” -- Carl Bass CEO Autodesk

Re: member returns list

[Emanuel Berg]

"Pascal J. Bourguignon" <pjb@informatimago.com>
writes:

> No Smalltalk -> no lisa -> no Macintosh -> no
> MS-Windows and no NeXTSTEP (Apple would be dead by
> now) -> MacOSX -> no iPad/iPhone.
>
> No Java -> no Android.
>
> Imagine if the bitmap displays were only used on
> high end workstations for scientific data
> representation, and in low-end PC for games.
>
> Most PC would still work with text screens.

Did Smalltalk have any positive consequences as well?

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: member returns list

[Pascal J. Bourguignon]

Emanuel Berg <embe8573@student.uu.se> writes:

> "Pascal J. Bourguignon" <pjb@informatimago.com>
> writes:
>
>> No Smalltalk -> no lisa -> no Macintosh -> no
>> MS-Windows and no NeXTSTEP (Apple would be dead by
>> now) -> MacOSX -> no iPad/iPhone.
>>
>> No Java -> no Android.
>>
>> Imagine if the bitmap displays were only used on
>> high end workstations for scientific data
>> representation, and in low-end PC for games.
>>
>> Most PC would still work with text screens.
>
> Did Smalltalk have any positive consequences as well?

No Smalltalk -> no Lisa.

-- 
__Pascal Bourguignon__                 http://www.informatimago.com/
“The factory of the future will have only two employees, a man and a
dog. The man will be there to feed the dog. The dog will be there to
keep the man from touching the equipment.” -- Carl Bass CEO Autodesk

Re: member returns list

[Emanuel Berg]

"Pascal J. Bourguignon" <pjb@informatimago.com>
writes:

> No Smalltalk -> no Lisa.

LISA: the "LISA invented silly acronym" computer that
Steve Jobs named after his daughter, which he didn't
recognize at this moment of strange and
misguided affection.

LISA was the computer in-between the hackish and
social Apple 2 (which Steve Wozniak built), and the
posh, pre-chewed, and all-Jobish Macintosh which was
supposedly stylish and minimalist (that was true at
least with respect to software as there were only
MacPaint, MacWord, HyperCard and [Beyond] Dark Caste
and a few more programs to run).

LISA was much more powerful than the Mac but failed
miserably which is why the Apple people put into the
LISAs a Mac emulator which made it possible to run Mac
software. Then they rebranded LISA "The Mac XL" which
in some ways was correct.

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: member returns list

[tomas]

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

On Sat, Sep 12, 2015 at 04:01:46AM +0200, Pascal J. Bourguignon wrote:
> Emanuel Berg <embe8573@student.uu.se> writes:
> 
> > "Pascal J. Bourguignon" <pjb@informatimago.com>
> > writes:
> >
> >> No Smalltalk -> no lisa -> no Macintosh -> no
> >> MS-Windows and no NeXTSTEP (Apple would be dead by
> >> now) -> MacOSX -> no iPad/iPhone.
> >>
> >> No Java -> no Android.
> >>
> >> Imagine if the bitmap displays were only used on
> >> high end workstations for scientific data
> >> representation, and in low-end PC for games.
> >>
> >> Most PC would still work with text screens.
> >
> > Did Smalltalk have any positive consequences as well?
> 
> No Smalltalk -> no Lisa.

Modula-2. Oberon. (Niklaus Wirth acknowledges the inspiration to his
stay at PARC).

Whatever. Much fun in computing anyway (anyone remember the Byte Magazine
cover to Smalltalk, with the colorful balloon? Sigh. That old)

- -- t
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlX1KtkACgkQBcgs9XrR2kbzsQCeMnsV4gJx/dCabFbZZwfqWZqO
b/gAn17Kq+ORflMmJB/TWllp9Q4DlXJR
=1igD
-----END PGP SIGNATURE-----

Re: member returns list

[Pascal J. Bourguignon]

Emanuel Berg <embe8573@student.uu.se> writes:

> "Pascal J. Bourguignon" <pjb@informatimago.com>
> writes:
>
>> No Smalltalk -> no lisa -> no Macintosh -> no
>> MS-Windows and no NeXTSTEP (Apple would be dead by
>> now) -> MacOSX -> no iPad/iPhone.
>>
>> No Java -> no Android.
>>
>> Imagine if the bitmap displays were only used on
>> high end workstations for scientific data
>> representation, and in low-end PC for games.
>>
>> Most PC would still work with text screens.
>
> Did Smalltalk have any positive consequences as well?

Also, I didn't show the transitivities, but:
No Smalltalk -> no Objective-C -> no NeXTSTEP
No Lisp -> no Interface Builder -> no NeXTSTEP
No NeXTSTEP -> no MacOSX -> no iOS -> no iPad/iPhone.

-- 
__Pascal Bourguignon__                 http://www.informatimago.com/
“The factory of the future will have only two employees, a man and a
dog. The man will be there to feed the dog. The dog will be there to
keep the man from touching the equipment.” -- Carl Bass CEO Autodesk

Re: member returns list

[Stefan Monnier]

> Also, I didn't show the transitivities, but:
> No Smalltalk -> no Objective-C -> no NeXTSTEP
> No Lisp -> no Interface Builder -> no NeXTSTEP
> No NeXTSTEP -> no MacOSX -> no iOS -> no iPad/iPhone.

FWIW, history usually shows that most inventions don't depend on one
particular person inventing that thing, but rather on a particular
context making that thing desirable/reachable/useful, at which point
some (set of) people usually invent similar things around the same time.

So while the world might look a bit different if
Smalltalk/Lisp/younameit hadn't been invented, it probably wouldn't be
all that different since someone else would have invented something
similar anyway.


        Stefan

Re: member returns list

[Emanuel Berg]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> FWIW, history usually shows that most inventions
> don't depend on one particular person inventing that
> thing, but rather on a particular context making
> that thing desirable/reachable/useful, at which
> point some (set of) people usually invent similar
> things around the same time.
>
> So while the world might look a bit different if
> Smalltalk/Lisp/younameit hadn't been invented, it
> probably wouldn't be all that different since
> someone else would have invented something
> similar anyway.

There is even a science fiction short story about
a guy with a time machine thinking he can go back in
time and make a fortune by inventing all sort of
things that he knows of from the future, only one day
or so before they were actually "invented". And he
fails miserably each time, just because he is so out
of context and his knowledge is only on-the-surface
scholasticism. Just think: everyone knows how a light
bulb works, but everyone doesn't feel as confident
going back to the 1870 to beat Edison to the punch!

Also, this word "invention" is misleading in many
cases. Often it is more about construction. They add
one bolt here and one screw here. With patience, luck,
and skills, in time, someone will stumble in the last
correct screw that will make the construction
something unique. Just like boiling water, the
quantitative difference between say 66 and 67 degrees
Celsius won't matter in isolation, but the same change
- only from 99 to 100 degrees - will make the water
boil - a qualitative difference, in state. Here, we
see that 67-66 = 100-99 = 1, but also that, to get
from 99 to 100 with water of say ~37 degrees, you must
first get up to, and past "66 to 67" before you are
even close to "99 to 100"...

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: member returns list

[Emanuel Berg]

"Pascal J. Bourguignon" <pjb@informatimago.com>
writes:

> Also, I didn't show the transitivities, but: No
> Smalltalk -> no Objective-C -> no NeXTSTEP No Lisp
> -> no Interface Builder -> no NeXTSTEP No NeXTSTEP
> -> no MacOSX -> no iOS -> no iPad/iPhone.

If I ever get my time machine going, first thing after
spending a decade in the 90s' Ibiza listening to
eurodisco and dropping E, remind me to go back to 1969
and terminate Alan Kay. Or better yet, I can just
bring an iPhone and he'll probably grab for the
revolver himself!

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: member returns list

[Pascal J. Bourguignon]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> Also, I didn't show the transitivities, but:
>> No Smalltalk -> no Objective-C -> no NeXTSTEP
>> No Lisp -> no Interface Builder -> no NeXTSTEP
>> No NeXTSTEP -> no MacOSX -> no iOS -> no iPad/iPhone.
>
> FWIW, history usually shows that most inventions don't depend on one
> particular person inventing that thing, but rather on a particular
> context making that thing desirable/reachable/useful, at which point
> some (set of) people usually invent similar things around the same time.
>
> So while the world might look a bit different if
> Smalltalk/Lisp/younameit hadn't been invented, it probably wouldn't be
> all that different since someone else would have invented something
> similar anyway.

You bet!

Given how accepted and mainstream lisp is, I can perfectly imagine a
universe where it would be totally ignored and where we'd lose all its
offsprings.

For example, Backus, of BNF and Fortran frame, wrote a paper about
functional programming in 1959!  You can bet it would still be ignored
if lisp hadn't shown the path with a garbage collector and high order
functions, and if it hadn't existed to develop ML and from this all the
functional programming language to Haskell nowadays.

If you want to argue that lisp wasn't essential, then explain the delay
between 1959 and ML which has been developed only in 1970!


Similarly for the web.  Without lisp and the interface builder (a
macintosh program written in lisp originally, and therefore doubly
dependent on lisp (from the lisp->smalltalk->parc->apple->lisa->mac and
from the lisp->dynamic-programming->UI paths), you wouldn't have had
nextstep where it was easy, obvious and trivial even, to develop html
and WWW server/browser, given the building blocks available.  The
alternative at the time was Xanadu on the hypertext side, SGML on the
document side, and gopher on the client/server side.  They could have
spend tens of years trying to mix two or three of those into something
vaguely ressembling the www, without lisp and NeXTSTEP.



-- 
__Pascal Bourguignon__                 http://www.informatimago.com/
“The factory of the future will have only two employees, a man and a
dog. The man will be there to feed the dog. The dog will be there to
keep the man from touching the equipment.” -- Carl Bass CEO Autodesk

Re: member returns list

[Emanuel Berg]

"Pascal J. Bourguignon" <pjb@informatimago.com>
writes:

> Given how accepted and mainstream lisp is, I can
> perfectly imagine a universe where it would be
> totally ignored and where we'd lose all
> its offsprings.

Some of the novelties that were introduced and/or
refined in Lisp are perhaps mainstream today, in other
languages and systems, but Lisp is not.

Actually it is totally marginalized. I know this from
reading job ads for one. Out of a hundred ads, there
is tons of Java, a lot C#, some web programming in
different languages, some SQL, and one or two oddball
projects and leftovers in C, C++ or even
older languages.

But there isn't *a single* ad for a Lisp programmer!
Even in the non-commercial world, very, very few young
programmers turn to Lisp. Even the
"functional programming" goofballs at the universities
most often do Haskell and not Lisp (or ML).

> For example, Backus, of BNF and Fortran frame, wrote
> a paper about functional programming in 1959!
> You can bet it would still be ignored if lisp hadn't
> shown the path with a garbage collector and high
> order functions, and if it hadn't existed to develop
> ML and from this all the functional programming
> language to Haskell nowadays.

We can bet all we want but never know for sure.
Even the premise "no Lisp" is dubious. Because, why
was there a Lisp? Say, there was a Lisp because of
factors A, B, and C. Now, if we are to remove Lisp
from history and then figure out what the world of
today would have looked like, should we not only
remove Lisp, but also A, B, and C? But if we do that,
how do we know they didn't create something else, in
parallel with Lisp? Should we remove that as well?
It is like a dough, or a tree, rather than the linear
chain of events as you put it. Nothing can ever be
removed or inserted that is there or isn't there.

> Similarly for the web. Without lisp and the
> interface builder (a macintosh program written in
> lisp originally, and therefore doubly dependent on
> lisp (from the
> lisp->smalltalk->parc->apple->lisa->mac and from the
> lisp->dynamic-programming->UI paths), you wouldn't
> have had nextstep where it was easy, obvious and
> trivial even, to develop html and WWW
> server/browser, given the building blocks available.
> The alternative at the time was Xanadu on the
> hypertext side, SGML on the document side, and
> gopher on the client/server side. They could have
> spend tens of years trying to mix two or three of
> those into something vaguely ressembling the www,
> without lisp and NeXTSTEP.

I'm surprised you haven't mentioned XML. No Lisp, no
XML, right?

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: member returns list

[tomas]

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

On Sun, Sep 13, 2015 at 01:38:08AM +0200, Emanuel Berg wrote:

[...]

> Actually it is totally marginalized. I know this from
> reading job ads for one. Out of a hundred ads, there
> is tons of Java, a lot C# [...]

That's because of The Pyramids [1]

> I'm surprised you haven't mentioned XML. No Lisp, no
> XML, right?

DSSL. XSLT. Right.

[1] The original quote (by Alan Perlis) goes about Pascal, but I think
we can confidently substitute Java as a worthi (if uglier) successor:

  "[Scheme and Pascal] It would be difficult to find two languages
   that are the communicating coin of two more different cultures
   than those gathered around these two languages. Pascal is for
   building pyramids -- imposing, breathtaking, static structures
   built by armies pushing heavy blocks into place. Lisp is for
   building organisms [...]"

You need a lot of slaves to build pyramids (yeah, I know: strictly
speaking, the pyramid builders weren't slaves, but hey).

- -- t
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlX1LbkACgkQBcgs9XrR2kZGfwCfVCOxVaYPCKbZqmdy9VURyRS3
POUAn1Z10OPXj3BLuaxCQdkDQPGP2hO+
=Jij+
-----END PGP SIGNATURE-----

Re: member returns list

[Emanuel Berg]

<tomas@tuxteam.de> writes:

> You need a lot of slaves to build pyramids (yeah,
> I know: strictly speaking, the pyramid builders
> weren't slaves, but hey).

You need long-ears to build pyramids, or actually to
build or achieve anything, long-ears that work
24/7/365 for generations, perfecting the craft, and
not be disturbed by short-ears all the time with their
wars and destructiveness.

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: member returns list

[Pascal J. Bourguignon]

Emanuel Berg <embe8573@student.uu.se> writes:

> We can bet all we want but never know for sure.
> Even the premise "no Lisp" is dubious. Because, why
> was there a Lisp? Say, there was a Lisp because of
> factors A, B, and C. Now, if we are to remove Lisp
> from history and then figure out what the world of
> today would have looked like, should we not only
> remove Lisp, but also A, B, and C? But if we do that,
> how do we know they didn't create something else, in
> parallel with Lisp? Should we remove that as well?
> It is like a dough, or a tree, rather than the linear
> chain of events as you put it. Nothing can ever be
> removed or inserted that is there or isn't there.

The only reason there's LISP was John McCarthy.

He started to work on LISP because Fortran and Algol designers didn't
want to include language features John McCarthy deemed useful, like
ternary IF and COND, or recursivity.  It was plain out of Fortran scope
(and remained so for a long time) and was only included into Algol by
ruse. 
https://vanemden.wordpress.com/2014/06/18/how-recursion-got-into-programming-a-comedy-of-errors-3/

Notice that list processing (with XCARF and XCDRF) already existed in
Fortran as FLPL (it was invented by Newell, Shaw, and Simon, not by John
McCarthy).  http://www.informatimago.com/articles/flpl/


And I won't say anything about the stress given to Turing Machines over
Lambda Calculus, my bet again is that without John McCarthy, nobody
would know about Church's work anymore.


>> Similarly for the web. Without lisp and the
>> interface builder (a macintosh program written in
>> lisp originally, and therefore doubly dependent on
>> lisp (from the
>> lisp->smalltalk->parc->apple->lisa->mac and from the
>> lisp->dynamic-programming->UI paths), you wouldn't
>> have had nextstep where it was easy, obvious and
>> trivial even, to develop html and WWW
>> server/browser, given the building blocks available.
>> The alternative at the time was Xanadu on the
>> hypertext side, SGML on the document side, and
>> gopher on the client/server side. They could have
>> spend tens of years trying to mix two or three of
>> those into something vaguely ressembling the www,
>> without lisp and NeXTSTEP.
>
> I'm surprised you haven't mentioned XML. No Lisp, no
> XML, right?

Nope. 
XML comes from SGML -> HTML (dead-end), therefore SGML -> XML.


Only good things can derive from Lisp.

-- 
__Pascal Bourguignon__                 http://www.informatimago.com/
“The factory of the future will have only two employees, a man and a
dog. The man will be there to feed the dog. The dog will be there to
keep the man from touching the equipment.” -- Carl Bass CEO Autodesk

Re: member returns list

[John Mastro]

> The only reason there's LISP was John McCarthy.

This is a little like saying that without Sir Isaac Newton there would
be no gravity ;-)

-- 
john

Re: member returns list

[Pascal J. Bourguignon]

John Mastro <john.b.mastro@gmail.com> writes:

>> The only reason there's LISP was John McCarthy.
>
> This is a little like saying that without Sir Isaac Newton there would
> be no gravity ;-)

Not at all, but since you didn't read the explainations, you sure still
don't know why.

-- 
__Pascal Bourguignon__                 http://www.informatimago.com/
“The factory of the future will have only two employees, a man and a
dog. The man will be there to feed the dog. The dog will be there to
keep the man from touching the equipment.” -- Carl Bass CEO Autodesk

computer history (was: Re: member returns list)

[Emanuel Berg]

"Pascal J. Bourguignon" <pjb@informatimago.com>
writes:

> Nope. XML comes from SGML -> HTML (dead-end),
> therefore SGML -> XML.
>
> Only good things can derive from Lisp.

Tho I didn't agree with the attitude "no this, no
that" in principle, that doesn't mean this wasn't
exactly what happened in the only history which
is real.

So here is what you have said so far, with some edits
to the form only.

Perhaps you can expand it even further both backward
and forward in time?

It could start with the transistor in the 40s/50s
(Nobel Prize in Physics in 1956) and end with the most
recent advances, for examples e-mail and
Walkie Talkies.

Speaking of communication, that isn't included at all
save for the "HTTP/www": mail, Usenet, and SMSs should
be there - somewhere!

Also, the edges (if this is a FSM) should perhaps
carry labels why there is a transition and/or in
what sense?

Anyways:

SGML -> HTML -> XML

LISP -> Smalltalk -> Parc -> Apple -> LISA -> Macintosh -> Windows

Smalltalk -> Objective-C -> NeXTSTEP -> Mac OS X -> iOS -> iPad -> iPhone

NeXTSTEP -> HTTP/www -> Google, Facebook, Twitter

Java -> Android

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: member returns list

[Pascal J. Bourguignon]

Emanuel Berg <embe8573@student.uu.se> writes:

> "Pascal J. Bourguignon" <pjb@informatimago.com>
> writes:
>
>> Also, I didn't show the transitivities, but: No
>> Smalltalk -> no Objective-C -> no NeXTSTEP No Lisp
>> -> no Interface Builder -> no NeXTSTEP No NeXTSTEP
>> -> no MacOSX -> no iOS -> no iPad/iPhone.
>
> If I ever get my time machine going, first thing after
> spending a decade in the 90s' Ibiza listening to
> eurodisco and dropping E, remind me to go back to 1969
> and terminate Alan Kay. Or better yet, I can just
> bring an iPhone and he'll probably grab for the
> revolver himself!

You are definitely crazy.

-- 
__Pascal Bourguignon__                 http://www.informatimago.com/
“The factory of the future will have only two employees, a man and a
dog. The man will be there to feed the dog. The dog will be there to
keep the man from touching the equipment.” -- Carl Bass CEO Autodesk

Re: member returns list

[Emanuel Berg]

"Pascal J. Bourguignon" <pjb@informatimago.com>
writes:

>>> Also, I didn't show the transitivities, but: No
>>> Smalltalk -> no Objective-C -> no NeXTSTEP No Lisp
>>> -> no Interface Builder -> no NeXTSTEP No NeXTSTEP
>>> -> no MacOSX -> no iOS -> no iPad/iPhone.
>>>
>> If I ever get my time machine going, first thing
>> after spending a decade in the 90s' Ibiza listening
>> to eurodisco and dropping E, remind me to go back
>> to 1969 and terminate Alan Kay. Or better yet,
>> I can just bring an iPhone and he'll probably grab
>> for the revolver himself!
>
> You are definitely crazy.

My people were once travellers and warriors. In yet
another era, we had an industrial capacity in parity
with the superpowers, and a super-educated workforce.
Now, people don't know jack about anything and they
don't even know what goes on half a meter to their
sides as they are enslaved by those one million times
accursed iThings. Physically and mentally those have
been a disaster to millions all over the world.
What Lisp has to do with them is beyond me as Lisp is
the most advanced programming language which implies
limitless creativity, whereas the iThings are very
dangerous toys that have already enslaved millions of
supposedly "adults" as well. Whenever I encounter old
people I see this very clearly - the difference in
posture, knowledge, skill, literacy, awareness,
self-confidence - it is just huge. Of course, there
were no iThings in their youths and adult lives so
they hade to take part in real activity, solve real
problems, communicate with real people, develop real
skills, and so on - every day. The people today who
never did any of that - well, it shows!

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: member returns list

[Pascal J. Bourguignon]

Emanuel Berg <embe8573@student.uu.se> writes:

> "Pascal J. Bourguignon" <pjb@informatimago.com>
> writes:
>
>>>> Also, I didn't show the transitivities, but: No
>>>> Smalltalk -> no Objective-C -> no NeXTSTEP No Lisp
>>>> -> no Interface Builder -> no NeXTSTEP No NeXTSTEP
>>>> -> no MacOSX -> no iOS -> no iPad/iPhone.
>>>>
>>> If I ever get my time machine going, first thing
>>> after spending a decade in the 90s' Ibiza listening
>>> to eurodisco and dropping E, remind me to go back
>>> to 1969 and terminate Alan Kay. Or better yet,
>>> I can just bring an iPhone and he'll probably grab
>>> for the revolver himself!
>>
>> You are definitely crazy.
>
> My people were once travellers and warriors. In yet
> another era, we had an industrial capacity in parity
> with the superpowers, and a super-educated workforce.
> Now, people don't know jack about anything and they
> don't even know what goes on half a meter to their
> sides as they are enslaved by those one million times
> accursed iThings. Physically and mentally those have
> been a disaster to millions all over the world.
> What Lisp has to do with them is beyond me as Lisp is
> the most advanced programming language which implies
> limitless creativity, whereas the iThings are very
> dangerous toys that have already enslaved millions of
> supposedly "adults" as well. Whenever I encounter old
> people I see this very clearly - the difference in
> posture, knowledge, skill, literacy, awareness,
> self-confidence - it is just huge. Of course, there
> were no iThings in their youths and adult lives so
> they hade to take part in real activity, solve real
> problems, communicate with real people, develop real
> skills, and so on - every day. The people today who
> never did any of that - well, it shows!

You are very ill-informed, you don't know what Alan Kay thinks of iPads and
iPhones.  I can't find the exact quote, so I can only advise you to
watch all these videos:
https://www.youtube.com/playlist?list=PLKuVC3Lrr0b8k5UY402FfM2LuZ8Ecti96

-- 
__Pascal Bourguignon__                 http://www.informatimago.com/
“The factory of the future will have only two employees, a man and a
dog. The man will be there to feed the dog. The dog will be there to
keep the man from touching the equipment.” -- Carl Bass CEO Autodesk

Re: member returns list

[Emanuel Berg]

"Pascal J. Bourguignon" <pjb@informatimago.com>
writes:

> You are very ill-informed, you don't know what Alan
> Kay thinks of iPads and iPhones. I can't find the
> exact quote

I just Googled

    Alan Kay iPad iPhone

and found a link [1] with the title

    Computing pioneer Alan Kay calls Apple's iPad user
    interface 'poor'

I'm not surprised he thinks so. That is what I meant
he would grab for the revolver himself if I showed him
in 1969 what his work with Smalltalk eventually
brought to humanity.

You might have seen the second Terminator movie in
which a android is sent back in time to kill the
engineer who did "Skynet", which eventually
enslaved humanity.

But this is in line with your kind of thinking.
Tho they killed the guy in that movie, that didn't
change anything - just as killing Kay in 1969 wouldn't
turn the iThings slaves of today into techno-warriors.

[The reason I don't like those products isn't the
interface in particular, tho that is one reason
I don't use them. With a computer-like interface,
i.e. a shell and a keyboard, they could be used for
good. But most people still wouldn't.]

[1] http://appleinsider.com/articles/13/04/03/computing-pioneer-alan-kay-calls-apples-ipad-user-interface-poor

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: member returns list

[Pascal J. Bourguignon]

Emanuel Berg <embe8573@student.uu.se> writes:

> "Pascal J. Bourguignon" <pjb@informatimago.com>
> writes:
>
>> No Smalltalk -> no lisa -> no Macintosh -> no
>> MS-Windows and no NeXTSTEP (Apple would be dead by
>> now) -> MacOSX -> no iPad/iPhone.
>>
>> No Java -> no Android.
>>
>> Imagine if the bitmap displays were only used on
>> high end workstations for scientific data
>> representation, and in low-end PC for games.
>>
>> Most PC would still work with text screens.
>
> Did Smalltalk have any positive consequences as well?

And:

No NeXTSTEP -> no HTTP/www -> no facebook, no tweeter, no google, no
nothing!


-- 
__Pascal Bourguignon__                 http://www.informatimago.com/
“The factory of the future will have only two employees, a man and a
dog. The man will be there to feed the dog. The dog will be there to
keep the man from touching the equipment.” -- Carl Bass CEO Autodesk

Re: member returns list

[Emanuel Berg]

"Pascal J. Bourguignon" <pjb@informatimago.com>
writes:

> No NeXTSTEP -> no HTTP/www -> no facebook, no
> tweeter, no google, no nothing!

OK, HTTP/www and Google we do want. (Only half a point
for Google.)

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: member returns list

[Eli Zaretskii]

> From: "Pascal J. Bourguignon" <pjb@informatimago.com>
> Date: Sat, 12 Sep 2015 01:29:43 +0200
> 
> Imagine if the bitmap displays were only used on high end workstations
> for scientific data representation, and in low-end PC for games.
> 
> Most PC would still work with text screens.

Which would be a Good Thing, IMO, since what we have now is beyond
ridiculous: 99.99% of our CPU power is engaged in moving pixels on the
screen from here to there.  That's why we have generations of
programmers who are blissfully unaware of the tremendous power of the
current CPUs: all they have before their eyes is how long it takes MS
Word to redraw its screen.  On my daytime job I bump into those guys
every day: they are unable to imagine how much processing could be
done in 1 sec, and therefore vastly underestimate the performance of
data processing software they need to design and implement.  Ask them
how did people fly to the Moon with a 1 MIPS CPU, and they will tell
you it's impossible.

Re: member returns list

[Pascal J. Bourguignon]

Emanuel Berg <embe8573@student.uu.se> writes:

> "Pascal J. Bourguignon" <pjb@informatimago.com>
> writes:
>
>>> Why don't you do a Lisp OS with Lisp-only software?
>>
>> Time. Money.
>
> OK, what I meant was actually again why Lisp is so
> marginalized. Not only in "industry" (yuk, that is
> a stupid word) but also in the systems we use every
> day. Every program I ever use is written in C (except
> for Emacs which is C and Lisp). 

It's up to you to choose programs written in lisp instead.

For example, instead of GNU emacs you could use Hemlock (notably in
Clozure CL.app on MacOSX, it's nicely integrated).  Of course, it
doesn't benefit of all the GNU emacs third-party packages, but you have
an emacs with the same basic editing features, all written in Common
Lisp from the bottom up (well, apart from a small kernel in ccl written
in C, and from UI stuff in Hemlock written in CL but calling out to
the Objective-C cocoa framework).


> Do you think the association between C and Unix, strong as it may, is
> enough to explain this? 

Historically, definitively.

But for a long time now, availability of implementations and computing
power and memory size of unix machines has not justified the use of C
(or C++) at all for applications.  And people also realize that when
they created the P languages, perl, php, python and rupy^W ruby.

I would use C only to write a device driver.

> The only big program which I use that I can think of which is
> Lisp-only is Gnus which is a part of Emacs.

> But: Keeping the Linux kernel (which is in C) and then
> starting to replace the typical components in a Unix
> or Linux system (which are all in C) with ditto in
> Lisp, I don't see the purpose of that. 

This is however the approach taken by Android, and they obtain a system
that is quite different from a unix system.  The only thing unix in
Android, is the use of the linux kernel for the drivers, and for the
implementation of sandboxes.

Android "user accounts" whatever that means, are not unix account (unix
account on Android actually correspond more to Android applications,
than to human users).


> What would be interesting is a system that is Lispic, not just another
> Unix only written in Lisp, which would be stupid at best.

I already mentionned Mezzano.  If you want to write your own, you can
use Movitz CL, or of course, build on Mezzano.

> Do you have hyperlinks to a bootable DVD or USB?

No, it's no batteries included.  You get the sources from the github and
do it yourself.

https://github.com/froggey/Mezzano
https://common-lisp.net/project/movitz/
https://github.com/PuercoPop/Movitz

-- 
__Pascal Bourguignon__                 http://www.informatimago.com/
“The factory of the future will have only two employees, a man and a
dog. The man will be there to feed the dog. The dog will be there to
keep the man from touching the equipment.” -- Carl Bass CEO Autodesk

Re: member returns list

[Emanuel Berg]

"Pascal J. Bourguignon" <pjb@informatimago.com>
writes:

> But for a long time now, availability of
> implementations and computing power and memory size
> of unix machines has not justified the use of C (or
> C++) at all for applications. And people also
> realize that when they created the P languages,
> perl, php, python ...

I don't like Python (the forced indentation, for
example), "Personal Home Page" (PHP) is a toy for
kids, Perl is sort of cool but I prefer C except for
web programming which I never did much. Perl is also
very much shelly Unix with awk and sed-ish syntax and
attitude, so compared to the "Unix C", Perl is
Unix 2.0 or whatever.)

> No, it's no batteries included. You get the sources
> from the github and do it yourself.
>
> https://github.com/froggey/Mezzano
> https://common-lisp.net/project/movitz/
> https://github.com/PuercoPop/Movitz

They should put it in the Debian repos because it is
a quality stamp and also a practical way to distribute
and retrieve it.

-- 
underground experts united
http://user.it.uu.se/~embe8573

RE: member returns list

[Drew Adams]

> Basically, you can implement a lisp without having access
> to an old lisp system, just by hearing about it and having
> a little light bulb going tilt in your head.

Hear, hear!

RE: member returns list

[Drew Adams]

> But basically, he started GNU emacs and designing emacs lisp slightly
> beforem the CL standardization process started, and it was far from
> obviouos that it would succeed (it took ten years!).

Hm...  Dunno when you want to say that RMS "started" designing
Emacs Lisp.  But I think I disagree with what I think you are
saying about when "the CL standardization process started".

The first public release of GNU Emacs was in 1985.  Common
Lisp was designed over a period of years prior to that, and RMS
was at least somewhat involved with that design process (he was
well aware of it, to say the least).

Common Lisp was defined by 1984.  The book that specified its
definition, Common Lisp the Language, was published in 1984
(I'm looking at my 1984 copy now), and it is quite clear from
that book that the language design that it presents (specifies,
in detail) was agreed upon by all of the design participants.
It is a thoroughgoing specification of the language, and as
such it was used as the guide when implementing CL here and
there.

Was that a "standard".  I would say so.  It was a full
definition, and it thus allowed people to go out and develop
implementations.  Whether it was a "standard" blessed by this
or that standards body is a moot point, IMO.

And there were already working implementations of Common Lisp
in 1984.  It was being used by programmers in various labs in
1984.  And new Common Lisp implementations were fast underway
in 1984 (e.g. for new Lisp machines).

I was using Kyoto Common Lisp in 1984, for instance.  It was not
a great implementation at that point, but it was usable.  It was
developed just on the basis of studying the spec (CLtL).
https://en.wikipedia.org/wiki/Kyoto_Common_Lisp

Not only was Common Lisp defined by 1984, it was even already
criticized  in a paper in the 1984 Symposium on Lisp and
Functional Programming, "Critique of Common Lisp".

See The Evolution of Lisp, http://www.dreamsongs.com/Files/Hopl2.pdf

From another recent thread here ("print out all members of a list"):

>>>> How is that possible, since Emacs Lisp came out AFTER Scheme and Common 
>>>> Lisp?  CLtL was published in 1984, the same year Stallman started 
>>>> writing GNU Emacs?  And Scheme is older, since CL took a number of ideas 
>>>> from it (most notably lexical scoping).
>>> 
>>> At the same time as CL.  
>>> The CL standard was completed in 1994.   1984 only marks the beginning
>>> of the standardization effort.

I disagree with that characterization.  The fact that Common Lisp
continued to be refined as a standard, and the fact that CLOS and
ANSI Common Lisp came later, does not mean that CL had not already
been defined by 1984.

> For example, Franz, Inc. switched over to CL only after 1985
> and had CL available only in 1986.

Franz Lisp was widely distributed and mature, while CL had few
implementations at that point.  Eventually Franz Inc. was formed
and it produced its own implementation of Common Lisp.

But the fact that Franz Inc. did not have a CL in 1984 does not
mean that CL had not been designed by then, let alone that it
was not defined until 1994!  Other CL implementations existed
in 1984, and still others were in the process of development.

This development was all happening (rapidly) because CL had
already been designed, as a standard.  The mere fact that
Franz Inc. could and would set out to implement its own CL
after 1984 underlines the fact that CL had already been
defined by then.

> http://franz.com/about/company.history.lhtml
> http://emacswiki.org/emacs/EmacsHistory

Re: member returns list

[Barry Margolin]

In article <mailman.502.1441349470.19560.help-gnu-emacs@gnu.org>,
 Marcin Borkowski <mbork@mbork.pl> wrote:

> On 2015-09-04, at 03:03, Emanuel Berg <embe8573@student.uu.se> wrote:
> 
> > Marcin Borkowski <mbork@mbork.pl> writes:
> >
> >> memq
> >
> > Hot!
> >
> > Love Emacs and Lisp inconsistency!
> 
> assq
> delq
> memq
> rassq
> remq
> 
> ...inconsistency?

FYI, all those names were inherited from Maclisp. The q at the end of 
the names reflects that they use eq as the comparison function.

Conversely, the functions that use equal have long names like delete, 
member, remove. The consistency is that the fully-spelled-out list 
functions use the fully-spelled-out comparison.

-- 
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

Re: member returns list

[Emanuel Berg]

Barry Margolin <barmar@alum.mit.edu> writes:

> FYI, all those names were inherited from Maclisp.
> The q at the end of the names reflects that they use
> eq as the comparison function.

Ha ha, cool!

> Conversely, the functions that use equal have long
> names like delete, member, remove. The consistency
> is that the fully-spelled-out list functions use the
> fully-spelled-out comparison.

What?! :O

Or did you make that up just now?

If not, do you have more such Lisp secrets to share?

-- 
underground experts united
http://user.it.uu.se/~embe8573

member (was: Re: To `boundp' or not to `boundp'?)

[Emanuel Berg]

Barry Margolin <barmar@alum.mit.edu> writes:

> It's no more misleading than MEMBER, which
> intuitively seems like it would just return
> a boolean, but actually returns the tail of the list
> where the element was found.

I guess one can do something like this. But probably
it will only lead to even more confusion.

    (defun memberp (e l)
      (when (member e l) t) )

    (memberp 1 '(1 2 3 4)) ; t
    (memberp 0 '(1 2 3 4)) ; nil

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: member returns list (was: Re: To `boundp' or not to `boundp'?)

[Barry Margolin]

In article <mailman.363.1441150201.19560.help-gnu-emacs@gnu.org>,
 Emanuel Berg <embe8573@student.uu.se> wrote:

> Barry Margolin <barmar@alum.mit.edu> writes:
> 
> > ... MEMBER, which intuitively seems like it would
> > just return a boolean, but actually returns the tail
> > of the list where the element was found.
> 
> Yes, and I have wondered about that. Is it useful,
> perhaps with the use of `car' (?) as in:
> 
>     (car (member 2 '(1 2 3))) ; 2
>     (car (member 0 '(1 2 3))) ; nil
> 
> Or is it some "leftover optimization" thing where
> `cdr' is faster than returning `t', and can be used
> the same way?
> 
> Or is it something else?

It could be useful for something like

(length (member item list))

Or it could be used in a loop, where you repeat the operation with the 
list that it returned.

-- 
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

Re: member returns list (was: Re: To `boundp' or not to `boundp'?)

[Emanuel Berg]

Barry Margolin <barmar@alum.mit.edu> writes:

> It could be useful for something like
>
> (length (member item list))
>
> Or it could be used in a loop, where you repeat the
> operation with the list that it returned.

Yes, I understand it can be used in many situations.
The sky is the limit. What I thought, I thought it was
either an "inverted optimization" (i.e., the
optimization is not to make it intuitive but leave it
as it is which is faster and works the same) *or* if
there was one (1), or but a few cases where it is very
useful, simple combinations like the 1-2 of boxing or
one-timer in ice hockey, that would be interesting
to see.

We can compare it to something else and you will
understand immediately what I mean: `or' is
intuitively a boolean, but in practice it is a boolean
AND the item which was first found to be true,
returned. I.e., it is just like `member' in that
sense. However, with `or' if anyone asked the question
I asked about `member', I would answer without
blinking, because then you can do

    (or title "The boring standard title that should never appear")

The examples provided hasn't been as straightforward
as that, at least not to me, but it is OK. They don't
have to be.

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: member returns list (was: Re: To `boundp' or not to `boundp'?)

[Barry Margolin]

In article <mailman.426.1441229773.19560.help-gnu-emacs@gnu.org>,
 Emanuel Berg <embe8573@student.uu.se> wrote:

> Barry Margolin <barmar@alum.mit.edu> writes:
> 
> > It could be useful for something like
> >
> > (length (member item list))
> >
> > Or it could be used in a loop, where you repeat the
> > operation with the list that it returned.
> 
> Yes, I understand it can be used in many situations.
> The sky is the limit. What I thought, I thought it was
> either an "inverted optimization" (i.e., the
> optimization is not to make it intuitive but leave it
> as it is which is faster and works the same) *or* if
> there was one (1), or but a few cases where it is very
> useful, simple combinations like the 1-2 of boxing or
> one-timer in ice hockey, that would be interesting
> to see.
> 
> We can compare it to something else and you will
> understand immediately what I mean: `or' is
> intuitively a boolean, but in practice it is a boolean
> AND the item which was first found to be true,
> returned. I.e., it is just like `member' in that
> sense. However, with `or' if anyone asked the question
> I asked about `member', I would answer without
> blinking, because then you can do
> 
>     (or title "The boring standard title that should never appear")
> 
> The examples provided hasn't been as straightforward
> as that, at least not to me, but it is OK. They don't
> have to be.

The basic idea of all these things is that if a function can easily 
return something more detailed and potentially useful than just 
true/false, it might as well do so. There's no downside, and potential 
upside.

-- 
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

Re: member returns list (was: Re: To `boundp' or not to `boundp'?)

[Emanuel Berg]

Barry Margolin <barmar@alum.mit.edu> writes:

> The basic idea of all these things is that if
> a function can easily return something more detailed
> and potentially useful than just true/false, it
> might as well do so. There's no downside, and
> potential upside.

I agree, the question was rather what the "potential
upside" has been in practice. Usually when you can do
one hundred things with something it boils down to two
or three things or combinations that are actually
used, even by the masters.

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: member

[Pascal J. Bourguignon]

Emanuel Berg <embe8573@student.uu.se> writes:

> Barry Margolin <barmar@alum.mit.edu> writes:
>
>> It's no more misleading than MEMBER, which
>> intuitively seems like it would just return
>> a boolean, but actually returns the tail of the list
>> where the element was found.
>
> I guess one can do something like this. But probably
> it will only lead to even more confusion.
>
>     (defun memberp (e l)
>       (when (member e l) t) )
>
>     (memberp 1 '(1 2 3 4)) ; t
>     (memberp 0 '(1 2 3 4)) ; nil

If you just want a more concise result, you can use position or find
instead of member.  As predicates, they're equivalent.

-- 
__Pascal Bourguignon__                 http://www.informatimago.com/
“The factory of the future will have only two employees, a man and a
dog. The man will be there to feed the dog. The dog will be there to
keep the man from touching the equipment.” -- Carl Bass CEO Autodesk

Re: member

[Emanuel Berg]

"Pascal J. Bourguignon" <pjb@informatimago.com>
writes:

> If you just want a more concise result

I'm fine using `member' as a "false predicate", and
I don't think it is bad or that it should be changed.

> you can use position or find instead of member.
> As predicates, they're equivalent.

`find' seems to be the same and thus better than `car'
+ member. `position' is good when what should be
determined is the... position of the item.

    (find 2 '(1 2 3 4))       ; 2
    (find 6 '(1 2 3 4 5))     ; nil
    (position 1 '(1 2 3 4))   ; 0 (zero-indexed; N.B. (when 0 t) ; t)
    (position 6 '(1 2 3 4 5)) ; nil

-- 
underground experts united
http://user.it.uu.se/~embe8573

RE: To `boundp' or not to `boundp'?

[Drew Adams]

> > > > I often see code like this
> > > > (when (and (boundp 'xxx-mode) xxx-mode) ...)
> > >
> > > The "proper" way to do that is to use bound-and-true-p.
> >
> > That certainly is *not* proper for the more general case
> > (and (boundp 'xxx)  xxx), where the value of `xxx' is
> > not necessarily Boolean or is not used only as a Boolean.
> >
> > Well, it works the same, but the _name misleads_ terribly
> > in this case, even if the doc does let you know that the
> > variable value (not t or nil) is returned, when bound.
> 
> The name isn't misleading if you use it in a boolean context,
> like the WHEN call in the OP.

Correct.  It is not misleading in that case.  Which is why
I qualified the statement with "where the value of `xxx' is
_not_ necessarily Boolean or is _not_ used only as a Boolean."

It does not mislead in all cases, no.  But it does in some.
It is misleading in general because what it suggests is not
what is meant in some (common) cases.  Not a great name.

FWIW, if someone proposed `member-p' instead of `member'
I would have the same remark.  The former emphasizes the
Boolean/predicate nature; the latter does not.  A fortiori,
if someone were to propose `member-and-true-p' - no thanks.

It's not a big deal, certainly.  But neither is it needed.
(and (boundp 'VAR) VAR) is succinct enough and clear enough,
IMHO, and it has the advantage of _never_ misleading.

Re: To `boundp' or not to `boundp'?

[Stefan Monnier]

> (when (and (boundp 'xxx-mode) xxx-mode)
>   ...)
> I personally prefer to do it shorter
> (when (ignore-errors xxx-mode)
>   ...)
> Are those equivalent?

Kinda.  I think ignore-errors has a higher cost than boundp+and, but the
more important difference is that ignore-errors will hide all kinds of
other errors, so its use generally makes debugging your code harder.
For that reason I generally prefer to avoid it.


        Stefan

Re: To `boundp' or not to `boundp'?

[Alexander Shukaev]

I also see

> Note that if `lexical-binding' is in effect, this refers to the
> global value outside of any lexical scope.

in the documentation of `boundp'.  Isn't it a big difference?

Re: To `boundp' or not to `boundp'?

[Michael Heerdegen]

Alexander Shukaev <haroogan@gmail.com> writes:

> I also see
>
> > Note that if `lexical-binding' is in effect, this refers to the
> > global value outside of any lexical scope.
>
> in the documentation of `boundp'.  Isn't it a big difference?

That's a difference.  But testing lexical variables for whether they are
bound is a rare use case (is it one at all?).  I mean, when you are
interested in the binding of a variable that might not be bound
(defined), that variable will typically be special, or not bound at all,
i.e., not lexically bound in any case.


Michael.

Re: To `boundp' or not to `boundp'?

[Barry Margolin]

In article <mailman.410.1441212753.19560.help-gnu-emacs@gnu.org>,
 Michael Heerdegen <michael_heerdegen@web.de> wrote:

> Alexander Shukaev <haroogan@gmail.com> writes:
> 
> > I also see
> >
> > > Note that if `lexical-binding' is in effect, this refers to the
> > > global value outside of any lexical scope.
> >
> > in the documentation of `boundp'.  Isn't it a big difference?
> 
> That's a difference.  But testing lexical variables for whether they are
> bound is a rare use case (is it one at all?).  I mean, when you are
> interested in the binding of a variable that might not be bound
> (defined), that variable will typically be special, or not bound at all,
> i.e., not lexically bound in any case.

In Common Lisp it's not even possible for a lexically-bound variable to 
be unbound. I'm not sure whether Emacs Lisp has a way to do it or not.

-- 
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

Re: member returns list

[Barry Margolin]

In article <mailman.719.1441763081.19560.help-gnu-emacs@gnu.org>,
 Robert Thorpe <rt@robertthorpeconsulting.com> wrote:

> "Pascal J. Bourguignon" <pjb@informatimago.com> writes:
> 
> > "Pascal J. Bourguignon" <pjb@informatimago.com> writes:
> >
> >> Emanuel Berg <embe8573@student.uu.se> writes:
> >>
> >>> "Pascal J. Bourguignon" <pjb@informatimago.com>
> >>> writes:
> >>>
> >>>> Because each implementation worked on a different
> >>>> machine with a different OS (if an OS was available
> >>>> at all).
> >>>
> >>> Yeah, but there were many machines at the time of the
> >>> "crazy language" C as well, still, there aren't
> >>> a plethora of C dialects. (If you don't count all the
> >>> epigone languages that borrowed heavily the syntax
> >>> of C.)
> >>>
> >>> But C is famous for its portability (which also
> >>> proliferated Unix) - perhaps the exception that
> >>> confirms the rule, that Lisp is cooler than C?
> >>
> >> It's not exactly the same time period, and not the same kind of
> >> machines.
> >>
> >> Basically, C was running on small machines, that were all the same.
> >> After C the micro-processors appeared, and since they were so bad, they
> >> soon were optimized to run C code efficiently.
> 
> I don't really agree with Pascal's view.
> 
> Anyway, there were some other reasons why Lisp implementations differed
> between machines.  As Pascal said, the early Lisp implementations were
> on mainframes.  Later on people tried to port Lisp to minicomputers and
> microcomputers.  But, Lisp was already quite complex and it wasn't
> possible to fit all the features.  So, some of the features got
> excluded, and which were excluded varied.

This doesn't explain why there were such drastic differences between the 
mainframe Lisps.

Remember that in the 70's, when much of the Lisp evolution was 
happening, we didn't have the Internet (Arpanet was still in its early 
days, but there was no WWW yet). The folks at the Stanford, CMU, and MIT 
AI Laboratories couldn't easily collaborate on a daily basis like they 
can now. So each group developed their own Lisp dialects, based on the 
preferences of their developers.

It's not really much different from why we now have a profusion of 
languages for writing web server-side applications: Perl, PHP, Python, 
Ruby. Different people have different style preferences.

-- 
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

Re: member returns list

[Ted Zlatanov]

On Wed, 09 Sep 2015 11:03:24 -0400 Barry Margolin <barmar@alum.mit.edu> wrote: 

BM> It's not really much different from why we now have a profusion of 
BM> languages for writing web server-side applications: Perl, PHP, Python, 
BM> Ruby. Different people have different style preferences.

(or lack thereof)

Ted