I'm still kindof neutral on whether or not there should be a non-whitespace
character that acts as a whitespace character. Even so, I'm also inclined
to think that, since we're talking about Lisp, there's always a chance that
somewhere, someone has written a function or macro that begins with a given
character, *especially* if that character is ASCII and isn't considered a
special character by Lisp.
I the biggest challenge in trying to figure out a good
non-whitespace-character to use as whitespace is that historically, ASCII
has been the limit of what can be used in a computer language; and
historically, what hasn't been whitespace, has been used, reused, and
overloaded extensively in all sorts of languages, not just Lispy
ones...thus, regardless the character, we would have to be prepared to
provide an escape mechanism for it, if we wanted to use it as initial
whitespace.
Or, at least, regardless the ASCII character set. I'm sure we'd be able to
find something in the Unicode Astral Planes that would work nicely...at
least, until someone wants to write a program in Cuniform, and we just
happened to co-opt one of the most useful characters for starting things in
ancient Hittite! :-)
On Fri, Jul 20, 2012 at 11:32 AM, David A. Wheeler <[email protected]>wrote:
> I propose that we drop "."+space/tab as an indentation character, and
> instead, declare that a simple "!" is an indentation character JUST LIKE
> space or tab.
>
> This is:
> 1. Trivial to implement. unread-char goes away, the code is easier to
> separate, etc.
> 2. It's trivial to explain.
> 3. It is *REALLY* great for highlighting ranges (better than "."), I think
> it's far better than "." for this purpose. When dealing with
> whitespace-killers like HTML it's okay, perhaps not as nice-looking as "."
> but workable.
> 4. Preserves the advantages of having a non-whitespace indent character.
>
> Details below.
>
> Thoughts? Comments? Like it? Hate it? Kindof neutral?
>
> --- David A. Wheeler
>
>
> Alan Manuel Gloria said:
> > Not if the indentation tracking finds a ".", then fails to see a tab
> > or space after it. Then it's forced to have 2 characters overhead,
> > which the modern-expr reader must read back to find the symbol or
> > number that begins with "."
>
> I think the *look* of period+space/tab is nice, but the implementation
> problems are getting to be rediculous. Leading period is *especially*
> problematic in Scheme, since it can indicate a number *or* symbol, and a
> "." by itself is the symbol used to quickly create improper lists. It
> creates the need for a lot of gyrations, and a dependency on an unread-char
> that isn't universally supported.
>
> But having a non-whitespace character for indent is turning out to be
> remarkably useful:
> 1. It's great when whitespace is dropped (e.g., HTML email)
> 2. It's great for highlighting regions.
>
> We could use "~", but Arc uses leading "~" for not. In the cases where
> you always put the condition after the word "if" this doesn't matter, but
> since Arc has *alternating* condition / action syntax, I'd expect Arc text
> to sometimes look like this:
> if condition1
> action1
> condition2
> action2
> condition3
> action3
> ...
>
> We could use "!"+space/tab. That's actually a little better than "."; you
> really need to hand off handling of "." to the underlying modern-expression
> parser (because "." is complicated. I think we could isolate its
> complications to the indentation processor if it's not a period, *without*
> the lower-level reader needing to know. But it'd still create
> complications in its implementation. Compared to the stark simplicity of
> "! is an indenting character" it's breathtaking.
>
> This would obviously be slightly annoying to languages like wart, where
> leading "!" has a meaning. But I think those cases are rare, and this only
> matters if it's just after indentation... so:
> if !myfunction(...)
> could retain that meaning if desired.
>
> --- David A. Wheeler
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Readable-discuss mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/readable-discuss
>
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Readable-discuss mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/readable-discuss
