Consider finding the winner of a race
(defun winner (list-of-runners-and-their-times)
(reduce (lambda (x y)
(if (< (race-time x)
(race-time y))
x
y))
list-of-runners-and-their-times))
(defun race-time ( |(runner time)| )
(second |(runner time)| ))
(winner '((bill 204)(fred 201)(joe 203))) => (FRED 201)
Is the variable name `(runner time)'
1) a good use of a multiple escape to write self documenting code
2) a bad use of a multiple escape to write obfuscated code
3) The function should be written with defstruct :
(defstruct (race (:type list))
runner
time)
Consider trying to lift the concept of inequality from
operating on a pair of numbers to operating on two lists of
numbers with the left most number being decisive.
(defun compare (x y)
(cond ((and (endp x)
(endp y)) 'equal)
((endp x) 'less)
((endp y) 'more)
((< (car x)
(car y)) 'less)
((> (car x)
(car y)) 'more)
('equal-heads (compare (cdr x)
(cdr y)))))
It is banal enough, but the cond form drags on a bit. Is it better to use
typecase to give if a bit more structure?
(defun compare (x y)
(typecase x
(null (typecase y
(null 'equal)
(cons 'less)))
(cons (typecase y
(null 'more)
(cons (let ((a (car x))
(b (car y)))
(cond ((< a b) 'less)
((= a b) (compare (cdr x)(cdr y)))
('(> a b) 'more))))))))
Let us push a bit further with
(deftype zero () '(real 0 0))
(deftype positive () '(real (0) *))
(deftype negative () '(real * (0)))
(defun compare (x y)
(typecase x
(null (typecase y
(null 'equal)
(cons 'less)))
(cons (typecase y
(null 'more)
(cons (typecase (- (car x) (car y))
(positive 'more)
(negative 'less)
(zero (compare (cdr x)(cdr y)))))))))
Is this
1) Cool!
2) A typecase too far
3) Four typecases too far
Oh and what about '(> a b) in the final cond; was that st[ylish|upid]?
Alan Crowe
Edinburgh
Scotland
In article <··············@cawtech.freeserve.co.uk>,
Alan Crowe <····@cawtech.freeserve.co.uk> wrote:
> Consider finding the winner of a race
>
> (defun winner (list-of-runners-and-their-times)
> (reduce (lambda (x y)
> (if (< (race-time x)
> (race-time y))
> x
> y))
> list-of-runners-and-their-times))
>
> (defun race-time ( |(runner time)| )
> (second |(runner time)| ))
>
> (winner '((bill 204)(fred 201)(joe 203))) => (FRED 201)
>
> Is the variable name `(runner time)'
>
> 1) a good use of a multiple escape to write self documenting code
>
> 2) a bad use of a multiple escape to write obfuscated code
>
> 3) The function should be written with defstruct :
>
> (defstruct (race (:type list))
> runner
> time)
None of the above. It should be:
(defstruct runner name time)
And then if you want:
(defstruct race participants ...)
> Consider trying to lift the concept of inequality from
> operating on a pair of numbers to operating on two lists of
> numbers with the left most number being decisive.
>
> (defun compare (x y)
> (cond ((and (endp x)
> (endp y)) 'equal)
> ((endp x) 'less)
> ((endp y) 'more)
> ((< (car x)
> (car y)) 'less)
> ((> (car x)
> (car y)) 'more)
> ('equal-heads (compare (cdr x)
> (cdr y)))))
>
> It is banal enough, but the cond form drags on a bit. Is it better to use
> typecase to give if a bit more structure?
>
> (defun compare (x y)
> (typecase x
> (null (typecase y
> (null 'equal)
> (cons 'less)))
> (cons (typecase y
> (null 'more)
> (cons (let ((a (car x))
> (b (car y)))
> (cond ((< a b) 'less)
> ((= a b) (compare (cdr x)(cdr y)))
> ('(> a b) 'more))))))))
>
> Let us push a bit further with
>
> (deftype zero () '(real 0 0))
> (deftype positive () '(real (0) *))
> (deftype negative () '(real * (0)))
>
> (defun compare (x y)
> (typecase x
> (null (typecase y
> (null 'equal)
> (cons 'less)))
> (cons (typecase y
> (null 'more)
> (cons (typecase (- (car x) (car y))
> (positive 'more)
> (negative 'less)
> (zero (compare (cdr x)(cdr y)))))))))
>
> Is this
>
> 1) Cool!
>
> 2) A typecase too far
>
> 3) Four typecases too far
Less clear cut, but I vote for #3.
> Oh and what about '(> a b) in the final cond; was that st[ylish|upid]?
I'll go with stylish here. Likewise for 'equal-heads.
rg
Alan Crowe <····@cawtech.freeserve.co.uk> writes:
> Consider finding the winner of a race
>
> (defun winner (list-of-runners-and-their-times)
> (reduce (lambda (x y)
> (if (< (race-time x)
> (race-time y))
> x
> y))
> list-of-runners-and-their-times))
>
> (defun race-time ( |(runner time)| )
> (second |(runner time)| ))
>
> (winner '((bill 204)(fred 201)(joe 203))) => (FRED 201)
>
> Is the variable name `(runner time)'
>
> 1) a good use of a multiple escape to write self documenting code
>
> 2) a bad use of a multiple escape to write obfuscated code
The second. runner-time would be fine.
> 3) The function should be written with defstruct :
>
> (defstruct (race (:type list))
> runner
> time)
Maybe. It depends on how serious an application you are writing.
> Consider trying to lift the concept of inequality from
> operating on a pair of numbers to operating on two lists of
> numbers with the left most number being decisive.
>
> (defun compare (x y)
> (cond ((and (endp x)
> (endp y)) 'equal)
> ((endp x) 'less)
> ((endp y) 'more)
> ((< (car x)
> (car y)) 'less)
> ((> (car x)
> (car y)) 'more)
> ('equal-heads (compare (cdr x)
> (cdr y)))))
>
> It is banal enough, but the cond form drags on a bit. Is it better to use
> typecase to give if a bit more structure?
>
> (defun compare (x y)
> (typecase x
> (null (typecase y
> (null 'equal)
> (cons 'less)))
> (cons (typecase y
> (null 'more)
> (cons (let ((a (car x))
> (b (car y)))
> (cond ((< a b) 'less)
> ((= a b) (compare (cdr x)(cdr y)))
> ('(> a b) 'more))))))))
>
> Let us push a bit further with
>
> (deftype zero () '(real 0 0))
> (deftype positive () '(real (0) *))
> (deftype negative () '(real * (0)))
>
> (defun compare (x y)
> (typecase x
> (null (typecase y
> (null 'equal)
> (cons 'less)))
> (cons (typecase y
> (null 'more)
> (cons (typecase (- (car x) (car y))
> (positive 'more)
> (negative 'less)
> (zero (compare (cdr x)(cdr y)))))))))
>
> Is this
>
> 1) Cool!
>
> 2) A typecase too far
>
> 3) Four typecases too far
Four too many.
> Oh and what about '(> a b) in the final cond; was that st[ylish|upid]?
Nasty.
It is usually better to keep things really simple and obvious.
Alan Crowe <····@cawtech.freeserve.co.uk> writes:
> Oh and what about '(> a b) in the final cond; was that st[ylish|upid]?
It's silly.
Let the compiler optimize the stuff.
--
__Pascal Bourguignon__ http://www.informatimago.com/
The mighty hunter
Returns with gifts of plump birds,
Your foot just squashed one.
Alan Crowe wrote:
> Consider finding the winner of a race
>
> (defun winner (list-of-runners-and-their-times)
> (reduce (lambda (x y)
> (if (< (race-time x)
> (race-time y))
> x
> y))
> list-of-runners-and-their-times))
>
> (defun race-time ( |(runner time)| )
> (second |(runner time)| ))
>
> (winner '((bill 204)(fred 201)(joe 203))) => (FRED 201)
>
> Is the variable name `(runner time)'
>
> 1) a good use of a multiple escape to write self documenting code
>
> 2) a bad use of a multiple escape to write obfuscated code
>
> 3) The function should be written with defstruct :
>
> (defstruct (race (:type list))
> runner
> time)
I'd much prefer either 3 or using destructuring-bind for the self
documenting effect:
(defun race-time (runner-time)
(destructuring-bind (runner time)
time))
BTW, shouldn't the race structure contain multiple runners?
> Consider trying to lift the concept of inequality from
> operating on a pair of numbers to operating on two lists of
> numbers with the left most number being decisive.
>
> (defun compare (x y)
> (cond ((and (endp x)
> (endp y)) 'equal)
> ((endp x) 'less)
> ((endp y) 'more)
> ((< (car x)
> (car y)) 'less)
> ((> (car x)
> (car y)) 'more)
> ('equal-heads (compare (cdr x)
> (cdr y)))))
>
> It is banal enough, but the cond form drags on a bit. Is it better to use
> typecase to give if a bit more structure?
>
> (defun compare (x y)
> (typecase x
> (null (typecase y
> (null 'equal)
> (cons 'less)))
> (cons (typecase y
> (null 'more)
> (cons (let ((a (car x))
> (b (car y)))
> (cond ((< a b) 'less)
> ((= a b) (compare (cdr x)(cdr y)))
> ('(> a b) 'more))))))))
>
> Let us push a bit further with
>
> (deftype zero () '(real 0 0))
> (deftype positive () '(real (0) *))
> (deftype negative () '(real * (0)))
>
> (defun compare (x y)
> (typecase x
> (null (typecase y
> (null 'equal)
> (cons 'less)))
> (cons (typecase y
> (null 'more)
> (cons (typecase (- (car x) (car y))
> (positive 'more)
> (negative 'less)
> (zero (compare (cdr x)(cdr y)))))))))
>
> Is this
>
> 1) Cool!
>
> 2) A typecase too far
>
> 3) Four typecases too far
Can I vote for 3 typecases too far? I'd like a mixture of the two,
using the positive/negative/zero typecase, but only one cond.
> Oh and what about '(> a b) in the final cond; was that st[ylish|upid]?
I'd really rather that be in a comment, as that is what it really is.
-- MJF
M Jared Finder <·····@hpalace.com> writes:
> > 3) The function should be written with defstruct :
> >
> > (defstruct (race (:type list))
> > runner
> > time)
>
> I'd much prefer either 3 or using destructuring-bind for the self
> documenting effect:
>
> (defun race-time (runner-time)
> (destructuring-bind (runner time)
> time))
That is nice, that's the self-documenting effect I was after
> BTW, shouldn't the race structure contain multiple runners?
>
Yes, poor choice of name on my part. `Race' needs to be
called something like `individual-result' for maximum clarity.
> > Let us push a bit further with
> >
> > (deftype zero () '(real 0 0))
> > (deftype positive () '(real (0) *))
> > (deftype negative () '(real * (0)))
> >
> > (defun compare (x y)
> > (typecase x
> > (null (typecase y
> > (null 'equal)
> > (cons 'less)))
> > (cons (typecase y
> > (null 'more)
> > (cons (typecase (- (car x) (car y))
> > (positive 'more)
> > (negative 'less)
> > (zero (compare (cdr x)(cdr y)))))))))
> >
> > Is this
> >
> > 1) Cool!
> >
> > 2) A typecase too far
> >
> > 3) Four typecases too far
>
> Can I vote for 3 typecases too far? I'd like a mixture of the two,
> using the positive/negative/zero typecase, but only one cond.
This is a surprise. I didn't expect anyone to like
positive/negative/zero typecase, with its added deftypes,
yet dislike the other typecases, which seem to me to flow
naturally from the statement in the hyperspec:
The types cons and null form an exhaustive partition of
the type list.
14.2 The Conses Dictionary: System Class LIST
> > Oh and what about '(> a b) in the final cond; was that st[ylish|upid]?
>
> I'd really rather that be in a comment, as that is what it really is.
>
I thought that the alternative was
(cond ((< a b) ...)
((= a b) ...)
(t ...) ; A must be greater than B
but Pascal Bourguignon seemed to be suggesting
(cond ((< a b) ...)
((= a b) ...)
((> a b) ...))
That would worry me, because it is so obvious that (> a b)
will always be true that one starts to wonder what the
programmer was getting at. I would start imagining
(cond ((< a b) ...)
((= a b) ...)
((> a b) ...)
(t nil)) ;remember it is only a parial order
and then worry that I thought it was a total order.
But what then is the appropriate comment? Writing the code,
we realise that the value of (< a b) is guaranteed to be
true. There is no need to actually perform the calculation
(cond ((< a b) ...)
((= a b) ...)
((quote (> a b)) ...))
seems to me say what is needed, with the brevity appropriate
to a minor point, but others find it "nasty" :-(
Alan Crowe
Edinburgh
Scotland
Alan Crowe wrote:
> M Jared Finder <·····@hpalace.com> writes:
>
>
>>(defun compare (x y)
>> (etypecase (cons x y)
>> ((cons null null) '=)
>> ((cons cons null) '>)
>> ((cons null cons) '<)
>> ((cons cons cons) (etypecase (- (first x) (first y))
>> (negative '<)
>> (positive '>)
>> (zero (compare (rest x) (rest y)))))))
>>
>>Though honestly, I'd probably write this using endp and econd. I'd
>>still have only four cases at the top level cond.
>
>
> Wow! I had no idea that you could do that. That is what I
> get for reading CLtL2. The pretty printing section explains
> that you cannot do (cons number t), but need it for pretty
> print dispatch, so it is available there as a special case.
>
> That was 1990 but poking about I find that in March 1991
> X3J13 passed option ADD on a vote of 12-1 making cons a
> specializing compound type specifier.
>
> As the writeup discusses, this has remarkable consequences.
>
> [9]> (deftype list-of-length (n)
> (if (zerop n)
> 'null
> `(cons t (list-of-length ,(- n 1)))))
>
> [10]> (typep '(1 2 3) '(list-of-length 4)) => NIL
> [11]> (typep '(1 2 3) '(list-of-length 3)) => T
> [12]> (typep '(1 2 3) '(list-of-length 2)) => NIL
But the coolest thing is the dialogs you get:
CL-USER> (typep '(((cons) cons) (cons) (cons))
'(cons (cons cons cons) (cons cons (cons))))
T
:)
-- MJF
In article <··············@cawtech.freeserve.co.uk>,
Alan Crowe <····@cawtech.freeserve.co.uk> wrote:
> Consider trying to lift the concept of inequality from
> operating on a pair of numbers to operating on two lists of
> numbers with the left most number being decisive.
>
> (defun compare (x y)
> (cond ((and (endp x)
> (endp y)) 'equal)
> ((endp x) 'less)
> ((endp y) 'more)
> ((< (car x)
> (car y)) 'less)
> ((> (car x)
> (car y)) 'more)
> ('equal-heads (compare (cdr x)
> (cdr y)))))
The most serious style problem with this code (and the rest of your
examples, which I haven't bothered to quote) is the incorrect indenting.
I sure hope this is just an artifact of your posting software, not how
you actually write your code.
Independent of the indenting problems, I've also never seen code that
puts something on the same line *after* the close parens of a multi-line
expression. I'm referring to the lines:
((< (car x)
(car y)) 'less)
((> (car x)
(car y)) 'more)
which most would write as:
((< (car x) (car y)) 'less)
((> (car x) (car y)) 'more)
or:
((< (car x)
(car y))
'less)
((> (car x)
(car y))
'more)
The usual style convention is that when an expression is broken up into
multiple lines, everything is part of that expression until you see
something at the same or lower indentation level. This is because Lisp
programmers don't normally count parentheses, they recognize the
structure from the indentation.
--
Barry Margolin, ······@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
Barry Margolin sneered:
> The most serious style problem with this code (and the
> rest of your examples, which I haven't bothered to quote)
> is the incorrect indenting. I sure hope this is just an
> artifact of your posting software, not how you actually
> write your code.
When I proof read my post (endp y) lined up underneath
(endp x). Replacing spaces with full-stops
......(cond ((and (endp x)
..................(endp y))
When I read my own post from the server (endp y) still lined
up underneath (endp x).
When I read Barry's post, they didn't line up any more. Specifically
......(cond ((and (endp x)
................(endp y))
I think the problem is at my end, with my emacs putting in
tabs. I've set `indent-tabs-mode' to `nil', and retyped
bits of my post. I hope that the code below has (endp x) and
(endp y) exactly aligned, for every-one.
(defun compare(x y)
(cond ((and (endp x)
(endp y))
'equal)
(other-stuff)))
Can some-one who saw the original post mis-aligned please
confirm that I've managed to solve the indentation problem
with my posts.
Alan Crowe
Edinburgh
Scotland
On 08 Oct 2005 11:23:56 +0100, <····@cawtech.freeserve.co.uk> wrote:
>
> Can some-one who saw the original post mis-aligned please
> confirm that I've managed to solve the indentation problem
> with my posts.
Problem is solved for me (an slrn user).
--
In Common Lisp quite a few aspects of pathname semantics are left to
the implementation.
Alan Crowe wrote:
> I think the problem is at my end, with my emacs putting in
> tabs. I've set `indent-tabs-mode' to `nil', and retyped
> bits of my post. I hope that the code below has (endp x) and
> (endp y) exactly aligned, for every-one.
Emacs users should also learn the M-x untabify function, which
operates on a region replacing all tabs with spaces. It is
unnecessary to worry about tabs in normal code, but it is nice
to untabify any code snippets that get copied to non-Lisp-source
text formats such as mail or documentation, where they may have
various additional indentation or tabbing rules applied to them.
It's easy to do. The hard part is remembering to do it.
Stefan Scholl <······@no-spoon.de> writes:
> On 2005-10-08 17:44:59, Fred Gilham wrote:
> > But these days I do spaces, and aggressively replace tabs. Then people
> > complain about my coding style again.
>
> You've done everything right when the only thing they complain about
> is the indention of your non-Lisp code.
Well, they also complain about my long variable names... :-)
--
Fred Gilham ······@csl.sri.com
A gold coin standard transfers monetary policy-making from central
bankers and government officials to the common man, who can walk into
a bank and demand payment for paper or digital currency in gold
coins. This is the ultimate form of democracy, and the Establishment
hates it. -- Gary North
Edi Weitz wrote:
> On Sat, 08 Oct 2005 14:00:00 GMT, "Steven M. Haflich" <···@alum.mit.edu> wrote:
>
>> It is unnecessary to worry about tabs in normal code
>
> I don't agree. Even if you use Emacs and someone else looking at your
> code also uses Emacs they might not have the same tabs settings. IMHO
> tabs don't belong into code. Luckily, Emacs makes it easy to get rid
> of them once and for all.
In ASCII or a superset a tab is eight spaces. In a high-level editor
(like Emacs, not vi) you don't see the actual whitespace representation,
and you shouldn't. I think my editor is free to use tabs to save a
couple % of storage space, but I don't know if it does.
In C and Java code things are different, because indentation is not
alignment-based, like in Lisp, but block-based. IMHO only tabs should
be used, and rendered by the editor in whatever block indentation amount
people like (2, 4, 8...).
--
We're glad that graduates already know Java,
so we only have to teach them how to program.
somewhere in a German company
(credit to M. Felleisen and M. Sperber)
Ulrich Hobelmann <···········@web.de> writes:
> In C and Java code things are different, because indentation is not
> alignment-based, like in Lisp, but block-based. IMHO only tabs should
> be used, and rendered by the editor in whatever block indentation
> amount people like (2, 4, 8...).
Lisp code is indented for the purpose of making it look pretty,
and this is done according to its syntax, which is mostly block
structured; the syntax is known to the editor. Lisp syntax is
simpler, but involves a lot more nested expressions than what
people coming from most other languages are used to.
Beginner programmers who don't understand the syntax of the language
will sometimes screw this up -- maybe they are thinking that since
Lisp seems different than other languages, perhaps it should therefore
look very strange. Or perhaps they are beginner programmers who would
also write just as ugly C code. Often they don't quite understand the
code that they are writing, and they mess up the syntax - they didn't
understand the syntax, and didn't realize the editor could fix it up
for them so that it would illuminate their misunderstandings.
Or perhaps they just didn't realize that TAB characters would
likely get mangled by their some newsgroup posting software.
I think you are using the word "block" and "alignment"
in some way that I don't quite understand.
A good editor will understand the material being edited,
and present it to the user in a meaningful and comfortable way.
The fact that ASCII is used as the highest level program
code interchange protocol is ridiculous. Instead of arguing
over what TAB should mean, perhaps something more sophisticated
ought to be discussed and implemented. The idea that source
code should be divided into these units called "files" is stupid.
This is old news; the mystery is: why hasn't anyone done
anything about this stuff in the last couple of decades.
Maybe now that the idea object/database file systems are
starting to catch on in the mainstream...
Christopher C. Stacy wrote:
> I think you are using the word "block" and "alignment"
> in some way that I don't quite understand.
With alignment I meant that a Lisp line is indented so that it lines up
with the line before in a way that "makes sense," i.e. so that
parameters are on the same column, or that the body of a LET is a bit to
the right.
Block-based means that you have indentation levels (= blocks) that are
indented with uniform width, no matter what they contain. A tab seems
like a natural intentation identifier to me which editors could
interpret according to user preferences.
> A good editor will understand the material being edited,
> and present it to the user in a meaningful and comfortable way.
> The fact that ASCII is used as the highest level program
> code interchange protocol is ridiculous.
Agreed. That's why the user shouldn't care about tabs and such in
high-level structured code (like sexps).
> Instead of arguing
> over what TAB should mean, perhaps something more sophisticated
> ought to be discussed and implemented. The idea that source
> code should be divided into these units called "files" is stupid.
Absolutely. Something like Smalltalk class browsing is really cool.
Most modern Java IDEs seem to be just frontends for file-based editing,
though.
> This is old news; the mystery is: why hasn't anyone done
> anything about this stuff in the last couple of decades.
Good question that I'd like an answer to, too.
> Maybe now that the idea object/database file systems are
> starting to catch on in the mainstream...
--
We're glad that graduates already know Java,
so we only have to teach them how to program.
somewhere in a German company
(credit to M. Felleisen and M. Sperber)
······@news.dtpq.com (Christopher C. Stacy) writes:
> The fact that ASCII is used as the highest level program
> code interchange protocol is ridiculous.
I strongly disagree. I haven't heard of any more convenient way of
editing program text than by typing characters.
> Ulrich Hobelmann <···········@web.de> writes:
>> In C and Java code things are different, because indentation is not
>> alignment-based, like in Lisp, but block-based. IMHO only tabs should
>> be used, and rendered by the editor in whatever block indentation
>> amount people like (2, 4, 8...).
[...]
> I think you are using the word "block" and "alignment"
> in some way that I don't quite understand.
In most non-Lisp syntaxes the conventional indentation rules use
nesting levels which increase only by 1. That is, there is a constant
N such that, after removing empty lines and comments, for each pair of
adjacent lines where the next line is indented more than the previous
line, it's indented by exactly N columns more.
If it's not strictly true in all cases, it's at least common,
excluding e.g. C/C++ labels (which might be outdented by half of a
normal indentation) or continuation lines (indented not as far as
to the next level). It's also often true when the indentation is
decreasing, but this time there are more exceptions.
The width of a single indentation level depends on the typical depth
of nesting. For C 4 columns is common; some people even use 8 columns
and claim that more than 3 nesting levels is too deep. OTOH for OCaml
the standard indentation width is only 2, because OCaml encourages
deeper indenting than C.
Lisp is usually indented quite differently. Indentation doesn't use
fixed levels because people put the first element of an indented
sequence right after the word which introduces the sequence, and line
up other elements under it, and thus the indentation width depends
on the number of letters in that word.
Lisp yields much more different indentation levels within a given
height of code. Various constructs introduce their own nesting while
their equivalents in other languages don't.
--
__("< Marcin Kowalczyk
\__/ ······@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
Marcin 'Qrczak' Kowalczyk wrote:
> ······@news.dtpq.com (Christopher C. Stacy) writes:
>
>> The fact that ASCII is used as the highest level program
>> code interchange protocol is ridiculous.
>
> I strongly disagree. I haven't heard of any more convenient way of
> editing program text than by typing characters.
Typing doesn't imply that the program you're editing shouldn't be
structured above text level. I think Lisp is already a small step in
the structural direction, and some Emacs modes already provide text
navigation/editing at a more structural than character level.
--
Blessed are the young for they shall inherit the national debt.
Herbert Hoover
Ulrich Hobelmann <···········@web.de> writes:
>>> The fact that ASCII is used as the highest level program
>>> code interchange protocol is ridiculous.
>> I strongly disagree. I haven't heard of any more convenient way of
>> editing program text than by typing characters.
>
> Typing doesn't imply that the program you're editing shouldn't be
> structured above text level. I think Lisp is already a small step in
> the structural direction, and some Emacs modes already provide text
> navigation/editing at a more structural than character level.
This is OK. But I would hate if navigating and editing by structure
was the only possibility, i.e. if I couldn't add characters "(when
blah" in one place and ")" in another. Also I like being able to
decide whether to split an expression into lines, so it stays in
the same shape as it was written.
--
__("< Marcin Kowalczyk
\__/ ······@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
Barry Margolin wrote:
>
> Independent of the indenting problems, I've also never seen code that
> puts something on the same line *after* the close parens of a multi-line
> expression. I'm referring to the lines:
>
> ((< (car x)
> (car y)) 'less)
> ((> (car x)
> (car y)) 'more)
I see it from maybe 20% of new Lisp and Scheme programmers in my
courses. Most are harder to read than the above, e.g., for a DrScheme
function:
(define (make-grid-button number)
(make-button (if (= number 0)
" "
(number->string number))(lambda (e) (hide-window w))))
It's one of my standard critiques. I can only guess that they are just
operating in some "stay on the same line till it gets full" mode.