Hatena::Groupcadr

わだばLisperになる このページをアンテナに追加 RSSフィード

2004 | 12 |
2005 | 01 | 02 | 07 | 10 | 11 |
2006 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2007 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2008 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2009 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2010 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2011 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 11 |

2009-12-12

CL365始めました

| 22:08 | CL365始めました - わだばLisperになる を含むブックマーク はてなブックマーク - CL365始めました - わだばLisperになる

Ruby Advent Calendar jpが羨しかったので、CL365という年中CLネタを書くというイベントを作りました。

Advent Calendarのように役立つTipsでなくてもOKですので興味のある方は是非参加してみてください!

このRSSを購読すれば毎日CLの記事が読める!これで勝つる!というのを目指しています。

ちなみに、1日1つでなくても他の人と被ってもOKな方針です。

IFのインデント

| 22:10 | IFのインデント - わだばLisperになる を含むブックマーク はてなブックマーク - IFのインデント - わだばLisperになる

REMOVE-FROM-TREE-IFのコードでIFのインデントが読み辛い…と書いていて、IFのインデントに関しての古のLispハッカー達がMLで議論していたのを思い出したので掲載してみます。(CADR System 99の>doc>if.answerより)

Lispマシン初期では、今のEmacs Lispのようにthen節とelse節のインデントが違っていたらしいのですが、いつの間にやら揃える派の人がLispマシンに変更を加えてしまい、それを元に戻したRMS(ずらす派)と揃える派のやりとりです。

Date: 16 February 1982 01:57-EST
From: Richard M. Stallman <RMS at MIT-AI>
To: BUG-LISPM at MIT-AI

Does anyone object to indenting the else-clauses in IF two spaces
less than the then-clause?

This was flushed, but nobody admitted to flushing it, and the only
response I got before was a favorable one.  Unless opinion is clearly
against it, I will reinstall it.
Date: Tuesday, 16 February 1982  16:03-EST
From: DLW at SCRC-TENEX

Yes, I object to the special indentation for IF.  Also, if you look at
various init files you can find other people who, like me, remove
the special indentation.  Moon does.  Daniel Weise does, and he told
me that most of the people that he works with do too.

I don't know who changed the default; I didn't even know that it had
been changed (since my environment is customized anyway).
LEVITT@MIT-AI 02/16/82 15:58:53 Re:  IF indentation syntax
To: RMS at MIT-AI

I recommended &BODY style indentation to BUG-LISPM for IF over a year
ago.  I strongly prefer it.  At the time, DLW pointed out that for
"parallel constructions", with just a pair of forms, the other way
makes more sense, but still I find that harder to read.  His was the
only response I got at the time, and of course it was never
implemented until you did it (I had little doubt) a while ago.

From whom did you obtain your consensus on IF indentation aesthetics?
Since I imagine many of us will want to use Symbolics bands in the
future, won't it be a big hassle for you to re-install things like
this every time they release a new band?  Maybe you start putting a
bunch of "patches" that users have said they like, but Symbolics
doesn't care to support, into LMLIB;, and announce them.  Isn't that
the current convention?
dcb@MIT-AI 02/16/82 09:39:27
To: RMS at MIT-AI

By all means PLEASE re-install it.
	dan
Date: 16 February 1982 09:25-EST
From: Gerald R. Barber <JerryB at MIT-AI>
To: RMS at MIT-AI

No.  I prefer that else clauses are indented differently that the then
clause, it helps distinquish the two.
Date: 16 February 1982 04:47-EST
From: George J. Carrette <GJC at MIT-MC>

Yes, I object. I never use more that one else clause, so I think it
looks silly to have (IF (FOO X) (BAR X) (BAZ X))  indent as
(IF (FOO X)
    (BAR X)
  (BAZ X))

It is pretty to have parens line-up as much as possible. Certainly
with C-M-F and C-M-B it is never a readability problem.
RWG@MIT-MC 02/16/82 05:06:10 Re: Indenting IF

I used to prefer maximally aligned parens, but given the evolution of
Lisp syntax, I now lean toward the higher information content possible
with less rigid indenting.  In the case of IF with one ELSE clause, I
initially bletched when I saw RMS's contour, then decided it was in
fact mnemonic:  the outcome consonant with the predicate indented
consonantly, and mutatis mutandis for the ELSE.
Date: 16 February 1982 03:13-EST
From: Alan Bawden <ALAN at MIT-MC>

I didn't flush it, but three cheers for whoever did!  I detest having my IF's
indent that way.  The only time I ever mentiond this in public I got a whole
room full of people jumping up and down hating it right along with me.  (I
recall DLW and DANIEL to be amoung them.)  Moon tells me that he also dislikes
it.
Date: Wednesday, 17 February 1982, 00:39-EST
From: David A. Moon <Moon at SCRC-TENEX>
Subject: IF indentation

I answered your previous query.  I don't like the different indentation
for the else clauses; however it's not quite that simple.  When I use
symmetrical IFs, which I nearly always use, I greatly prefer having the
THEN and the ELSE indented the same way.  When I use multiple-else-clause
IF, I indent it the new way you (I assume) thought of.  However, after
much consideration and experimentation I decided that I liked it better
for the automatic indenter to do it the old way, and I would type
control-Tab myself if I wanted it the new way.  Consequently I put something
in my init file to turn off the new mode.

Most people I happened to ask about this preferred it the old way, however
if you reinstall it I will continue to make my init file turn it off.
Date: 16 February 1982 21:55-EST
From: Andrew L. Ressler <ALR at MIT-ML>
Subject: IF Indentation

I like it.  If people want to turn it off in their inits I could
care less but I like it to be the default.
Andrew
GSB@MIT-ML 02/16/82 20:10:14 Re: IF clause indenting

I've developed the habit of using IF in the simple cases where
the "then" and "else" clauses are equivalent, and i just about
never use multiple "else" clauses, so have always preferred
having them indent equivalently.  Of course, not using multiple
"else" clauses is partly a response to having it not supported
everywhere (once-upon-a-time?).  Indentation is something i can
always customize if i really want anyway, so i don't really
care that much.
EB@MIT-AI 02/17/82 17:48:53

I vote to keep the special IF indentation, though at first I thought
it was ugly.
BAK@MIT-AI 02/18/82 17:06:21

I am DEFINITELY against it.  I don't see the point of having the the
and else clauses go to different places.

KMRCLを眺める (37) REMOVE-FROM-TREE-IF

| 21:13 | KMRCLを眺める (37) REMOVE-FROM-TREE-IF - わだばLisperになる を含むブックマーク はてなブックマーク - KMRCLを眺める (37) REMOVE-FROM-TREE-IF - わだばLisperになる

今回は、KMRCLのlists.lisp中からREMOVE-FROM-TREE-IFです。

定義は

(defun remove-from-tree-if (pred tree &optional atom-processor)
  "Strip from tree of atoms that satistify predicate"
  (if (atom tree)
      (unless (funcall pred tree)
        (if atom-processor
            (funcall atom-processor tree)
          tree))
    (let ((car-strip (remove-from-tree-if pred (car tree) atom-processor))
          (cdr-strip (remove-from-tree-if pred (cdr tree) atom-processor)))
      (cond
       ((and car-strip (atom (cadr tree)) (null cdr-strip))
        (list car-strip))
       ((and car-strip cdr-strip)
        (cons car-strip cdr-strip))
       (car-strip
        car-strip)
       (cdr-strip
        cdr-strip)))))

動作は、名前からすると、REMOVE-IFのtree版というところですが、

(DEFVAR *TREE* '(1 A 2 B 3 C 4 D () () (5 E 6 F 7 G (8 9 10) 11 12) 13))

(REMOVE-FROM-TREE-IF #'VALUES *TREE*)
;⇒ NIL

(REMOVE-FROM-TREE-IF #'NULL *TREE*)
;=> (1 A 2 B 3 C 4 D (5 E 6 F 7 G (8 9 10) 11 12) 13)

(REMOVE-FROM-TREE-IF (LAMBDA (X)
                       (IF (SYMBOLP X)
                           X
                           (EVENP X)))
                     *TREE*)
;⇒ (1 3 (5 7 (9) 11) 13)

(REMOVE-FROM-TREE-IF #'SYMBOLP
                     *TREE*
                     (LAMBDA (N) (AND (ODDP N) N)))
;⇒ (1 3 (5 7 (9) 11) 13)

(REMOVE-FROM-TREE-IF #'NUMBERP *TREE*)
;⇒ (A B C D (E F . G))

なんだかちょっと素直じゃないような気も。

再帰する部分が何度も出てくるので、LETの束縛部分に書いてありますが、自分も好きで長くなくても良くこう書きます。

それと、瑣末なところですが、REMOVE-FROM-TREE-IFの定義に使われているIFのインデント方式は読み辛いです…

KMRCLを眺める (36) APPENDNEW

| 14:58 | KMRCLを眺める (36) APPENDNEW - わだばLisperになる を含むブックマーク はてなブックマーク - KMRCLを眺める (36) APPENDNEW - わだばLisperになる

今回は、KMRCLのlists.lisp中からAPPENDNEWです。

定義は

(defun appendnew (l1 l2)
  "Append two lists, filtering out elem from second list that are already in first list"
  (dolist (elem l2 l1)
    (unless (find elem l1)
      (setq l1 (append l1 (list elem))))))

となっています。

L1に含まれていない要素だけ末尾に足してゆくのが分かります。

使用例/動作例は、

(APPENDNEW (LIST 'A 'B 'C 'D)
           (LIST 1 'A 2 'B 3 'C 4 'D))
;⇒ (A B C D 1 2 3 4)

という感じでしょうか。

CLの標準でもこういうのが用意されているような気がしたので、探してみましたが、PUSHNEWとも違うし、UNIONとも違うしで、ありそうで無い関数のようです。