> define-syntax list-of
> syntax-rules (is in)
> ; base case
> \
> . list-of x
> . \ list x
> ; handle (var in x) clause
BTW, another option to consider: explicitly avoid the case of macros.
In wart I have no way to state quasiquote without parens. I figure the
point of s-exp
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. Wheele
- Start Original Message -
Sent: Wed, 18 Jul 2012 19:28:34 -0700
From: Kartik Agaram
To: Alan Manuel Gloria
Subject: Re: [Readable-discuss] Arne Babenhauserheide proposal: use "." on own
line instead of "group"
>
> > > b) Should we really have to i
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
On 7/19/12, Kartik Agaram 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)))?
On 7/19/12, Kartik Agaram 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 edit
> "." 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 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
On 7/19/12, Kartik Agaram 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
> 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))?
--
Liv
> \
> . 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
> > 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
On 7/19/12, Kartik Agaram 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
> 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)
> . . lis
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
> 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 ma
Kartik Agaram:
> I've been falling behind as well. I wanted to see if time would reduce
> my dislike for GROUP, but that doesn't seem to be happening. Indeed, I
> can't even bring myself to do more than skim the discussions about it.
> I've struggled to understand/articulate why this is to myself
Alpheus Madsen:
> 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 n
Hmm, a new fly in the ointment for \-as-symbol. I've found that using symbol \
as SPLIT/GROUP symbol has an implementation complication for anyone who also
wants to support slashification inside (...). And I expect some reader
implementations *will* want to slashification, at least inside (...
>
> Is 'group' really going to be easier to understand than enabling
> whitespace-sensitivity inside parens? I think that's a good test if
> we've decided the latter is too complex.
>
> Also, using backslash for any meaning is butt ugly.
>
I don't completely agree with your sentiments; in part, be
I've been falling behind as well. I wanted to see if time would reduce
my dislike for GROUP, but that doesn't seem to be happening. Indeed, I
can't even bring myself to do more than skim the discussions about it.
I've struggled to understand/articulate why this is to myself, and
mostly failed. The
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 cur
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 cur
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,
In the thread: "Proposal: Let's reserve some symbols "for future
syntactic purposes" in 0.3":
On 7/14/12, David A. Wheeler wrote:
>
> Although I think I'm the one who started using "\" for SPLIT, I'm
> increasingly thinking it's a bad symbol choice. The Common Lisp spec uses
> that as an escape
Alan Manuel Gloria:
> OK, I'll summarize...
I think that's a great summary. I put it into [Current], too.
--- David A. Wheeler
===
>
> First, we have a pool of syntax symbols. Let's not fix meanings to
> symbols for now:
>
> ~
> \
> .
> !
> $
> %
> ^
>
> Then we hav
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 propos
> > 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 b
On 7/13/12, David A. Wheeler wrote:
> Alan Manuel Gloria :
>> 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 ca
Alan Manuel Gloria :
> 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 the cost of add
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
At Mon, 9 Jul 2012 06:20:00 +0800,
Alan Manuel Gloria wrote:
>
> On Mon, Jul 9, 2012 at 3:17 AM, David A. Wheeler
> wrote:
> > I think we need to seriously discuss all the splicing/grouping/etc. stuff.
> > Those decisions will affect everything else, and there are complex
> > trade-offs. One
> 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 SYMBOL-at-beginn
On 7/12/12, David A. Wheeler wrote:
> 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.
>
- Start Original Message -
Sent: Wed, 11 Jul 2012 21:51:17 -0400 (EDT)
From: "David A. Wheeler"
To: almkg...@gmail.com
Subject: Re: [Readable-discuss] Arne Babenhauserheide proposal: use "." on
own line instead of "group"
> Alan Manuel Gloria:
> &
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
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.
GROUP - the original SRFI-49 rule. The GROUP marker is "invisible"
when at the start of the line, and is removed, except for its effe
On 7/9/12, David A. Wheeler 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.
>
>> ~ = mostly unused e
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.
> ~ = mostly unused except in Arc, where ~foo means "the function
On Mon, Jul 9, 2012 at 3:17 AM, David A. Wheeler wrote:
> I think we need to seriously discuss all the splicing/grouping/etc. stuff.
> Those decisions will affect everything else, and there are complex
> trade-offs. One challenge is that practically any character or character
> pair seems to
I think we need to seriously discuss all the splicing/grouping/etc. stuff.
Those decisions will affect everything else, and there are complex trade-offs.
One challenge is that practically any character or character pair seems to be
already used by someone.
> proposal 3:
>
> 3. . = SPLICE =
On 7/5/12, Alan Manuel Gloria wrote:
> existing meaning in other languages, we avoid it. Incidentally, "."
> has a meaning in general western written languages: it ends sentences.
Hmm.
%s/SPLICE/END/g
%s/GROUP/END/g
END = .
---
The "END" rule, in words:
1. Outside of an explicitly delimite
proposal 3:
3. . = SPLICE = GROUP, remove SPLICE-at-the-eol rule (this helps
justify removing the SPLICE-at-the-eol: since \ at the eol has an
existing meaning in other languages, we avoid it. Incidentally, "."
has a meaning in general western written languages: it ends sentences.
So we could j
On Wed, Jul 4, 2012 at 5:35 AM, Arne Babenhauserheide wrote:
> Hi David,
>
>> I can be talked either way about the \ splice thing. The goal is to make
>> "easy things easy", without too many rules. Is the extra "\" rule helpful?
>> Neutral? More harm than good? I'd love to hear more feedbac
Hi David,
> I can be talked either way about the \ splice thing. The goal is to make
> "easy things easy", without too many rules. Is the extra "\" rule helpful?
> Neutral? More harm than good? I'd love to hear more feedback on it.
Personally I think that the inline \ makes it too complex.
On Mon, Jul 2, 2012 at 12:38 AM, David A. Wheeler wrote:
>> 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)
>
> 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 (e
On Sun, Jul 1, 2012 at 2:24 AM, Arne Babenhauserheide wrote:
> > 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:
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 s
> 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
On Sat, Jun 30, 2012 at 9:06 PM, Arne Babenhauserheide wrote:
> Hm, I did not even know about the splice rule.
>
> So, if it’s already necessary for syntax, \ would indeed be equivalent.
>
> I’m just used to using it for escaping special characters, so it seems
> odd to me to see it on a line on i
Hm, I did not even know about the splice rule.
So, if it’s already necessary for syntax, \ would indeed be equivalent.
I’m just used to using it for escaping special characters, so it seems
odd to me to see it on a line on its own :)
Best wishes,
Arne
---
dwheeler mentioned the use of "\" for the GROUP character. It happens to
be the same as the SPLICE character. My initial instinct is that this is a
non-breaking change, i.e. using the same character for both will not break
things, as long as we remove the SPLICE-at-the-eol rule (i.e. only allow
S
Hi,
At Wed, 23 May 2012 12:54:18 -0400 (EDT),
David A Wheeler wrote:
>
> Alpheus Madsen
> > One thought I've been wanting to experiment with, but haven't had the time
> > to attempt to implement, is to use a double-indent to indicate groups.
>
> I think that's even worse. It's very unreadable
On Wed, May 23, 2012 at 9:54 AM, David A. Wheeler wrote:
> Alpheus Madsen
> > This is a problem I've thought about myself. I'm not sure if I like
> Arne's solution, though, because a period is almost too small, but I would
> agree that group is rather clunky too.
>
> Agree.
>
> > One thought I'v
Alpheus Madsen
> This is a problem I've thought about myself. I'm not sure if I like Arne's
> solution, though, because a period is almost too small, but I would agree
> that group is rather clunky too.
Agree.
> One thought I've been wanting to experiment with, but haven't had the time to
>
This is a problem I've thought about myself. I'm not sure if I like Arne's
solution, though, because a period is almost too small, but I would agree
that group is rather clunky too.
One thought I've been wanting to experiment with, but haven't had the time
to attempt to implement, is to use a dou
57 matches
Mail list logo
