First of all, I want to make it clear that I'm not completely opposed to
using . as an option for indentation.
Having said that, I think your examples are flawed; the logic of your
example is difficult to follow. I also don't think you're using COND
correctly--but that could just be me, because
Alpheus Madsen said on Fri, 20 Jul 2012 11:25:54 -0700:
First of all, I want to make it clear that I'm not completely opposed to
using . as an option for indentation.
Good!
Having said that, I think your examples are flawed; the logic of your example
is difficult to follow. I also don't
Alpheus Madsen said:
-- How do we pair up two lists on a single line? If I understand correctly,
the '\\' SPLICE context creates two lists, where we would expect one list.
Does it also wrap up the two lists in a single parent list?
Ah, I think I see the issue. We've had lots of proposals
On Fri, Jul 20, 2012 at 12:03 AM, Alpheus Madsen
alpheus.mad...@gmail.com wrote:
Certainly using --| is very heavy, but the point of using . is that it
is much lighter visually.
Just for clarification: I've never used --| in a language as official
syntax; I've used it (and variations of it)
Alan Manuel Gloria:
Okay, let's recap this topic.
1. almkglor's original proposal:
At start-of-line, the . character is treated as a space character
until the first non-tab, non-space, non-. character. This means
that . can be used as indentation, and is equivalent to space for
purposes
Earlier I said:
But I think this shouldn't be TOO bad to implement. You're right that if we
use ONLY lookahead we can't do it. but I don't think that should be a
problem. In particular, in our current code, in sugar.scm's function
readblock-internal...
Hmm, that approach might not work,
Alan Manuel Gloria:
4. I can't accept #4 because I'm not assured that it is easy to
implement given a one-character lookahead implementation (Scheme). I
think that it is a significant implementation burden, in order to
support what I consider to be minor advantages.
I just posted an updated
On Thu, Jul 19, 2012 at 12:12 AM, David A. Wheeler
dwhee...@dwheeler.com wrote:
Alan Manuel Gloria:
4. I can't accept #4 because I'm not assured that it is easy to
implement given a one-character lookahead implementation (Scheme). I
think that it is a significant implementation burden, in
Alan Manuel Gloria:
IIRC some peek-char implementations are just read-char followed by
unread-char, with only one unread-char lookahead: so the sequence of
peek-char followed by unread-char might cause strange errors about too
many unread-char.
Hmm, I'd think of that as a bug.
Generally,
On Thu, Jul 19, 2012 at 6:23 AM, David A. Wheeler dwhee...@dwheeler.com wrote:
Alan Manuel Gloria:
IIRC some peek-char implementations are just read-char followed by
unread-char, with only one unread-char lookahead: so the sequence of
peek-char followed by unread-char might cause strange
Alan Manuel Gloria:
I don't see it as having as much utility as drawing horizontal lines
of . in indentation area.
Still, either one will do. The most common use case I see is to draw
vertical lines in the indentation area so I that when I modify the
code, I can get to see where I should
On Thu, Jul 19, 2012 at 2:45 AM, Alpheus Madsen
alpheus.mad...@gmail.com wrote:
Third, I'm not sure I like the idea of using . for indentation. While it
helps to clarify the structure, it can also clutter the visual presentation
of the source code. I like the fact that word processors allows
On 7/19/12, David A. Wheeler dwhee...@dwheeler.com wrote:
Alan Manuel Gloria:
IIRC some peek-char implementations are just read-char followed by
unread-char, with only one unread-char lookahead: so the sequence of
peek-char followed by unread-char might cause strange errors about too
many
On Tue, Jul 10, 2012 at 11:09 AM, David A. Wheeler
dwhee...@dwheeler.com wrote:
Me:
I've now implemented the . as an indentation character in the git
repository, so we can experiment with it. I decided to *NOT* make it
equivalent to a space - you have to match exactly
AmkG:
That's
14 matches
Mail list logo
