On 7/20/12, David A. Wheeler wrote:
> On Fri, 20 Jul 2012 00:37:57 +0800, from Alan Manuel Gloria:
>> bundle bundle!
>
> Awesome. Reviewed, accepted, pushed.
>
> More tests == more goodness, and I am *REALLY* glad to be rid of the ugly
> function clean(). I'm sure more code cleanups would help,
So, basically: ENLIST does not treat its RHS as a new line expression,
unlike QUOTE et al., SPLIT, or GROUP, i.e. it won't somehow recurse
into readblock-internal.
ENLIST treats its RHS specially, and if the next line is indented,
also treats that specially.
If ENLIST treated its RHS as an expres
On 7/20/12, David A. Wheeler wrote:
> Alan Manuel Gloria:
>> >> 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
I asked:
> > What would be the best symbol, if implemented? $, $$, ~, something else?
Kartik Agaram replied:
> It looks a lot like haskell's $.
I don't think that's accidental :-).
Amusingly, our spec notation also uses $ currently ($1, $2, etc.). But we
could disambiguate or change.
--- Dav
I said:
> Semantics could be, where $$ is the SUBLIST==ENLIST separator, that given:
> EXPR1 $$ EXPR2
> It maps to:
> (EXPR1 EXPR2)
> I.E., it becomes cons(EXPR1 EXPR2).
>
> where either EXPR1 and EXPR2 can be empty, and EXPR2 can span lines. The
> beginning of EXPR1 is the end of this l
Alan Manuel Gloria:
> >> 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 p
So a new top-level form is detected either with left edge unindent or with
an empty line.
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed a
> *interactive* use becomes fundamentally different than *non interactive*
use.
You could read all in non interactive mode and keep the empty line rule.
Would they diverge in that case?
On Jul 19, 2012 6:24 PM, "David A. Wheeler" wrote:
> Kartik Agaram:
> > One option -- in case y'all haven't al
Kartik Agaram:
> One option -- in case y'all haven't already considered it -- is to
> perform non-interactive translation using a read-all, rather than
> read. Wart did this for a long time.
That's certainly possible, and it would also allow blank lines to NOT terminate
expressions in files.
The
On Fri, Jul 20, 2012 at 12:03 AM, Alpheus Madsen
wrote:
>> Certainly using "--|" is very heavy, but the point of using . is that it
>> is much lighter visually.
>
>
> Just for clarification: I've never used "--|" in a language as "official"
> syntax; I've used it (and variations of it) in Python
> First read(): Reads foo, bar, and it consumes the indentation of "eggs" so
> that it can determine that another is at the same level. It returns (foo
> bar).
Ah yes, this bug actually took me *forever* to understand in wart :)
This also helps me understand the other discussions here about
unr
I just added a whole bunch of test cases for the current sweet-expression
reader, and the reader seems to be working very well with the new semantics.
I hope that we can reduce the code's complexity - I'd like the reader code to
be "obviously right". Alan Manuel Gloria has been making great str
Kartik Agaram:
> Why do we care where the 'left edge' is?
As you know, you need to know where an expression indents, and where it ends.
If you read in a line, and it has the same indentation level, that should end
the previous expression. If its indentation is *less*, it should close out all
> 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
> It looks at the port... and sees a space!! Oh noes!! Someone has
> just indented the first line! Okay, let's count the first line's
> indent... two spaces. Let's pretend that this is the 'left edge'..
> let's go to the next line... oh noes! It's got one space for indent -
> it's managed to go
> How do we express the usage of [such macros] using the Unified Syntax for
> Indented Lisp?
I'm hoping that if the unified syntax takes hold then people will tend
to just define their own macros differently.
There's the obvious workarounds, of course, like defining my-and-let*
that massages thin
On Fri, 20 Jul 2012 00:37:57 +0800, from Alan Manuel Gloria:
> bundle bundle!
Awesome. Reviewed, accepted, pushed.
More tests == more goodness, and I am *REALLY* glad to be rid of the ugly
function clean(). I'm sure more code cleanups would help, but that's a big
step forward.
And speaking o
bundle bundle!
2012-07-20-almkglor.bundle
Description: Binary data
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers ca
>
> Certainly using "--|" is very heavy, but the point of using . is that it
> is much lighter visually.
>
Just for clarification: I've never used "--|" in a language as "official"
syntax; I've used it (and variations of it) in Python and PHP when I really
needed to see the structure.
Come to th
On 7/19/12, Kartik Agaram wrote:
>> There have been dozens of Lisp-based programming languages that started
>> with that premise, starting with McCarthy's M-expressions.
>
> But I think my proposal hasn't been tried before: a single consistent
> set of primitives that map 1-1 to various lisp diale
> There have been dozens of Lisp-based programming languages that started with
> that premise, starting with McCarthy's M-expressions.
But I think my proposal hasn't been tried before: a single consistent
set of primitives that map 1-1 to various lisp dialects.
You wouldn't be able to translate
Alan Manuel Gloria:
> Wouldn't this be better? AFAIK list? implies pair?
Well yes, list? implies pair?, but I was thinking about performance. After
all, list? has to walk all the cons pairs' cdrs, while pair?() just has to look
at one pair. Typically lists aren't that long, but they could be,
Kartik Agaram:
> I'll investigate ENLIST further. But I'm skeptical that the answer is
> an additional syntax character. The problem is _not_ some lack of
> functionality. The problem, IMO, is that y'all are trying to do too
> much. You're trying to satisfy too many different camps of users, and
>
But if you seriously drop the parns, it'd look like this!!
o^.^oo^.^o
So you can't see where they're facing anymore!
On 7/19/12, Kartik Agaram wrote:
>> This was intended to be a joke v(^^)v o(^.^o)(o^.^)o
>
> Yeah I saw that, but I wanted to see how ha-ha-only-serious it was :)
>
> This was intended to be a joke v(^^)v o(^.^o)(o^.^)o
Yeah I saw that, but I wanted to see how ha-ha-only-serious it was :)
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's securit
Wouldn't this be better? AFAIK list? implies pair?
define represent-as-infix?(x)
. and
. . list? x
. . symbol? car(x)
. . memq car(x) infix-operators
. . {length(x) >= 3}
. . {length(x) <= 6}
Yeah looks purty.
On 7/19/12, David A. Wheeler wrote:
> When writing iformat.sscm, I'm using sweet-exp
On 7/19/12, Kartik Agaram wrote:
>> There's no need to completely dismiss sweet-expressions just because
>> you see SPLIT winning and dislike the consensus of the symbol being
>> used.
>
> No, that isn't what I said. I articulated doubts that sweetexprs could
> be relevant, not because it doesn't
27 matches
Mail list logo
