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
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
. .
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
.
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
.
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
\
. 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:
\
. 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:
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
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
OK, I'll summarize.
First, we have a pool of syntax symbols. Let's not fix meanings to
symbols for now:
~
\
.
!
$
%
^
Then we have a bunch of concrete proposals:
1. almkglor:
Don't use GROUP
Don't use SPLICE
Use SPLIT
Use ENLIST
Use 2 symbols from our pool of syntax symbols. Current
a
.
b → do a double bracket
. b → pure syntactic sugar to give the code a stronger structure.
a
SPLIT
b = (a (b))
SPLIT b = b
What isn't compatible is:
a . b → construct a cons-cel
since:
a SPLIT b
is two expressions, a followed by b
Instead, your
Uhm. What you call GRIT *is* SPLIT.
Ugh, I'm an idiot. That's what I get for trying to come up with new approaches
on-the-keyboard. I tried some alternative ways of combining things, kept
fiddling, and ended up circling back :-).
That said, I think my alternative rule for
Hi Alan,
At Wed, 11 Jul 2012 17:28:43 +0800,
Alan Manuel Gloria wrote:
All right all right, let's use this thread to discuss GROUP, SPLICE,
SPLIT, and ENLIST.
Let's call this DEBATE POINT 1, for reasons that are not readily apparent.
I tried to follow your reasoning, but I did not get a
Alan Manuel Gloria almkg...@gmail.com:
Hence my continued position: SPLIT (to support :keyword-style
juxtaposition pairings) and ENLIST (to support (k v)-style explicit
pairings), using two different symbols.
You can drop ENLIST, maybe, because SPLIT-by-itself can do part of its
work, at
On 7/13/12, David A. Wheeler dwhee...@dwheeler.com wrote:
Alan Manuel Gloria almkg...@gmail.com:
Hence my continued position: SPLIT (to support :keyword-style
juxtaposition pairings) and ENLIST (to support (k v)-style explicit
pairings), using two different symbols.
You can drop ENLIST,
Alan Manuel Gloria:
All right all right, let's use this thread to discuss GROUP, SPLICE,
SPLIT, and ENLIST.
Agree.
By the way, thanks very much for creating this summary on the mailing list +
the info on the Wiki. Nicely done + very helpful.
...
1. NO to GROUP and SPLICE
2. YES to
On 7/9/12, David A. Wheeler dwhee...@dwheeler.com wrote:
The special chars that look most promising to me as single chars:
\ = often means continue on next line when at eol in other languages
This is one I've been using, and as noted earlier, it already has a meaning
to many readers.
~ =
2.3 remove SPLICE inline rule
That may be NG. The reason for the SPLICE-at-the-start and
SPLICE-inline rules is to support the following Arc syntax, and CL keywords:
(if
(cond1)
(exp1)
(cond2)
(exp2)
(exp-else))
(foo
:foo-stuff (exp1)
:bar-stuff (exp2))
Right.
Do be aware that the \ splice thing is not yet officially part of
sweet-expressions; dwheeler made a draft of the splice rules but hasn't
made a 0.3 sweet-expressions spec including it.
Do you mean the one here?
- http://www.dwheeler.com/readable/sweet-expressions.html
- If it's the last
First of all, I''m delighted to see this discussion! I'll look over Alan
Manuel Gloria's parser proposal more carefully soon.
Do be aware that the \ splice thing is not yet officially part of
sweet-expressions; dwheeler made a draft of the splice rules but hasn't
made a 0.3 sweet-expressions
27 matches
Mail list logo
