Re: [Readable-discuss] The QUOTE proposals
On 7/8/12, David A. Wheeler dwhee...@dwheeler.com wrote: Alan Manuel Gloria: This simplifies the spec, but makes the following wrong: ' foo bar == (quote foo bar) The more complicated current spec yields: ' foo bar == (quote (foo bar)) The proposal is sensible, and I agree that it simplifies the spec slightly. But I think the more complicated current spec (based on the SFRI) is the better choice. Here's why. Imagine a longer expression like this: foo bar .. spam eggs eggs eggs .. spam eggs eggs eggs Under the current spec, you can quote the entire expression by adding quote-space to the front of the first line, e.g.: ' foo bar .. spam eggs eggs eggs .. spam eggs eggs eggs The same with comma, comma-at, or backquote. These kinds of transformations are pretty common, so making them really easy to do seems like a good idea. In addition, it means that it's really easy to *write* these expressions in the first place. You're right that this means that it means that traditional abbreviations like QUOTE will be handled differently than grouping, but that's already true in traditional Lisp anyway. 'x is already really special - a list suddenly appears, even though there are no ()s. Okay, that seems fine to me. 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: 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
[Readable-discuss] Reformatter starting to work
The reformatter (from traditional s-expr to sweet-expressions) is starting to
actually work.
I wrote it with sweet-expressions (of course!), so generate its Scheme file
with:
$ make iformat.scm
Now you can process Scheme s-expressions. For example, to see sugar.scm:
$ guile iformat.scm sugar.scm | less
I cheated by using object-string which isn't in R5RS, but is in guile. That
could be replaced later (in a portability layer), but it's a pain to generate
some data types without it.
There's a lot it doesn't do. In particular, there's only one term per line
(terms can have parameters, so {3 + 4} can be on a line), and it doesn't have
any clue about common Lisp function names how they might be better formatted.
But it's enough to able to see what things look like.
--- 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 QUOTE proposals
I said: ... I think the more complicated current spec (based on the SFRI) is the better choice. Here's why. Alan Manuel Gloria said (on Wed, 18 Jul 2012 14:54:53 +0800): Okay, that seems fine to me. Great! In that case, I think that completes the QUOTE discussion. I plan to mark that discussions on [Changes] as completed (let me know if I've misunderstood something). We are down to two (related) issues: GROUP/SPLICE/etc. and period-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: 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] Arne Babenhauserheide proposal: use . on own line instead of group
I've been trying to keep up with the activity that's been going on this
past month; but since I've been busy doing other things as well, I think I
failed. Even so, I've tried to review everything, and so I'd like to share
some thoughts.
First, I'm not sure what the status of \ is; or how it currently fits in
with the proposed GROUP, SLICE, etc semantics. (I don't fully understand
those semantics, but I suspect that they'll be cleared up in the 0.3
Spec...if I understand correctly, though, these are the names of how \
has been proposed to be used.)
On the one hand, I like using \ as a way to end a line; using it to
separate two lists seems kindof reasonable. I'm not sure if using it as a
replacement for group will fix things.
On the other hand, using \ in this overloaded way can potentially be
confusing. Since the different contexts are mostly orthogonal to each
other, this isn't likely to be too much of a problem...except that the
biggest clash will be in the fact that \ is also Common Lisp's Escape
Character. Indeed, it is because of this that I couldn't see how to
comandeer Haskell's use of \ as lambda. As much as I like it, I'd more
likely use Paul Graham's fn instead. (Like group, I think lambda is
an over-handed keyword for an important, simple concept.)
Which gives me an idea that would further overload \: If it isn't too
complicated, we can define \(...etc...) to be lambda! (I have the sneaky
suspicion that Common Lisp will make this too complicated, though...)
About a week ago, as I was thinking about the GROUP issue, I had the idea
to use an ellipses in the following manner:
let
... x 10
y 12
{x + y}
This would be equivalent to (and compatible with)
let
...
x 10
y 12
{x + y}
That is, the ellipses designates a group; if anything follows the ellipses
on the same line, it's considered a list in and of itself; any sublist
contained in the ellipses would be appended to the original ellipses.
This would be simpler to implement than the other idea I proposed, which
was to have a series of ellipses, like so:
let
... x 10
... y 12
{x + y}
The reason this is a concern with me, is that one of the reasons I consider
GROUP to be heavy-handed (besides being a long name) was that it
introduced an extra line that I consider unnecessary.
Of course, this semantic would work just as well with GROUP, or ., or
even \, or perhaps even something like ::, as it would for ellipses;
I'm just partial to using ellipses myself.
Second, one of the thoughts I've been having lately, is a concern about the
attempt to be compatible with as many Lisps as possible. While I think
this is a useful concern--indeed, it allows sweet-expressions to be tested
in a variety of environments--it can also hamper a good idea, if not used
cautiously. For example, if using \ in its various contexts is a good
idea, the fact that Common Lisp hampers it by using \ as an escape
character shouldn't result in its complete rejection. (It may, however, be
one of several valid reasons to eventually reject the character for
something different.)
This concern goes both ways: Arc, if I understand correctly, uses \ to
separate two lists on a line. If this is a good idea (and I tend to think
it is), then it should be kept; if it becomes clear that it's awkward,
though, the concept should be rejected, with a special exception being made
for Arc for compatibility reasons.
Indeed, since no two Lisp variants are strictly compatible with each other,
trying to come up with a sweet-expression spec that's fully compatible
between every variant may even be impossible!
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.
So, these are some of my thoughts concerning these proposals. I hope they
prove to be useful!
On Sun, Jul 15, 2012 at 7:42 PM, David A. Wheeler dwhee...@dwheeler.comwrote:
Alan Manuel Gloria:
Actually, I think I very much prefer the \.
I think your visual argument is sound. I particularly appreciate that you
divided up the issue into different use cases, that makes it much easier to
follow.
BUT. What concerns me is that \ is already taken by Common Lisp, and I
recall that some other Lisps have done the same. Per the Common Lisp
hyperspec spec:
http://www.lispworks.com/documentation/HyperSpec/Body/02_b.htm
A \ followed by space would begin a symbol whose name begins with space,
by definition.
Yes, we could say that \+space loses
Re: [Readable-discuss] Arne Babenhauserheide proposal: use . on own line instead of group
I've been trying to keep up with the activity that's been going on this
past month; but since I've been busy doing other things as well, I think I
failed. Even so, I've tried to review everything, and so I'd like to share
some thoughts.
First, I'm not sure what the status of \ is; or how it currently fits in
with the proposed GROUP, SLICE, etc semantics. (I don't fully understand
those semantics, but I suspect that they'll be cleared up in the 0.3
Spec...if I understand correctly, though, these are the names of how \
has been proposed to be used.)
On the one hand, I like using \ as a way to end a line; using it to
separate two lists seems kindof reasonable. I'm not sure if using it as a
replacement for group will fix things.
On the other hand, using \ in this overloaded way can potentially be
confusing. Since the different contexts are mostly orthogonal to each
other, this isn't likely to be too much of a problem...except that the
biggest clash will be in the fact that \ is also Common Lisp's Escape
Character. Indeed, it is because of this that I couldn't see how to
comandeer Haskell's use of \ as lambda. As much as I like it, I'd more
likely use Paul Graham's fn instead. (Like group, I think lambda is
an over-handed keyword for an important, simple concept.)
Which gives me an idea that would further overload \: If it isn't too
complicated, we can define \(...etc...) to be lambda! (I have the sneaky
suspicion that Common Lisp will make this too complicated, though...)
About a week ago, as I was thinking about the GROUP issue, I had the idea
to use an ellipses in the following manner:
let
... x 10
y 12
{x + y}
This would be equivalent to (and compatible with)
let
...
x 10
y 12
{x + y}
That is, the ellipses designates a group; if anything follows the ellipses
on the same line, it's considered a list in and of itself; any sublist
contained in the ellipses would be appended to the original ellipses.
This would be simpler to implement than the other idea I proposed, which
was to have a series of ellipses, like so:
let
... x 10
... y 12
{x + y}
The reason this is a concern with me, is that one of the reasons I consider
GROUP to be heavy-handed (besides being a long name) was that it
introduced an extra line that I consider unnecessary.
Of course, this semantic would work just as well with GROUP, or ., or
even \, or perhaps even something like ::, as it would for ellipses;
I'm just partial to using ellipses myself.
Second, one of the thoughts I've been having lately, is a concern about the
attempt to be compatible with as many Lisps as possible. While I think
this is a useful concern--indeed, it allows sweet-expressions to be tested
in a variety of environments--it can also hamper a good idea, if not used
cautiously. For example, if using \ in its various contexts is a good
idea, the fact that Common Lisp hampers it by using \ as an escape
character shouldn't result in its complete rejection. (It may, however, be
one of several valid reasons to eventually reject the character for
something different.)
This concern goes both ways: Arc, if I understand correctly, uses \ to
separate two lists on a line. If this is a good idea (and I tend to think
it is), then it should be kept; if it becomes clear that it's awkward,
though, the concept should be rejected, with a special exception being made
for Arc for compatibility reasons.
Indeed, since no two Lisp variants are strictly compatible with each other,
trying to come up with a sweet-expression spec that's fully compatible
between every variant may even be impossible!
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.
So, these are some of my thoughts concerning these proposals. I hope they
prove to be useful!
On Sun, Jul 15, 2012 at 7:42 PM, David A. Wheeler dwhee...@dwheeler.comwrote:
Alan Manuel Gloria:
Actually, I think I very much prefer the \.
I think your visual argument is sound. I particularly appreciate that you
divided up the issue into different use cases, that makes it much easier to
follow.
BUT. What concerns me is that \ is already taken by Common Lisp, and I
recall that some other Lisps have done the same. Per the Common Lisp
hyperspec spec:
http://www.lispworks.com/documentation/HyperSpec/Body/02_b.htm
A \ followed by space would begin a symbol whose name begins with space,
by definition.
Yes, we could say that \+space loses
Re: [Readable-discuss] The . as indentation whitespace proposal
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 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] Arne Babenhauserheide proposal: use . on own line instead of group
Alan Manuel Gloria almkg...@gmail.com Actually, I think I very much prefer the \. How about \\ for SPLIT/GROUP? Or use \\ for SPLIT, and something else (say ) for GROUP? I *think* that using \\ would resolve my concerns about slashification, and I know you like the look of the \ character for many use cases. We really don't *need* to have single-character symbols for either GROUP or SPLIT. Even with Scheme's one-char lookahead, you can easily read in the whole symbol before making that decision (our current implementation does). I think it's important that it be non-alphabetic, for clarity (all other abbreviations are punctuation), but there's no implementation reason either have to be single characters. Heck, Lisps already support multi-character abbreviations like ,@. --- 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] Arne Babenhauserheide proposal: use . on own line instead of group
Okay, here are a couple of complex examples for group et al.:
define-syntax list-of
syntax-rules (is in)
; base case
\
. list-of x
. \ list x
; handle (var in x) clause
\
. list-of x
. var in expr
. clauses \ ...
. \ concatenate
. . map
. . lambda (var)
. . list-of x
. . clauses \ ...
. . expr
; handle (var is x) clause
\
. list-of x
. var is expr
. clauses \ ...
. \ let ((var expr))
. . list-of x
. . clauses \ ...
; handle (pred? x) clause
\
. list-of x
. pred?(args ...)
. clauses \ ...
. \ if pred?(args ...)
. .list-of x
. . clauses \ ...
. .'()
define xforce(promise)
let ((content unbox(promise)))
case car(content)
(eager)
cdr(content)
(lazy)
let*
\
promise* cdr(content)()
content unbox(promise)
if not{ car(content) eqv? 'eager }
begin
set-car! content car(unbox(promise*))
set-cdr! content cdr(unbox(promise*))
set-box! promise* content
xforce(promise)
--
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 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 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] Bundle of git changes
Alan Manuel Gloria almkg...@gmail.com Bundle time! ... commit 4492dc4a42c5d6b3553491fe36a8b9c1d6bfbe1a Author: Alan Manuel K. Gloria almkg...@gmail.com Date: Thu Jul 19 06:20:03 2012 +0800 Add example nfx macro implementation. This very simple implementation of nfx allows very simple arithmetic precedence, and nothing else. Committed. Should we change all the sweet-expression Scheme file extensions from .scm to .sscm? I'd like to do that. It'd make it easier to auto-invoke translators, as well as making it clear that you need the sweet-reader for those files. --- 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: 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 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 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] Bundle of git changes
On Thu, Jul 19, 2012 at 6:30 AM, David A. Wheeler dwhee...@dwheeler.com wrote: Alan Manuel Gloria almkg...@gmail.com Bundle time! ... commit 4492dc4a42c5d6b3553491fe36a8b9c1d6bfbe1a Author: Alan Manuel K. Gloria almkg...@gmail.com Date: Thu Jul 19 06:20:03 2012 +0800 Add example nfx macro implementation. This very simple implementation of nfx allows very simple arithmetic precedence, and nothing else. Committed. Should we change all the sweet-expression Scheme file extensions from .scm to .sscm? I'd like to do that. It'd make it easier to auto-invoke translators, as well as making it clear that you need the sweet-reader for those files. Okay, but I have to go to work now ^^. The advantage of .scm is that guile by default includes it in the %load-extensions, if we use .sscm we need to do (set! %load-extensions (cons .sscm %load-extensions)) or some such (not 100% sure, need to check in an actual guile). Maybe we could modify sweet-guile to do that also so that it's a lot more seamless. 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] Arne Babenhauserheide proposal: use . on own line instead of group
define-syntax list-of syntax-rules (is in) ; base case \ . list-of x . \ list x ; handle (var in x) clause \ . list-of x . var in expr . clauses \ ... . \ concatenate . . map . . lambda (var) . . list-of x . . clauses \ ... . . expr ; handle (var is x) clause \ . list-of x . var is expr . clauses \ ... . \ let ((var expr)) . . list-of x . . clauses \ ... ; handle (pred? x) clause \ . list-of x . pred?(args ...) . clauses \ ... . \ if pred?(args ...) . .list-of x . . clauses \ ... . .'() As a first experiment, let's see if I can easily recreate what this translates to: (define-syntax list-of (syntax-rules (is in) ((list-of x) (list x)) ((list-of x (var in expr) clauses ...) (concatenate (map (lambda (var) (list-of x clauses ...)) expr))) ((list-of x (var is expr) clauses ...) (let ((var expr)) (list-of x clauses ...))) ((list-of x (pred? args ...) (clauses ...)) (if (pred? args ...) (list-of x (clauses ...)) '() Observations: a) If this is right, why do we need the period-backslash construct, say in the base case? Wouldn't just indentation (two periods) suffice? b) Should we really have to insert a backslash in empty lines? Wart just applies the enter-enter rule at the repl, not in batch mode. Did y'all consider that? c) Are the periods for indentation optional? It's confusing/distracting to mix spaces with periods in the same code. d) I notice that avoiding parens is *much* more compact. It lets me see the global structure at a glance. Let me see if I can reconstruct that property by bringing back some parens: define-syntax list-of syntax-rules (is in) \ list-of x list x \ list-of x (var in expr) clauses ... concatenate map (lambda (var) (list-of x clauses ...)) expr \ list-of x (var is expr) clauses ... let ((var expr)) list-of x clauses ... \ list-of x pred?(args ...) (clauses ...) if pred?(args ...) list-of x (clauses ...) '() Ok, I see why you need GROUP support :) It's because common lisp and scheme use more parens than arc. I also found myself missing arc's syntax for compose, so that I could say: concatenate:map (lambda (var) (list-of x clauses ...)) expr Is this translation correct? I'm not sure which proposal this maps to. Is it subsumed by one of the suggestions? -- 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
[Readable-discuss] SPLICE
1. I'm making heavy weather of the difference between SPLIT and SPLICE at http://sourceforge.net/p/readable/wiki/Current 2. I think I can come to terms with GROUP (as long as it doesn't have to be on a line by itself), but I don't like SPLICE. The example given is in arc: if cond1() \ expr1() cond2() \ expr2() \ expr3() I'd rather just insert parens and say: (if cond1() expr1() cond2() expr2() expr3()) Or: (if cond1() expr1() cond2() expr2() expr3()) In either case, I'd give up indent inside the clause and try to keep it simple by refactoring. -- 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 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 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] wart
ii) An indentation-sensitive lisp like wart requires mentally inserting parens to make sure we aren't accidentally wrapping something we didn't mean to. People indent even when it's *not* significant, so this turns out to be a non-problem. The indentation ends up working with, not against. But the context for my statement was (http://www.mail-archive.com/readable-discuss@lists.sourceforge.net/msg00272.html): Say you're trying to track down a bug in evaluation: No matter how intuitive, we're going to run into cases where we accidentally mal-indent and need to track down the bug. It's like a stray paren or semi-colon. During debugging you have to drop down a layer of abstraction and think about the paren insertion itself. -- 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
[Readable-discuss] Fwd: SPLICE
On 7/19/12, Kartik Agaram a...@akkartik.com wrote: 1. I'm making heavy weather of the difference between SPLIT and SPLICE at http://sourceforge.net/p/readable/wiki/Current SPLICE: allows this: foo bar \ .nitz kuu == (foo bar nitz kuu) SPLIT doesn't. SPLIT: allows this: \ . foo bar . nitz kuu == ( (foo bar) (nitz kuu)) SPLICE: ( foo bar (nitz kuu)) -- 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] Arne Babenhauserheide proposal: use . on own line instead of group
On 7/19/12, Kartik Agaram a...@akkartik.com wrote: define-syntax list-of syntax-rules (is in) ; base case \ . list-of x . \ list x ; handle (var in x) clause \ . list-of x . var in expr . clauses \ ... . \ concatenate . . map . . lambda (var) . . list-of x . . clauses \ ... . . expr ; handle (var is x) clause \ . list-of x . var is expr . clauses \ ... . \ let ((var expr)) . . list-of x . . clauses \ ... ; handle (pred? x) clause \ . list-of x . pred?(args ...) . clauses \ ... . \ if pred?(args ...) . .list-of x . . clauses \ ... . .'() As a first experiment, let's see if I can easily recreate what this translates to: (define-syntax list-of (syntax-rules (is in) ((list-of x) (list x)) ((list-of x (var in expr) clauses ...) (concatenate (map (lambda (var) (list-of x clauses ...)) expr))) ((list-of x (var is expr) clauses ...) (let ((var expr)) (list-of x clauses ...))) ((list-of x (pred? args ...) (clauses ...)) (if (pred? args ...) (list-of x (clauses ...)) '() Observations: a) If this is right, why do we need the period-backslash construct, say in the base case? Wouldn't just indentation (two periods) suffice? \ . list-of x . \ list x === ( (list-of x) (list x)) --- \ . list-of x . . list x === ( (list-of x list x)) b) Should we really have to insert a backslash in empty lines? Wart just applies the enter-enter rule at the repl, not in batch mode. Did y'all consider that? The use case is when you edit some file, but aren't 100% sure of the correctness of your edits. So you copy-paste the file's contents into the REPL. If the REPL supports ENTER-ENTER but the file has empty lines, you're going to have to insert backslashes or empty comment lines to your file anyway. So using the same rule in the file and in the REPL gives this advantage. c) Are the periods for indentation optional? It's confusing/distracting to mix spaces with periods in the same code. Yes. I find it easier for telling me whether I'm looking at syntax-rules pattern code or generated code - one . is pattern code, 2 . is generated code . It's useful in really long cond expressions: align a . at the condition's indentation, so that adding a new clause somewhere is easy - just press space until your cursor reaches the . d) I notice that avoiding parens is *much* more compact. It lets me see the global structure at a glance. Let me see if I can reconstruct that property by bringing back some parens: define-syntax list-of syntax-rules (is in) \ list-of x list x Incorrect. This yields: \ list-of x list x ( list-of x list x) This is a consequence of only wanting one symbol for GROUP and SPLICE. Here's a more parenthes-y version that is correct: define-syntax list-of syntax-rules (is in) (list-of x) list x (list-of x (var in expr) clauses ...) ...blah blah blah... \ list-of x (var in expr) clauses ... concatenate map (lambda (var) (list-of x clauses ...)) expr \ list-of x (var is expr) clauses ... let ((var expr)) list-of x clauses ... \ list-of x pred?(args ...) (clauses ...) if pred?(args ...) list-of x (clauses ...) '() Ok, I see why you need GROUP support :) It's because common lisp and scheme use more parens than arc. I also found myself missing arc's syntax for compose, so that I could say: concatenate:map (lambda (var) (list-of x clauses ...)) expr Is this translation correct? I'm not sure which proposal this maps to. Is it subsumed by one of the suggestions? Your proposal looks more like GRIT, which despite its name is a combination of what I call ENLIST and SPLIT. --- disgression on GROUP and ENLIST The problem lies in the original SRFI-49 from which we got I-expressions. It said The GROUP symbol is used to allow lists whose first element is also a list David Wheeler (and no doubt many others) thought it meant The GROUP symbol is used to FORCE a list to have the first element be a list. So they assumed that: group a b c d was the same as: group a b c d But it wasn't. You see, group ALLOWS the first element to be a list. It doesn't FORCE the first element to be a list. So: group a b c d === ( a b c d) But people were expecting: ( (a b) (c d)) I renamed this more intuitive interpretation of group as ENLIST to prevent confusion with the original GROUP meaning (i.e. GROUP-as-in-SRFI-49, which doesn't force listing). I called it ENLIST because it forcibly conscripts the rest of the line as a sublist. Dwheeler persists in calling the
[Readable-discuss] realistic examples
Alan, would you really prefer SPLIT/SPLICE to just combining clauses with the previous line when writing ( http://article.gmane.org/gmane.lisp.readable-lisp/367)? . list-of x . var in expr . clauses \ ... vs list-of (var in expr) clauses ... David Wheeler (http://article.gmane.org/gmane.lisp.readable-lisp/290): We've been doing a lot of experimentation, and pressing various notations as far as they will go to maximize readability. So you'll certainly see us try some odd things on occasion. I fear that 'pressing' might be distorting our sense of the relative frequency of different constructs. SPLIT/SPLICE is for arc's if; there it actually looks good as a separator. I would be less concerned about SPLIT if it's going to be fairly uncommon in other situations. Another example: I didn't even realize Common lisp permits backslash-escaping in symbols. Eeurgh! But nobody uses it, so it doesn't bother me and I don't have to bother with it. Perhaps we should bring up examples as we would write them, and explicitly state when a notation is being 'stretched'. This is an aesthetic project, so I think it's reasonable to have aesthetic opinions, rather than to try to accomodate hypothetical styles that we haven't encountered. -- 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] Bundle of git changes
Alan Manuel Gloria: Heya, looked at commit c94afdb0b89b1c1e2b8ec26111aef68308d59bd2, Awesome, and thanks. I'm a big believer in peer review. This seems different, shouldn't that be: +(if (or (char-whitespace? char) (eqv? #\newline char)) +(list qt) +(list qt (sugar-read-save port) I don't think so; char-whitespace?(#\newline) returns #t, so the extra or would be useless. R5RS says, The whitespace characters are space, tab, line feed, form feed, and carriage return. (http://www.schemers.org/Documents/Standards/R5RS/HTML/ ). I checked, and I don't think the semantics changed. If I checkout the version before that change, the semantics are the same as the current master c88432322f745: git checkout 7885ce091: $ ./sweet-filter ' a b = '(a b) It's fair to ask what the semantics SHOULD be in such cases, of course; that's what we're trying to nail down. I think it's *important* that: ' a b . c d = '(a b (c d)) *My* expectation would be that if you wanted the extra grouping level, you'd use a group mark: ' group a b = '((a b)) And that if you say: ' . a b It's really the same thing as: quote a b = (quote (a b) = '(a b) So I'm happy with the semantics the tool has currently in this case, which I believe are exactly the same as SRFI-49. There's no loss of generality, just add the group marker after the quote marker. --- 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] realistic examples
Well, all the examples I make are as how I would write them, not as how I would On 7/19/12, Kartik Agaram a...@akkartik.com wrote: Alan, would you really prefer SPLIT/SPLICE to just combining clauses with the previous line when writing ( http://article.gmane.org/gmane.lisp.readable-lisp/367)? . list-of x . var in expr . clauses \ ... vs list-of (var in expr) clauses ... Yes. Because I expect list-of to be used in this manner: let \ . bar . list-of quux(foo bar) . foo in some-func() . obs?(foo) . nitz in some-other-func(foo) . meow?(nitz) some-code(bar) Since that's how I expect list-of to look like in code that uses list-of, that's how I formatted my syntax-rules. So, it serves as a hint as to how to properly format the macro. David Wheeler (http://article.gmane.org/gmane.lisp.readable-lisp/290): We've been doing a lot of experimentation, and pressing various notations as far as they will go to maximize readability. So you'll certainly see us try some odd things on occasion. I fear that 'pressing' might be distorting our sense of the relative frequency of different constructs. SPLIT/SPLICE is for arc's if; there it actually looks good as a separator. I would be less concerned about SPLIT if it's going to be fairly uncommon in other situations. Another example: I didn't even realize Common lisp permits backslash-escaping in symbols. Eeurgh! But nobody uses it, so it doesn't bother me and I don't have to bother with it. Perhaps we should bring up examples as we would write them, and explicitly state when a notation is being 'stretched'. This is an aesthetic project, so I think it's reasonable to have aesthetic opinions, rather than to try to accomodate hypothetical styles that we haven't encountered. All the code I've been putting in examples/ is code as how I would write them. -- 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] Bundle of git changes
On 7/19/12, David A. Wheeler dwhee...@dwheeler.com wrote: Alan Manuel Gloria: Heya, looked at commit c94afdb0b89b1c1e2b8ec26111aef68308d59bd2, Awesome, and thanks. I'm a big believer in peer review. This seems different, shouldn't that be: +(if (or (char-whitespace? char) (eqv? #\newline char)) +(list qt) +(list qt (sugar-read-save port) I don't think so; char-whitespace?(#\newline) returns #t, so the extra or would be useless. R5RS says, The whitespace characters are space, tab, line feed, form feed, and carriage return. (http://www.schemers.org/Documents/Standards/R5RS/HTML/ ). AH, sorry, I confused char-horiz-whitespace? with char-whitespace? My bad. 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] Arne Babenhauserheide proposal: use . on own line instead of group
b) Should we really have to insert a backslash in empty lines? The use case is when you .. you copy-paste a file's contents into the REPL. a) In practice top-level forms tend to be separated by lines anyway in files. b) A smart repl could notice when a line is at the same indent as the previous expression, and eval the previous form. It might print things in the wrong place, something like this: + 1 2 . 7 3 7 Here I've colored* what the computer prints grey to distinguish from what the programmer types in. So the '+ 1 2' is evaluated after he's already started typing the next expression (7). I think this is ok. c) If you paste in several forms into the repl at once, you might need to type in an extra Enter like in the example above (the empty line just above 7). I think that's acceptable as well. What do people think? * - With apologies to those who don't see html formatting in their email. Please speak up if there's someone like that. I try to avoid html emails -- until there's a genuine need for extra formatting. -- 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] realistic examples
Well, all the examples I make are as how I would write them Ah, thanks for the clarification! -- 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] Arne Babenhauserheide proposal: use . on own line instead of group
\ . list-of x . . list x === ( (list-of x list x)) Would: \ . list-of x . list x be correct? -- 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] realistic examples
On 7/19/12, Kartik Agaram a...@akkartik.com wrote: Well, all the examples I make are as how I would write them Ah, thanks for the clarification! Anyway, I will also do some exploratory syntaxing, but if I find some problem or difficulty with it, I'll just silently drop it. You'll more reliably see how I prefer the code to look at in the example/ directory. -- 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] Arne Babenhauserheide proposal: use . on own line instead of group
On 7/19/12, Kartik Agaram a...@akkartik.com wrote: \ . list-of x . . list x === ( (list-of x list x)) Would: \ . list-of x . list x be correct? . is just whitespace. So: list-of x list x === (list-of x (list x)) list-of x . list x (list-of x (list x)) ; i.e. the same thing. To say I'm indenting this line for my own purposes, but I want you, indentation-processor, to act as if it's indented *over there*, you use SPLIT to mark where you want the indentation-processor to act: list-of x \ list x (list-of x) ( list x) -- 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] Arne Babenhauserheide proposal: use . on own line instead of group
On 7/19/12, Kartik Agaram a...@akkartik.com wrote: You see, group ALLOWS the first element to be a list. It doesn't FORCE the first element to be a list. So: group a b c d === ( a b c d) Clarification: Should this be (a b (c d))? Ah, yes, that's right. group a b c d === (a b (c d)) -- 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] Arne Babenhauserheide proposal: use . on own line instead of group
. is just whitespace. Ah, of course :/ I'm having trouble holding that in my head. Getting rid of periods, I'm still having trouble understanding why the second line isn't wrapped in parens in: \ a b c Shouldn't this be ((a (b c)))? -- 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] Arne Babenhauserheide proposal: use . on own line instead of group
On 7/19/12, Kartik Agaram a...@akkartik.com wrote: b) Should we really have to insert a backslash in empty lines? The use case is when you .. you copy-paste a file's contents into the REPL. a) In practice top-level forms tend to be separated by lines anyway in files. Let me clarify: you're editing a function in the file. You're not 100% sure it's correct. The function is a long one, so you put some blank lines between parts of the function to organize it. The function is a single top-level form. You copy-paste the function (not the whole file!!) into the REPL so that you can experiment with it. BOOM! your REPL gets confused by the empty lines inside your function, which it thought was ENTER-ENTER. You are then forced to re-edit the function to insert \ into empty lines to prevent the REPL from confusion. So: using the same reader at REPL and at file is useful for this use case. b) A smart repl could notice when a line is at the same indent as the previous expression, and eval the previous form. It might print things in the wrong place, something like this: + 1 2 . 7 3 7 Here I've colored* what the computer prints grey to distinguish from what the programmer types in. So the '+ 1 2' is evaluated after he's already started typing the next expression (7). I think this is ok. Dwheeler specifically didn't like this IIRC ^^ Let's see what he says. c) If you paste in several forms into the repl at once, you might need to type in an extra Enter like in the example above (the empty line just above 7). I think that's acceptable as well. What do people think? * - With apologies to those who don't see html formatting in their email. Please speak up if there's someone like that. I try to avoid html emails -- until there's a genuine need for extra formatting. -- 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] realistic examples
Kartik Agaram: I fear that 'pressing' might be distorting our sense of the relative frequency of different constructs. SPLIT/SPLICE is for arc's if; there it actually looks good as a separator. I would be less concerned about SPLIT if it's going to be fairly uncommon in other situations. We need *some* sort of GROUP-like symbol (we expect it would be the first symbol on a line) so that we can handle lists-of-lists. You don't need them constantly, but they are really important - I'll argue they are necessary for practical use. The SPLIT semantic is one of several alternatives that enable this. You don't need it all that often, but you really do need it. SPLIT *between* symbols is one of those things that is not needed in many cases, but in those few cases where you want it, you REALLY want it. A key use case is anything that uses keyword arguments, where the keywords are at the same list level as the datum that follows them and there can be multiple keywords. E.G., my-funny-function(:keyword1 100 :keyword2 200 :keyword3 300 :keyword4 400) isn't too bad UNLESS one of the parameters is complex needs to be indented further. Then the obvious way becomes: my-funny-function . :keyword1 . 100 . :keyword2 . 200 . :keyword3 . my-complicated-calculation . . foo . . bar . :keyword4 . 400 Although the above WORKS, it completely obscures the relationship between keywords and their arguments, AND it takes a lot of precious vertical space. With SPLICE, you can do this: my-funny-function . :keyword1 \\ 100 . :keyword2 \\ 200 . :keyword3 . \\ my-complicated-calculation . . foo . . bar . :keyword4 \\ 400 Or even: my-funny-function . :keyword1 \\ 100 \\ :keyword2 \\ 200 . :keyword3 . \\ my-complicated-calculation . . foo . . bar . :keyword4 \\ 400 Another example: I didn't even realize Common lisp permits backslash-escaping in symbols. Eeurgh! But nobody uses it, so it doesn't bother me and I don't have to bother with it. Well, a lot of people use Common Lisp, where it is *required*. In addition, some Schemes implement slashification too. I'm rather curious what Alan Manuel Gloria thinks about my \\ symbol idea, which I believe eliminates the problems from slashification. --- 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] Arne Babenhauserheide proposal: use . on own line instead of group
On 7/19/12, Kartik Agaram a...@akkartik.com wrote: . is just whitespace. Ah, of course :/ I'm having trouble holding that in my head. Getting rid of periods, I'm still having trouble understanding why the second line isn't wrapped in parens in: \ a b c Shouldn't this be ((a (b c)))? Yes it is. But what you were asking was this: \ list-of x list x And it's wrong, because it's parsed as: ( (list-of x (list x))) Because what we wanted was: ( (list-of x) (list x)) That's why we have SPLIT: \ list-of x \ list x Which does that for you magically. -- 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] Arne Babenhauserheide proposal: use . on own line instead of group
Careful, I think there's some missing indentation in these examples, and since we've discussed several alternatives it can get confusing. Let's talk about group as it's currently defined. In that case: group a b . c d = (a b (c d)) But the other example given is actually two separate lists, since they are at the same indentation level: group a b c d = (a b) (c d) --- 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] Arne Babenhauserheide proposal: use . on own line instead of group
- Start Original Message - Sent: Wed, 18 Jul 2012 19:28:34 -0700 From: Kartik Agaram a...@akkartik.com To: Alan Manuel Gloria almkg...@gmail.com Subject: Re: [Readable-discuss] Arne Babenhauserheide proposal: use . on own line instead of group b) Should we really have to insert a backslash in empty lines? The use case is when you .. you copy-paste a file's contents into the REPL. a) In practice top-level forms tend to be separated by lines anyway in files. b) A smart repl could notice when a line is at the same indent as the previous expression, and eval the previous form. It might print things in the wrong place, something like this: + 1 2 . 7 3 7 Here I've colored* what the computer prints grey to distinguish from what the programmer types in. So the '+ 1 2' is evaluated after he's already started typing the next expression (7). I think this is ok. The current parser *does* detect when two lines are at the top level and accept it. In fact, it used to be that blank lines were ignored. I *HATED* it. That kind of interaction is absurdly confusing; nobody expects to type in something and see the results from the input BEFORE that. When you're using a REPL you do NOT need confusing output. This was one of the first things I fixed: Making sure that ENTER ENTER works. There are certainly alternatives, e.g., a symbol that means execute this. Several languages do exactly this. But that gets to a drag interactively; it's hard to beat the speed of ENTER ENTER. You don't need to use \ to make a blank line. A semicolon (possibly indented) will also cause the line to be ignored, and you don't need to match the indentation. This has the disadvantage that in text files, you can't have truly blank lines in the middle of a form, you have to put something (like a semicolon) in. Python solves this by making the interactive syntax DIFFERENT from syntax in code (blank lines end an expression only in interactive mode), but that seems like a bad idea for Lisp. * - With apologies to those who don't see html formatting in their email. Please speak up if there's someone like that. I try to avoid html emails -- until there's a genuine need for extra formatting. Um, me for one :-). --- 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] realistic examples
On 7/19/12, David A. Wheeler dwhee...@dwheeler.com wrote: I'm rather curious what Alan Manuel Gloria thinks about my \\ symbol idea, which I believe eliminates the problems from slashification. I still prefer \, but I won't object to \\. I also won't object to ~ or !. So if I were to rank preferences: \ \\ ~ or ! Other symbols, NO. 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] Arne Babenhauserheide proposal: use . on own line instead of group
Just to confirm, presuming SPLIT semantics (which is what is currently implemented) using \ as the SPLIT symbol: \ a b c Shouldn't this be ((a (b c)))? Yes, indeed, that's right. I think of this as \ starting a list with a 0-length function name. --- 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
[Readable-discuss] Proposal: SUBLIST (not a GROUP replacement)
Just when it's less than 2 weeks to spec freeze I once had to code this expression: force(car(force(unwrap-box(s And it's ugly. I could use I-expressions: force . car . . force . . . unwrap-box s But that wastes precious vertical space. So I propose the SUBLIST semantic. Informally: 1. If the SUBLIST symbol $ is found in the middle of a line, then it is an implied promise to insert a ( at that point with a ) automagically inserted at the end of the block (i.e. before the next line with the same or lesser indent than this one). So: force $ car $ force $ unwrap-box s is equivalent to: (force ( car ( force ( unwrap-box s The only time that the promise will not get used is if there is only a single term after the $: thus: foo $ bar is: (foo bar) ; no ( ) automagically inserted around bar FORMAL Spec: (i-expr lvl) - head hspace+ SUBLIST hspace+ (i-expr lvl) (append $1 (list $5)) 1. SUBLIST considers the rest of the line as a new expression at the same indentation level as the current line. This new expression is then used as the last member of the list being built. -- This syntax reduces the need for foo:bar syntax in Arc, BTW. : is more compact as it needs no space, and it can be used in higher-order functions, but $ is at the reader level, and does not require magic when used in head position (unlike Arc, where officially foo:bar means (compose foo bar) but (foo:bar nitz) really means (foo (bar nitz)) to make macros composable). -- 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
[Readable-discuss] We may have a symbol winner!
On 2012-07-19, David A. Wheeler wrote: I'm rather curious what Alan Manuel Gloria thinks about my \\ symbol idea, which I believe eliminates the problems from slashification. Alan Manuel Gloria replied: I still prefer \, but I won't object to \\. I also won't object to ~ or !. So if I were to rank preferences: \ \\ ~ or ! Other symbols, NO. We may have a winner! I *strongly* object to a bare \ as the split symbol, because it screws up on any system with slashification (all Common Lisps, some Scheme implementations, and probably many others). Other than that, though, I don't care much. I think almkglor's discussion of the visual advantages of various symbols a really interesting analysis, and it suggests that something using backslashes has advantages. So, since almkglor can live with \\, and I *strongly* object to \, I think the best between the two of is \\ for SPLIT, presuming that we implement SPLIT. Based on previous discussions, I think we should implement SPLIT at least. I'm not convinced of the advantages of ENLIST, and almglor was willing to live without it. So here's how I see the discussion shaking up: * SPLIT semantics, using \\ as the SPLIT symbol. It's like GROUP when the first symbol of the line, it represents a null-length function name at that indentation level. Otherwise, it splits datums; the next datum restarts at the current indentation level. * . lives on as indentation, but only when followed by space or tab. --- 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] realistic examples
SPLIT *between* symbols is one of those things that is not needed in many cases, but in those few cases where you want it, you REALLY want it. Absolutely. But if it's an uncommon use case then I'm less concerned about what y'all choose. Unfortunately, Alan's response suggests I'd end up seeing SPLIT between symbols a lot if sweetexprs take off :/ I don't think there's a way to resolve this. Both our styles are internally consistent, but mutually contradictory. (I tend to use dense lines more often than him.) And we're two points on a spectrum that's wider and more well-populated throughout than I realized, even among experienced lispers. I understand now why we need to introduce GROUP, SPLIT, etc. But they're as alien to lisp noobs as parens and prefix. So why bother with sweetexprs? Parens/infix + GROUP/SPLIT seems strictly more cognitive load than just parens/infix. -- 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
[Readable-discuss] SPLIT using \\ now implemented
The current code now implements SPLIT using \\. Please, experiment with it see how it works/looks. --- 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] Proposal: SUBLIST (not a GROUP replacement)
On 7/19/12, David A. Wheeler dwhee...@dwheeler.com wrote:
Alan Manuel Gloria:
Just when it's less than 2 weeks to spec freeze
:-).
I once had to code this expression:
force(car(force(unwrap-box(s
And it's ugly.
I could use I-expressions:
force
. car
. . force
. . . unwrap-box s
But that wastes precious vertical space.
So I propose the SUBLIST semantic.
Hmm. Function composition isn't unknown, of course, but I'm skeptical about
how often this kind of construct occurs. Every new rule has a mental cost;
we need to make sure the cases are so common (or so egregious) that the
construct is worth it. Otherwise, people will reject it as being too
complicated to learn. The wrapped example you show above is actually how
many other languages *would* show it.
I also worry about using up one-character symbols; if we do anything like
this, perhaps a multi-char symbol would do? We could also pick a few
symbols to reserve for cases like this; again, it's not so bad if we
reserve multi-character symbols.
Well, we could define an o-function that does composition:
define o
case-lambda
(f) f
(f g)
lambda parms
f apply(g parms)
(f g . rest)
{{f o g} o apply(o rest)}
Then: {force o car o force o unwrap-box}(s)
(or use * or . or something less egregious than o, now that I look
at it, o looks ugly, eh?)
Of course, the lack of true currying means that a slight variant like:
foo(bar(nitz quux(meow)))
Can't use a compose chain like o above.
foo $ bar nitz $ quux meow
--
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
