First impressions of the specification Mark H Weaver (22 Mar 2013 06:32 UTC)
Re: First impressions of the specification Alan Manuel Gloria (22 Mar 2013 09:23 UTC)
Re: First impressions of the specification David A. Wheeler (22 Mar 2013 12:49 UTC)
Re: First impressions of the specification John Cowan (22 Mar 2013 13:52 UTC)
Re: First impressions of the specification David A. Wheeler (22 Mar 2013 21:58 UTC)
Re: First impressions of the specification Mark H Weaver (23 Mar 2013 02:12 UTC)
Re: First impressions of the specification David A. Wheeler (25 Mar 2013 00:07 UTC)
Re: First impressions of the specification Mark H Weaver (26 Mar 2013 04:20 UTC)
Re: First impressions of the specification David A. Wheeler (26 Mar 2013 05:07 UTC)
Re: First impressions of the specification John Cowan (26 Mar 2013 08:48 UTC)
Re: First impressions of the specification Alan Manuel Gloria (26 Mar 2013 09:03 UTC)
Re: First impressions of the specification John Cowan (26 Mar 2013 09:28 UTC)
Re: First impressions of the specification Mark H Weaver (26 Mar 2013 12:04 UTC)
Re: First impressions of the specification David A. Wheeler (26 Mar 2013 13:13 UTC)
Re: First impressions of the specification David A. Wheeler (26 Mar 2013 05:08 UTC)
Re: First impressions of the specification David A. Wheeler (26 Mar 2013 21:49 UTC)
Re: First impressions of the specification Mark H Weaver (27 Mar 2013 01:43 UTC)
Re: First impressions of the specification David A. Wheeler (27 Mar 2013 03:49 UTC)
Re: First impressions of the specification Mark H Weaver (27 Mar 2013 05:24 UTC)
Re: First impressions of the specification Alan Manuel Gloria (27 Mar 2013 07:30 UTC)
Re: First impressions of the specification Mark H Weaver (27 Mar 2013 13:01 UTC)
Re: First impressions of the specification Alan Manuel Gloria (28 Mar 2013 02:20 UTC)
Re: First impressions of the specification David A. Wheeler (28 Mar 2013 02:45 UTC)
Re: First impressions of the specification David A. Wheeler (27 Mar 2013 21:31 UTC)
Re: First impressions of the specification Mark H Weaver (30 Mar 2013 16:12 UTC)
Re: First impressions of the specification David A. Wheeler (30 Mar 2013 18:15 UTC)
Re: OT: Formatting Lisp code from the command line Mark H Weaver (30 Mar 2013 21:36 UTC)
Re: OT: Formatting Lisp code from the command line John Cowan (30 Mar 2013 21:45 UTC)

Re: First impressions of the specification Mark H Weaver 30 Mar 2013 16:12 UTC

Hi David,

"David A. Wheeler" <xxxxxx@dwheeler.com> writes:

> Mark H Weaver:
>> Some more comments, unrelated to the recent changes:
>>
>> * I continue to find the use of unconventional indentation in the
>>   s-expression examples to be quite distracting.  I've never seen Scheme
>>   or Lisp code indented that way.
> ...
>> * I think you should consider using conventional indentation in your
>>   t-expression examples where reasonable, e.g. for 'if' and 'do'
>>   Personally, I find this:
>>
>>     define gcd(x y)
>>       if {y = 0}
>>          x
>>          gcd y rem(x y)
>>
>>   much easier to read than your convention of:
>>
>>     define gcd(x y)
>>       if {y = 0}
>>         x
>>         gcd y rem(x y)
>
> The only difference I see is that "x" is indented by 2 spaces in our case,
> and in your case, "x" is lined up with "{" with the assumption that characters
> are always fixed-width characters of equal width.  Is that correct?

Yes.

>> ...  Is there a compelling reason to break this tradition?
>
> I don't know how much of a "tradition" this is, I haven't done a study.

I'm sorry, but this makes me think that you have very little experience
working with other Schemers or reading existing Scheme code.  These
indentation rules that I'm talking about are nearly universally accepted
in the Scheme community.  It's not like other programming languages like
C where there are several competing traditions.  Indentation is one of
the precious few things that we mostly all agree on.

> I'll note that guile's pretty-printer, by default, does NOT line up
> the condition and the branches; by default it uses "fixed-indent", not
> "line-up-indent".

That only demonstrates that our pretty-printer is rather primitive.

> There are *reasons* I use fixed-indent.  First of all, the fixed-indent rule
> is really simple: "indent fixed amount X".  In the "line-up-indent" style,
> I have to figure out what to line up.

Those of us who use Emacs don't have to figure out what to line up,
because it simply does it for us.  This is how the vast majority of
Schemers write code.

Now I get the impression that your unusual indentation style is mostly
motivated by the fact that you're using a very primitive auto-indenter.

> If I change some line with "if" etc. in "line-up-indent" style,
> I'll feel compelled to change the indentation of the lines below to
> "fix" a style issue. These cause extra work and
> spurious "changes" when looking at diffs.

I don't understand how this is any different between the two styles.
Changing the subexpressions within the 'if' does not change the
indentation in either style.  Can you give a specific example that
demonstrates your point here?

> The line-up-indent approach also
> assumes that you know the encoding and visual width of all characters.
> This is increasingly untrue in an international world with
> non-ASCII chars, various encodings, and variable-width fonts.

The line-up approach assumes fixed-width fonts, yes, but I don't see the
relevance of non-ASCII chars or encodings.  Existing free fixed-width
fonts support a great many languages.

Regarding the assumption of fixed-width fonts: I agree that it's
suboptimal to have such an assumption, but the fact is that in the
programming world, fixed-width characters are the only way we have of
lining things up vertically beyond the left edge of text, e.g. comments
to the right of the code.  Until we have another way to accomplish this,
I expect that variable-width fonts will continue to be ubiquitous in
programming use.

Of course, when you typeset a paper or book with code excerpts, it is
common to use variable-width fonts, but in that case it is possible to
insert formatting commands to make things line up vertically.  In the
programming world we don't have that, so variable-width fonts are a
non-starter.  Being able to line things up is far more important to the
overall visual presentation than having a slightly prettier font.

Anyway, regardless of whether you find these arguments compelling, the
undeniable fact is that almost the entire rest of the Scheme community
has reached consensus on indentation style.  It's about the only thing
we can agree on.  You are an outlier.  That's not necessarily a bad
thing.  In a sense, all of us Schemers are outliers in the larger
programming community, so we can relate :)

For all I know, maybe you're ahead of the curve on this, and someday
many of us will switch to fixed-indent; I don't think so, but who knows?
But I'd like you to at least understand that you're rocking the boat in
more ways than necessary in your presentation of this SRFI, and I
suspect that it will have a negative effect on how well this SRFI is
received by the average Schemer.

I don't plan to write any more on this topic.

    Regards,
      Mark