Re: [Readable-discuss] The "." as indentation whitespace proposal
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 the table; sorry about the confusion. Alan Manuel Gloria and I are provisionally agreeing on SPLIT semantics, not SPLICE. See [Current]. As the name implies, SPLIT *breaks up* a line it's in the middle of into two lines. We don't have *agreement* on anything that joins up a list, though there are several on the table. My guess is that we won't be adding one, but we'll see. > -- What happens when we have a sublist indent after a line with a '\\' > SPLICE? Does it become a sublist of the last list of the SPLICE? Again, we have SPLIT not SPLICE Example 1 (where \\ means SPLIT): \\ ! f(a) ! f(b) => ((f a) (f b)) \\ g(a) ! g(b) ! g(c) => ((g a) (g b) (g c)) >I think using a '\\' is better than a single '\' is better, because it is more >visually appealing. Good! My *primary* concern is to avoid symbols that will *prevent* acceptance, but we should strive for as much visual appeal as we can manage. Nobody likes looking at nasty-looking code. > -- To get to the bottom of the issue of whether it is valuable to admit "." > as whitespace, I think we need real code examples. While coming up with fake > examples can be informative (I hadn't thought about the implications of "\\" > splice and following sublists...), ultimately, they are also dangerous, > because they don't represent actual code, and how it might be naturally written. Agree. I've written a lot of code samples, see [Examples] and the examples subdirectory. > -- I'm still on the fence with this, although one compelling argument *for* > the convention involves my experience with Python: when I'm desperate enough > to replace all the " " indents with "--|" or ".(or something just as > heavy), it eliminates the possibility of cutting snippets of Python and > pasting it into an REPL. Of course, Python, with its tradition of including > ellipses before every line in its REPL, makes it more difficult to cutting > snippets from the REPL and pasting it into an editor--and impossible to paste > *back* into the REPL. Fair enough. Which is also why I think it's critical that the interactive syntax and the file syntax be exactly identical. And suggests that there is value to a non-whitespace indent character. > I think this example also shows that using two spaces for indentation, when > whitespace is significant, can also be difficult to read. In using Python, I > tent to prefer three spaces, but when the editor defaults to four, I don't > fight it (and it's probably better too); and there are certainly times where > a LOT of indentation clears things up really quickly! That's probably a style thing, I *like* 2 space indents. But as long as the reader *permits* both, I think that's okay. --- 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 Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] The "." as indentation whitespace proposal
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 think you're using COND correctly--but
> that could just be me, because I'm an inexperienced Lisper, but I'm coming
> from a Common Lisp background.
> I've tried to re-write this as a classical s-expr, and I got this:
This is cool, the following is called a "classical s-expr" and it
has curly-infix and modern-expressions embedded inside it.
Mark this date down :-)!!!
BTW, I don't normally enable HTML display of email, but I sure
couldn't follow this post *without* enabling it.
I'm going to repost this as ordinary text, so that others who
only see straight text can follow it.
First, here's the S-expression as written by Alpheus Madsen:
> (cond
> ((expr1? f) (let ((var (list-of x
> ({t in '(1 2 3 4)}
> (pred? t)
> {x in range-of(0 t)})))
>(var2 (kitty ('meow) ('meow
> (execute
> ((foo var))
> ((quux var2)
> ((expr2? f) (progn (kitty
>('niaw)
>(expand-upon('niaw)))
> (woorf f)))
>(#t (error "bobcat: NYAWR")))
I haven't done a detailed study of the code, but the format looks okay
on a quick look.
> Then I've re-written this as a sweet-expression:
>
> cond
>exprl?(f) \\ let
>\\ var list-of(x
> ({t in '(1 2 3 4)}
>pred?(t)
>{x in range-of(0 t)}))
> var2
> kitty
> 'meow
> 'meow
>exprl2?(f) \\ progn
>
> kitty
>'niaw
>expand-upon('niaw)
> woorf(f)
>#t \\ error("bobcat: NYAWR")
This rewritten form isn't the same as "traditional" S-expr that precedes it.
The fragment:
> cond
>exprl?(f) \\ let
is by definition exactly the same as:
> cond
>exprl?(f)
>let
which is (cond (exprl? f) let ...).
"Split" in the middle of a line essentially causes a line break, and
starts over at the next indent. It's just a way of expressing in one
what you'd otherwise have to say in 2.
Also,
>\\ var list-of(x
is exactly the same as:
>var list-of(x
Again, "\\" is like a newline, but since the next line is at the SAME
indent level, nothing happens. This is useful for showing a line
that is logically related to the previous one, but has to NOT
actually be a child.
Is that clearer?
In general, conds aren't usually written that way in sweet-expressions.
If the test conditions and the expressions of the result actions are short,
you'll likely see (using "!" as an indentation character):
cond
! condition1 resulting-expression1
! condition2 resulting-expression2
...
If they aren't short, then the expressions would be children of the condition:
cond
! condition1
! ! resulting-expression1
! condition2
! ! resulting-expression2
A "let" is going to typically look like this:
let
! \\
! ! var1 expr...
! ! var2 expr..
! expression-calculating-let.
I think sweet-expressions handle "cond" nicely. Let, less so.
This is complicated, obviously:
(cond
((expr1? f) (let ((var (list-of x
({t in '(1 2 3 4)}
(pred? t)
{x in range-of(0 t)})))
(var2 (kitty ('meow) ('meow
(execute
((foo var))
((quux var2)
((expr2? f) (progn (kitty
('niaw)
(expand-upon('niaw)))
(woorf f)))
(#t (error "bobcat: NYAWR")))
Here's one way to rewrite it (if "!" is an indentation character)
that I believe is an accurate reflection of the s-expression version:
!cond
! expr1?(f)
!let
! \\
!var
! list-of x
!{t in '(1 2 3 4)} pred?(t) {x in range-of(0 t)}
!var2(kitty(('meow) ('meow)))
! execute (foo(var)) (quux(var2))
! expr2?(f)
!progn kitty(('niaw) (expand-upon('niaw))) woorf(f)
! #t error("bobcat: NYAWR")
(If I made a mistake, let me know.)
--- 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/j
Re: [Readable-discuss] The "." as indentation whitespace proposal
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 I'm an inexperienced Lisper,
but I'm coming from a Common Lisp background.
I've tried to re-write this as a classical s-expr, and I got this:
(cond
((expr1? f) (let ((var (list-of x
({t in '(1 2 3 4)}
(pred? t)
{x in range-of(0 t)})))
(var2 (kitty ('meow) ('meow
(execute
((foo var))
((quux var2)
((expr2? f) (progn (kitty
('niaw)
(expand-upon('niaw)))
(woorf f)))
(#t (error "bobcat: NYAWR")))
Then I've re-written this as a sweet-expression:
cond
exprl?(f) \\ let
\\ var list-of(x
({t in '(1 2 3 4)}
pred?(t)
{x in range-of(0 t)}))
var2
kitty
'meow
'meow
exprl2?(f) \\ progn
kitty
'niaw
expand-upon('niaw)
woorf(f)
#t \\ error("bobcat: NYAWR")
I think my implementation is also flawed--again, the problem centers around
COND--because I don't think my re-write correctly wraps the conditions with
the correct results. From this, I have the following observations and
questions:
-- 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?
-- What happens when we have a sublist indent after a line with a '\\'
SPLICE? Does it become a sublist of the last list of the SPLICE?
-- I think using a '\\' is better than a single '\' is better, because it
is more visually appealing.
-- To get to the bottom of the issue of whether it is valuable to admit "."
as whitespace, I think we need real code examples. While coming up with
fake examples can be informative (I hadn't thought about the implications
of "\\" splice and following sublists...), ultimately, they are also
dangerous, because they don't represent actual code, and how it might be
naturally written.
-- I'm still on the fence with this, although one compelling argument *for*
the convention involves my experience with Python: when I'm desperate
enough to replace all the " " indents with "--|" or ". " (or something
just as heavy), it eliminates the possibility of cutting snippets of Python
and pasting it into an REPL. Of course, Python, with its tradition of
including ellipses before every line in its REPL, makes it more difficult
to cutting snippets from the REPL and pasting it into an editor--and
impossible to paste *back* into the REPL.
-- I think this example also shows that using two spaces for indentation,
when whitespace is significant, can also be difficult to read. In using
Python, I tent to prefer three spaces, but when the editor defaults to
four, I don't fight it (and it's probably better too); and there are
certainly times where a LOT of indentation clears things up really quickly!
On Thu, Jul 19, 2012 at 3:03 PM, Alan Manuel Gloria wrote:
> On Fri, Jul 20, 2012 at 12:03 AM, Alpheus Madsen
> 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) in Python and PHP when I
> really
> > needed to see the structure.
> >
> > Come to think of it, there is Emacs code out there that can color-code
> the
> > levels; I have never tried using it, though.
>
> My argument still stands, though: sometimes the tool isn't there.
> There's something to stuff that just works with plain text.
>
> "." is the lightest syntax that is still typeable on the standard
> keyboard: the period is the character with the smallest canonical
> graphical representation that is typeable on a majority (all?) of
> keyboards.
>
> So: I'd like to know, if you think:
>
> cond
> expr1?(f)
> let
> \\
> var
> list-of x
> t in '(1 2 3 4)
> pred?(t)
> x in range-of(0 t)
> var2
> kitty
> 'meow
> 'meow
> execute
> foo(var)
> quux(var2)
> expr2?(f)
> kitty
> 'niaw
> expand-upon('niaw)
> woorf(f)
> #t
> error "bobcat: NYAWR"
>
> is superior to:
>
> cond
> expr1?(f)
> . let
> . \\
> . . var
> . . list-of x
Re: [Readable-discuss] The "." as indentation whitespace proposal
On Fri, Jul 20, 2012 at 12:03 AM, Alpheus Madsen
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) in Python and PHP when I really
> needed to see the structure.
>
> Come to think of it, there is Emacs code out there that can color-code the
> levels; I have never tried using it, though.
My argument still stands, though: sometimes the tool isn't there.
There's something to stuff that just works with plain text.
"." is the lightest syntax that is still typeable on the standard
keyboard: the period is the character with the smallest canonical
graphical representation that is typeable on a majority (all?) of
keyboards.
So: I'd like to know, if you think:
cond
expr1?(f)
let
\\
var
list-of x
t in '(1 2 3 4)
pred?(t)
x in range-of(0 t)
var2
kitty
'meow
'meow
execute
foo(var)
quux(var2)
expr2?(f)
kitty
'niaw
expand-upon('niaw)
woorf(f)
#t
error "bobcat: NYAWR"
is superior to:
cond
expr1?(f)
. let
. \\
. . var
. . list-of x
. . t in '(1 2 3 4)
. . pred?(t)
. . x in range-of(0 t)
. . var2
. . kitty
. . 'meow
. . 'meow
. execute
. foo(var)
. quux(var2)
expr2?(f)
. kitty
. 'niaw
. expand-upon('niaw)
. woorf(f)
#t
. error "bobcat: NYAWR"
?
Personally, now that I've adjusted to the "." as indentation, it seems
to me that the "." vertical lines there are superior. In fact, typing
in the latter is much easier than the former - I don't have to count
indents, I just look at the periods as a guide line/construction line
so that I align properly. If we can make sweet-expressions much
easier to type in at a small cost to readability - and I think the
latter case as above isn't so bad readably, and is superior - than
perhaps we should consider putting it in.
Sincerely,
AmkG
--
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
Readable-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] The "." as indentation whitespace proposal
> > 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) in Python and PHP when I really needed to see the structure. Come to think of it, there is Emacs code out there that can color-code the levels; I have never tried using it, though. On Wed, Jul 18, 2012 at 3:33 PM, Alan Manuel Gloria wrote: > On Thu, Jul 19, 2012 at 2:45 AM, Alpheus Madsen > 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 for > ways to > > toggle visual whitespace (certainly Kate, and probably Vi and Emacs); and > > sometimes I'll do a formal search and replace between " " and "--|" and > > back, when I need a better handle on the structure...but those are > editing > > functions, and I'm not sure if it would be a good idea to have these > things > > formally in the source code. > > You don't always get to use a text editor with that. Consider a long > piece of indentation-sensitive code that you're viewing online on say > github or sourceforge - or just plain FTP for that matter. I think it > would be much better to actually give small amounts of "." in > strategic places to give a better view. > > You don't have to use it all the time - "." as indentation is > optional. Certainly using "--|" is very heavy, but the point of using > . is that it is much lighter visually. It's meant to suggest thin > lines as you would put them on a printout, in order to view the > structure of the code without adding any particular meaning. > > > -- > 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 > Readable-discuss@lists.sourceforge.net > 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 Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] The "." as indentation whitespace proposal
On 7/19/12, David A. Wheeler 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 unread-char. > > Hmm, I'd think of that as a bug. Hmm. Here's an X3J13 Common Lisp issue UNREAD-CHAR-AFTER-PEEK-CHAR: http://www.lispworks.com/documentation/lw61/CLHS/Issues/iss356_w.htm Basically the write-up describes peek-char as equivalent to read-char followed by unread-char. Meaning that doing an unread-char after a peek-char is not allowed, as it becomes two unread-char's in sequence. In fact, I think this restriction goes all the way back to C. C has ungetc and getc , but no peekc. To implement Scheme using FILE*, you'd implement peek-char as getc followed by ungetc. Of course modern Scheme implementations will wrap FILE* if they still use it, but most Schemes start out as ridiculously simple implementations (taking advantage of the relative small size of R5RS/R4RS). Less is more and all that jazz. And think about it: R5RS already gives you one character lookahead on ports. Your proposed implementation (wrap R5RS port with cons-buffer) adds another character lookahead buffer, giving a total of 2 characters lookahead. Still, as long as we require that unread-char is only ever used by the "." as indentation whitespace implementation, I think it's OK. I think it's a slippery slope and you'll have to get more characters of lookahead, and thus lose strict R5RS-compliance. -- http://scheme.com/csug8/io.html Chez Scheme mentions that unbuffered ports have a one-character buffer in order to support unread-char and peek-char: "When the unbuffered option is specified, input is unbuffered, but not fully, since one character of buffering is required to support peek-char and unread-char." As the X3J13 UNREAD-CHAR-AFTER-PEEK-CHAR issue points out, this *probably* ends up meaning that peek-char followed by unread-char will fail. -- 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 Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] The "." as indentation whitespace proposal
On Thu, Jul 19, 2012 at 2:45 AM, Alpheus Madsen 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 for ways to > toggle visual whitespace (certainly Kate, and probably Vi and Emacs); and > sometimes I'll do a formal search and replace between " " and "--|" and > back, when I need a better handle on the structure...but those are editing > functions, and I'm not sure if it would be a good idea to have these things > formally in the source code. You don't always get to use a text editor with that. Consider a long piece of indentation-sensitive code that you're viewing online on say github or sourceforge - or just plain FTP for that matter. I think it would be much better to actually give small amounts of "." in strategic places to give a better view. You don't have to use it all the time - "." as indentation is optional. Certainly using "--|" is very heavy, but the point of using . is that it is much lighter visually. It's meant to suggest thin lines as you would put them on a printout, in order to view the structure of the code without adding any particular meaning. -- 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 Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] The "." as indentation whitespace proposal
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 indent to when I add another > clause in a long cond for example. Support that and I'm happy. Okay, in that case, I'll change it to cons a period when it reads a period. It's easier to *relax* constraints than to *add* them, so we can always switch later if we start with the more constrained version. It's also a slightly easier rule to describe. --- 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 Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] The "." as indentation whitespace proposal
On Thu, Jul 19, 2012 at 6:23 AM, David A. Wheeler 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 unread-char. > > Hmm, I'd think of that as a bug. > >> Generally, once an implementation supports both peek-char and >> unread-char without such a conflict they start supporting unlimited >> unread-char, so we might as well require that. > > No need. I'd like to minimize the implementation requirements, and Chez > Scheme (at least) only supports 1-char unread-char. > >> You know, I suspect that splitting the parser into a token scanner and >> a 0-lookahead (always consume next token) parser might actually be >> able to parse sweet-expressions. This is a much more different parser >> and requires a full reimplementation down to #-readers though. > > Perhaps. If we have to write portions of the parser, that's fine; the key is > that it has to be *implementable*, and then obviously we need a good > *implementation* for its use. > >> Otherwise, fine, #1 #2 or #4 is fine with me. > > Okay, that's good. I strongly prefer #4, so if all are okay by you, and I > have a strong preference, we have a winner. > >> Also, latest code seems to convert .-indent into spaces, is this >> deliberate? > > Yes, but that doesn't mean it should stay that way. > >> I proposed that, but only if it allowed me to draw >> something like this: >> >> let >> \ >> foo bar ; highlight this line >> . nitz quux >> meow >> >> Since multiple periods without intervening spaces are no longer >> allowed as indent, the utility of this punning is significantly >> reduced IMO. You can remove it if you think it gives better >> indentation-safety (i.e. convert the (cons #\space (accumulate-hspace >> port)) call to (cons #\. (accumulate-hspace port))). > > My reason to interpret period as space is to allow *vertical* highlighting of > a *range* that doesn't include the whole range: > > aa > . bb > . . cc > . . dd > . . ee > . ff > . gg > > But there are definitely advantages to cons'ing period, in particular, it'd > enforce consistency of indentation - enabling us to detect indentation > screw-ups. > > So I can be easily convinced to switch to consing period & forcing consistent > indentation. What do you think? The example you've given feels like a subset of the highlighting examples I want to make, viz.: aa . bb cc .dd ee . ff . gg 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 indent to when I add another clause in a long cond for example. Support that and I'm happy. Sincerely, AmkG -- 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 Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] The "." as indentation whitespace proposal
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, once an implementation supports both peek-char and > unread-char without such a conflict they start supporting unlimited > unread-char, so we might as well require that. No need. I'd like to minimize the implementation requirements, and Chez Scheme (at least) only supports 1-char unread-char. > You know, I suspect that splitting the parser into a token scanner and > a 0-lookahead (always consume next token) parser might actually be > able to parse sweet-expressions. This is a much more different parser > and requires a full reimplementation down to #-readers though. Perhaps. If we have to write portions of the parser, that's fine; the key is that it has to be *implementable*, and then obviously we need a good *implementation* for its use. > Otherwise, fine, #1 #2 or #4 is fine with me. Okay, that's good. I strongly prefer #4, so if all are okay by you, and I have a strong preference, we have a winner. > Also, latest code seems to convert .-indent into spaces, is this > deliberate? Yes, but that doesn't mean it should stay that way. > I proposed that, but only if it allowed me to draw > something like this: > > let > \ > foo bar ; highlight this line > . nitz quux > meow > > Since multiple periods without intervening spaces are no longer > allowed as indent, the utility of this punning is significantly > reduced IMO. You can remove it if you think it gives better > indentation-safety (i.e. convert the (cons #\space (accumulate-hspace > port)) call to (cons #\. (accumulate-hspace port))). My reason to interpret period as space is to allow *vertical* highlighting of a *range* that doesn't include the whole range: aa . bb . . cc . . dd . . ee . ff . gg But there are definitely advantages to cons'ing period, in particular, it'd enforce consistency of indentation - enabling us to detect indentation screw-ups. So I can be easily convinced to switch to consing period & forcing consistent indentation. What do you think? --- 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 Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] The "." as indentation whitespace proposal
On Thu, Jul 19, 2012 at 12:12 AM, David A. Wheeler 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 order to >> support what I consider to be minor advantages. > > I just posted an updated reader with that implementation, it turned out to be > really easy to implement with unread-char. While unread-char isn't part of > R5RS, it's available in at least two Schemes, and we could create little > portability layer to implement unread-char for other Schemes. > > So since it's easy to implement, can you accept #4 (period + space or tab as > indentation)? > > --- David A. Wheeler 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. Generally, once an implementation supports both peek-char and unread-char without such a conflict they start supporting unlimited unread-char, so we might as well require that. You know, I suspect that splitting the parser into a token scanner and a 0-lookahead (always consume next token) parser might actually be able to parse sweet-expressions. This is a much more different parser and requires a full reimplementation down to #-readers though. Otherwise, fine, #1 #2 or #4 is fine with me. Also, latest code seems to convert .-indent into spaces, is this deliberate? I proposed that, but only if it allowed me to draw something like this: let \ foo bar ; highlight this line . nitz quux meow Since multiple periods without intervening spaces are no longer allowed as indent, the utility of this punning is significantly reduced IMO. You can remove it if you think it gives better indentation-safety (i.e. convert the (cons #\space (accumulate-hspace port)) call to (cons #\. (accumulate-hspace port))). Sincerely, AmkG -- 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 Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] The "." as indentation whitespace proposal
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 reader with that implementation, it turned out to be really easy to implement with unread-char. While unread-char isn't part of R5RS, it's available in at least two Schemes, and we could create little portability layer to implement unread-char for other Schemes. So since it's easy to implement, can you accept #4 (period + space or tab as indentation)? --- 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 Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] The "." as indentation whitespace proposal
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, but I just realized there's a *much* simpler approach: use unread-char(). All we need is one-character unread-char, and it's trivial to implement. unread-char() *is* in at least guile (at least 1.8) and in ChezScheme (http://practical-scheme.net/wiliki/schemexref.cgi?ChezScheme). It's not a standard R5RS operation, but since the C standard does require ungetc() with at least one-char pushback, I wouldn't be surprised if other Schemes support it (or could be talked into it). Guile supports unlimited pushback, ChezScheme supports 1-char pushback; we only need 1 char. If we need to port it to Schemes without unread-char(), we could create a thin portability layer to add unread-char support (by creating a special "port" that stores any 1-char unread, which would only be the period if used). The code in modern.scm has to handle leading period specially anyway, in process-period, and the first thing *IT* does is get the char (which undoes any unread-char of a period), so it shouldn't change much of the rest. --- 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 Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] The "." as indentation whitespace proposal
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 of indentation matching. > > 2. dwheeler's current implemented proposal: > The characters tab, space, and "." are indentation characters; "." > loses the whitespace meaning outside of indentation. For purposes of > indentation matching "." in the current line must match a "." in the > indentation of the previous line. > > 3. dwheeler's initial "." proposal > Indentation may start with either tab, space, or any number of ".", > and the rest of indentation is either tabs or spaces. For purposes of > indentation matching "." in the current line must match a "." in the > indentation of the previous line. > > 4. dwheeler's pair-characters proposal > The characters tab and space are indentation characters, and the "." > character, if followed by a tab or space, is also an indentation > character (if followed by a newline, it's not an indentation > character). The "." character loses its whitespace meaning outside of > indentation. For purposes of indentation matching "." in the current > line must match a "." in the indentation of the previous line. Great summary. > My position is #1. I could accept #2 if that's what the consensus is. ... > 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. Clearly if it's too hard to implement then we shouldn't do it. 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, around where SPLIT-at-start is implemented, we could probably read in a potential symbol starting with period. Once read in, if the symbol is EXACTLY one period and it is followed by space or tab, we could interpret the period as space, and recurse back to readblock-internal with an updated indent (interpreting the period as space). I don't have time to try this right now, I have to go to work, but it looks feasible on a quick look. So, if that's not too hard to implement, would this approach be acceptable to you? It would let you use period to deal with HTML (the period as indentation original purpose), draw out lines (new additional purpose), allow us to use period-on-a-line for improper lists, and allow us to use symbols that start with period (but aren't period) without problems. --- 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 Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] The "." as indentation whitespace proposal
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 of indentation matching. 2. dwheeler's current implemented proposal: The characters tab, space, and "." are indentation characters; "." loses the whitespace meaning outside of indentation. For purposes of indentation matching "." in the current line must match a "." in the indentation of the previous line. 3. dwheeler's initial "." proposal Indentation may start with either tab, space, or any number of ".", and the rest of indentation is either tabs or spaces. For purposes of indentation matching "." in the current line must match a "." in the indentation of the previous line. 4. dwheeler's pair-characters proposal The characters tab and space are indentation characters, and the "." character, if followed by a tab or space, is also an indentation character (if followed by a newline, it's not an indentation character). The "." character loses its whitespace meaning outside of indentation. For purposes of indentation matching "." in the current line must match a "." in the indentation of the previous line. -- My position is #1. I could accept #2 if that's what the consensus is. 1. I like it because we can draw arbitrary graphics using "." characters in the indentation area. This is useful for highlighting sections of code. 2. I could accept #2 since most of the graphics I'm going to draw are simple vertical lines showing the indentation level of long cond clauses and what-not. The loss of drawing arbitrary graphics is minor to consensus. I'd still prefer #1 though. 3. I can't accept #3 since it only allows drawing a vertical line at the very left edge, or possibly a bar graph limited to the indentation level, neither of which are useful. 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. In particular, the ... symbol is only majorly used in Scheme's syntax-rules. Now, the idiom in using ... looks like this: (syntax-rules () ((begin x body ...) (let ((v x)) (begin body ...)) blah blah If we are to use indentation, and try to match the appearance as closely as possible: syntax-rules () . \ . . begin x . . body \ ... . . \ let ((v x)) . . . begin . . . body \ ... blah blah Note that we need to "escape" the ..., as otherwise it will be paired with body, resulting in (body ...) instead of two separate elements body and ... So I think requiring \ for . and .. an ... are fine to me. -- 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 Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] The "." as indentation whitespace proposal
> In https://sourceforge.net/p/readable/wiki/Current/ > you correctly pointed out that "." as indentation whitespace causes problems > with symbols like "..." in Scheme. Okay, another crazy idea: period only has an indentation meaning ONLY if it's followed by tab or space. Pros: * Don't need to escape symbols beginning with "." (unless it's "." itself, which is a highly improbable first symbol on a line for a list). * You can still use period to "draw" indentation levels in very long definitions or sub-clauses (which I admit is useful - and clever). * No special "column 1" rule Cons: * Now period *HAS* to be followed by space/tab if it's to have its indentation meaning. If you use 2+ space indenting that's no big deal, if you use 1-space indenting that's annoying. Under this semantic, the previous example still works: > define-syntax do-it > . syntax-rules () > .group > . do-it > .x > . group x > .group > . do-it > .x > .body > .... > . group begin > . x > . do-it > .body > .... --- 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 Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] The "." as indentation whitespace proposal
In https://sourceforge.net/p/readable/wiki/Current/ you correctly pointed out that "." as indentation whitespace causes problems with symbols like "..." in Scheme. HOWEVER, perhaps there's a much simpler approach: period only has an indentation meaning in column 1. Then the example could look like this: define-syntax do-it . syntax-rules () .group . do-it .x . group x .group . do-it .x .body .... . group begin . x . do-it .body .... Pros: * You don't need to escape symbols that begin with period (e.g., ...) unless they're in column 1. I think that's a lot less common; minimizing the need for escapes is a good thing. * People who want only whitespace indentation, or period indentation, can quickly switch. Cons: * Now you REALLY can't use periods to "emphasize" something. I don't mind that loss, I know you thought that interesting. A variant could be that periods only have the indentation meaning until the first non-period. Then this is valid: ... body ... ... As silly as the period-as-indentation rule appeared to me at first, it's sortof growing on me. Maybe we should keep some variant of it. --- 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 Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] The "." as indentation whitespace proposal
On Tue, Jul 10, 2012 at 11:09 AM, David A. Wheeler
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 quite fine, but that prevents us from drawing simple "pointing"
>> graphics in the indentation space. Although I suppose that depends on
>> whether you view it as something that is ripe for abuse, or as a
>> simple way of putting attention towards things.
>
> For "pointing" graphics you could just use ";" comment lines.
It's a bit more heavyweight, viz:
define foo(x)
define {y <=> z}
. doing
. let w \ compute-x(y)
. let u \ compute-u(z)
let v \ compute-v(y z x) ; take note of this thingy
. let n \ merge(w u v)
. n
<=>
define foo(x)
define {y <=> z}
. doing
. let w \ compute-x(y)
. let u \ compute-u(z)
;---
. let v \ compute-v(y z x) ; take note of this thingy
;---
. let n \ merge(w u v)
. n
<=>
Sincerely,
AmkG
--
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
Readable-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] The "." as indentation whitespace proposal
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 quite fine, but that prevents us from drawing simple "pointing" > graphics in the indentation space. Although I suppose that depends on > whether you view it as something that is ripe for abuse, or as a > simple way of putting attention towards things. For "pointing" graphics you could just use ";" comment lines. An advantage of the exact match is that you can easily tell when you did something inconsistent. --- 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 Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] The "." as indentation whitespace proposal
On Tue, Jul 10, 2012 at 7:36 AM, David A. Wheeler wrote: >> > "When processing indentation, beginning at the left-hand-side, a period is >> > equivalent to a space character until the first character that is not a >> > period, blank, or tab." > > 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. (So if you use a period > to indent a line, you have to use it in the same place in the next line if > it's indented to the same level). It was trivial to implement (a one-line > change). > That's quite fine, but that prevents us from drawing simple "pointing" graphics in the indentation space. Although I suppose that depends on whether you view it as something that is ripe for abuse, or as a simple way of putting attention towards things. Sincerely, AmkG -- 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 Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] The "." as indentation whitespace proposal
> > "When processing indentation, beginning at the left-hand-side, a period is > > equivalent to a space character until the first character that is not a > > period, blank, or tab." 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. (So if you use a period to indent a line, you have to use it in the same place in the next line if it's indented to the same level). It was trivial to implement (a one-line change). --- 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 Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] The "." as indentation whitespace proposal
On Sun, Jul 8, 2012 at 1:00 AM, David A. Wheeler wrote:
>> > 2. It can be used to highlight indentation for whatever purpose that may
>> > serve.
>>
>> To illustrate #2, consider the following contrivedly complicated code
>> (but I think you'd end up with similarly complicated code after
>> developing a project for a while).
>>
>> define foo(x)
>> define bar(y z)
>> . let
>> . \
>> . . quux frobnicate(y z)
>> . . quuux frobnicate(z y)
>
> To clarify, the rule you're thinking is:
> "When processing indentation, beginning at the left-hand-side, a period is
> equivalent to a space character until the first character that is not a
> period, blank, or tab."
>
> I think that's a good (experimental) rule.
Yes, I think this is a good rule.
With ". in indent = SPACE" we can draw simple stuff in the indent space:
define foo(x)
...define bar(y)
. let
. ...\
. . v {x + y}
. ...w {x - y}
... {v * w}
bar
Okay, I'll look at implementing it in the parser spec.
Sincerely,
AmkG
--
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
Readable-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] The "." as indentation whitespace proposal
> > 2. It can be used to highlight indentation for whatever purpose that may
> > serve.
>
> To illustrate #2, consider the following contrivedly complicated code
> (but I think you'd end up with similarly complicated code after
> developing a project for a while).
>
> define foo(x)
> define bar(y z)
> . let
> . \
> . . quux frobnicate(y z)
> . . quuux frobnicate(z y)
To clarify, the rule you're thinking is:
"When processing indentation, beginning at the left-hand-side, a period is
equivalent to a space character until the first character that is not a period,
blank, or tab."
I think that's a good (experimental) rule.
> define {a *<=>* b}
This one is cool. I hadn't thought to *define* infix operators using infix
notation. Perhaps that's because I'm too used to traditional Lisp notation, or
perhaps it's because few languages let you *define* infix operators using infix
notation (even ones that do don't use infix in definitions).
I really like this ability to define infix operators in infix notation, it
looks really clean.
--- 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
Readable-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] The "." as indentation whitespace proposal
> Pros: > > 1. It is useful for cases when we need to send code snippets by HTML > e-mail transport, which tends to cut off "real" whitespace. > 2. It can be used to highlight indentation for whatever purpose that may > serve. > > Cons: > > 1. It prevents us from using "." for the proposed GROUP - basically, > it prevents any syntax from using "." at the start of a line (it > shouldn't prevent the symbol from being used within or at the end of a line) Agree. Obviously, if we use "." for the group, this idea dies instantly. There's also: 2. It complicates using symbols beginning with "."; some escape mechanism like "(. .mysymbol)" or "\.mysymbol" must be used. Few people use symbols beginning with '.'. 3. It's different from any other indentation system, which makes it less familiar, and some may reject it because it's so "unusual". > My vote is "Maybe". That's where I am too. If we don't use "." as the GROUP symbol, we might try allowing for a little while (as an experiment) and feel free to use it in email. We can easily drop it later, if we make it clear this is an "experimental" feature. So I'm of a mind to give it a whirl for a little while, even if it's slightly crazy. It looks especially useful for discussing syntax in email, so it might play the role of "scaffolding" - helping us do the rest, and then we remove it when we're done. All of this is moot if we use "." as the GROUP symbol; then this dies instantly. --- 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 Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] The "." as indentation whitespace proposal
On 7/6/12, Alan Manuel Gloria wrote:
> Here we discuss the " '.' as indentation whitespace proposal"
>
> Pros:
>
> 1. It is useful for cases when we need to send code snippets by HTML
> e-mail transport, which tends to cut off "real" whitespace.
> 2. It can be used to highlight indentation for whatever purpose that may
> serve.
To illustrate #2, consider the following contrivedly complicated code
(but I think you'd end up with similarly complicated code after
developing a project for a while).
define foo(x)
define bar(y z)
. let
. \
. . quux frobnicate(y z)
. . quuux frobnicate(z y)
. complicate
. {quux *<=>* quuux}
. frobnicate(quux)
. cond
. {quux >=< quuux}
. 1
. #t
. 2
define frobnicate(a b)
. {
. {a + {{b - a} * 100}}
. /
. {b - a}
. }
define
. \ complicate
. . a
. . b
. . c
. cond
. . {a >=< b}
. . a
. . {b >=< c}
. . b
. . #t
. . c
define {a >=< b}
. {
. {frobnicate(a b) < frobnicate(a 1)}
. or
. {frobnicate(b a) < frobnicate(b -1)}
. }
define {a *<=>* b}
. { {a + b} / {a - b - 100 } }
;
;
bar(x {x + 1000})
--
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
Readable-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/readable-discuss
