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
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
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
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
Earlier I said:
But I think this shouldn't be TOO bad to implement. You're right that if we
use ONLY lookahead we can't do it. but I don't think that should be a
problem. In particular, in our current code, in sugar.scm's function
readblock-internal...
Hmm, that approach might not work,
Alan Manuel Gloria:
4. I can't accept #4 because I'm not assured that it is easy to
implement given a one-character lookahead implementation (Scheme). I
think that it is a significant implementation burden, in order to
support what I consider to be minor advantages.
I just posted an updated
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
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
On Thu, Jul 19, 2012 at 12:12 AM, David A. Wheeler
dwhee...@dwheeler.com wrote:
Alan Manuel Gloria:
4. I can't accept #4 because I'm not assured that it is easy to
implement given a one-character lookahead implementation (Scheme). I
think that it is a significant implementation burden, in
Alan Manuel Gloria 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 \
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
. .
Alan Manuel Gloria:
IIRC some peek-char implementations are just read-char followed by
unread-char, with only one unread-char lookahead: so the sequence of
peek-char followed by unread-char might cause strange errors about too
many unread-char.
Hmm, I'd think of that as a bug.
Generally,
On Thu, Jul 19, 2012 at 6:23 AM, David A. Wheeler dwhee...@dwheeler.com wrote:
Alan Manuel Gloria:
IIRC some peek-char implementations are just read-char followed by
unread-char, with only one unread-char lookahead: so the sequence of
peek-char followed by unread-char might cause strange
Alan Manuel Gloria 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
Alan Manuel Gloria:
I don't see it as having as much utility as drawing horizontal lines
of . in indentation area.
Still, either one will do. The most common use case I see is to draw
vertical lines in the indentation area so I that when I modify the
code, I can get to see where I should
On Thu, Jul 19, 2012 at 2:45 AM, Alpheus Madsen
alpheus.mad...@gmail.com wrote:
Third, I'm not sure I like the idea of using . for indentation. While it
helps to clarify the structure, it can also clutter the visual presentation
of the source code. I like the fact that word processors allows
On 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
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
.
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()
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
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
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:
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
.
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
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
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)?
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?
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
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
\
. 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
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
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.
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
. 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)))?
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:
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.
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
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,
- 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
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
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
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.
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
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
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
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
. . .
46 matches
Mail list logo
