How many spaces a tab is worth David Allouche (01 Dec 2003 12:44 UTC)
Re: How many spaces a tab is worth bear (02 Dec 2003 04:16 UTC)
Re: How many spaces a tab is worth redhog@xxxxxx (04 Dec 2003 20:33 UTC)
Re: How many spaces a tab is worth Bradd W. Szonye (04 Dec 2003 22:05 UTC)
Re: How many spaces a tab is worth Taylor Campbell (04 Dec 2003 22:43 UTC)
Re: How many spaces a tab is worth redhog@xxxxxx (05 Dec 2003 00:06 UTC)
Re: How many spaces a tab is worth bear (05 Dec 2003 00:27 UTC)

Re: How many spaces a tab is worth redhog@xxxxxx 04 Dec 2003 20:33 UTC

Dear Bear,

I won't comment much on your mail, as it seems to mostly be a troll.
This said, your comment on Schemes with this syntax enabled by default
needs a remark; the syntax is constructed in such a way as to be
backward compatible with the normal S-expression-based syntax -
I-expressions could be enabled by deffault without breaking any but a
very small set of old code.

Specifically, the only code that would break, would be code that had
two consecutive topplevel expressions, with the second line indented
more, as in

(define foo bar)

   (define fie naja)

To code like that clearly is not very usefull, and so isn't found in
many progams (most progams I've seen have had all topplevel
expressions non-indented).

However, regardless of this, I _do_ agree withy you and don't think
anything like this should be "enabled by default", there simply is no
need for that as SRFI-7 gives a way for a Scheme program to specify
its need for this or any other SRFI, and some implementors may shoose
to implement this SRFI as a module in their module-system (my
reference implementation for example, is a GNU Guile module), in which
case their normal module import function can be called uppon to use
this SRFI.

The rest of your garbage, I've dumped in /dev/null...

Best regards,

bear <> writes:

> First, I should say upfront that I think indentation-sensitive
> syntax is a Bad Idea.
> Second, I should say upfron that I think scheme is one of the
> worst *POSSIBLE* languages to apply indentation-sensitive syntax
> to.
> If this SRFI is implemented, I will stop using any scheme that
> implements it and enables it by default.
> Okay?  You understand where I'm at on this whole proposal, right?
> Now, understanding that this is a bad idea in the first place,
> allowing mixed spaces and tabs is the worst possible way to do it.
> Even the pythonistas, who have a language that indentation-sensitive
> syntax (sorta) works for, have had no end of fights over tabs and
> spaces, and they're now in the process of banning them.
> Understanding that it's the worst design for a bad idea, reading
> a tab as equal to FOUR spaces is the worst possible number that
> could have been plugged into this design.  Standard editing software
> assumes tabs are EIGHT spaces by default; two of your FOUR space
> tabs will line up exactly with people's expectation of where a single
> EIGHT space tab should be, and hence cock up their thinking about the
> code as well as cocking up the code itself.
> I probably won't check back into this particular SRFI thread; I'll
> just take it as a warning that there are idiots out there who would
> do this, and implementation of it as a sign from God that the
> implementor has in fact gone insane and that their scheme should be
> avoided in the future.
> 					Bear

GPG Public key:
Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread!