Re: [Readable-discuss] Spliced information - any better ideas?
I've tried to write the potential rules for "\ " more clearly, yet simply. They are here: http://www.dwheeler.com/readable/version02.html#backslash-operator Current text: When doing indentation processing, if the first character of a form is "\" followed by whitespace: * If it's the last character of the line (other than 0 or more spaces/tabs), then the newline is considered a space, and the next line's indentation is irrelevant. This continues the line. (Note that comments cannot follow, because that would be confusing.) * If it's between items on a line, it's interpreted as a line break to the same indentation level. * Otherwise, if it's at the beginning of a line (after 0+ spaces/tabs), it's ignored - but the first non-whitespace character's indentation level is used. I'm really beginning to warm to this one. Most of the time you don't need it, but there are definitely some common use cases where it's helpful. And if you don't use it, it doesn't make things harder. Also, I think I should modify the interpretation of unprefixed [...]. Basically, unprefixed [...] should mean "whatever they mean to the underlying Lisp". For Scheme, [...] should be the same as (...) because that's what they mean in R6. That'll make sweet-expressions easier to use with Arc and other Lisps that define [...] differently. I'll probably keep prefixed [...] with its (bracketaccess ...) meaning simply because it's impractical to "add" anything later, but it's not significantly used. In any case, indentation processing is disabled inside [...]. --- David A. Wheeler - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] Spliced information - any better ideas?
Alan Manuel Gloria: > Hmm. > if > aprim ast \ expand-prim ast > acond ast \ expand-cond ast > \ do > zap [map expansion _] ast!subx > ast > > Not bad. Thanks! You'll need to indent it. I'm guessing you meant something like this: if aprim ast \ expand-prim ast acond ast \ expand-cond ast \ do zap [map expansion _] ast!subx ast Hmm, the more I look at it, the more it makes sense. I think the rule description is over-complicated; the rule is simpler than I how I wrote it. And maybe this IS worth figuring out. Basically, this rule lets you show (through formatting) when pairs of forms are interrelated, yet aren't actually inside a larger list. As happens in any Lisp that uses ":param-name value", as well as in formats like Arc's Lisp. --- David A. Wheeler - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] Spliced information - any better ideas?
On Fri, Nov 14, 2008 at 7:14 AM, David A. Wheeler <[EMAIL PROTECTED]>wrote:
> Alan Manuel Gloria asked:
> > How about the cond-style if of Arc?
> > (if
> > (condition1)
> > (dothis1)
> > (condition2)
> > (dothis2)
> > (default))
> ...
> > if
> > (condition1)
> > -> (dothis1)
> > (condition2)
> > -> (dothis2)
> > -> (default)
>
> I presume the intent is that "->" at the beginning
> of a line is ignored. Is that what you mean??
> I'll comment based on that possibly wrong assumption,
> please correct me if that wasn't intended.
>
> That _looks_ nice, but two issues:
> 1. That rule would make "->" unusable, which in many apps is really
> important.
> A less-common symbol could work, though, such as "\ ".
True. \ does look nice.
- Show quoted text -
>
> 2. For short pairs that's really awkward. You still have to use 2 lines
> to provide information that in traditional Lisp notation only requires
> one line. For attribute-value pairs that's really important.
>
> For example, given the SMT-LIB example:
> (benchmark bignum
> :source "SMT-COMP'06 Organizers"
> :notes "This benchmark is designed to check if the DP supports
> bignumbers."
> :status sat
> :difficulty "0"
> :category "check"
> :logic QF_RDL
> :extrafuns ((x1 Real))
> :extrafuns ((x2 Real))
> :extrafuns ((x3 Real))
> :extrafuns ((x4 Real))
> :formula
> (and (<= (- x1 x2) (/ 1 10))
> (<= (- x2 x3) (/ 1 200011))
> (<= (- x3 x4) (~ (/ 1 10)))
> (<= (- x4 x1) (~ (/ 1 200012)
>
>
> The simple rule "-> ignored at beginning of line" could be used, but that
> would produce:
> benchmark bignum
> :source
> -> "SMT-COMP'06 Organizers"
> :notes
> -> "This benchmark is designed to check if the DP supports bignumbers."
> :status
> -> sat
> :difficulty
> -> "0"
> :category
> -> "check"
> :logic
> -> QF_RDL
> :extrafuns
> -> ((x1 Real))
> :extrafuns
> -> ((x2 Real))
> :extrafuns
> -> ((x3 Real))
> :extrafuns
> -> ((x4 Real))
> :formula
> -> and { {x1 - x2} <= {1 / 10} }
>{ {x2 - x3} <= {1 / 200011} }
>{ {x3 - x4} <= ~({1 / 10}) }
>{ {x4 - x1} <= ~({1 / 200012})}
> )
>
> Yuk. Vertical space is precious; most screens have less vertical than
> horizontal space.
>
> I think we must NOT use "->" as the symbol, anyway.
> So how about "\ " (backslash followed by space)
> as the special symbol? That's rather improbable outside a
> string element; how many times do you need a symbol beginning
> with space or newline?
>
> So here's another rule idea, inspired by that approach.
> When doing indentation processing:
> 1. A "\ " at the beginning of the line (after whitespace) is ignored
> (recursively, so you can have several if you want them).
> 2. INSIDE a line, "\ " means "treat this as a line break,
> with the next line beginning at this same indentation level".
> 3. At the END of a line, "\" means "ignore the newline"; it
> basically merges the line with the next one & ignores indentation.
>
> If we do that, we can write:
>
> ; When condition1, dothis1, etc. are lengthy, you can do this:
> if
> (condition1)
> \ (dothis1)
> (condition2)
> \ (dothis2)
> (default)
>
> ; When condition1, dothis1, etc. are short, you can do this:
> if
> (condition1) \ (dothis1)
> (condition2) \ (dothis2)
> (default)
>
> benchmark bignum
> :source \ "SMT-COMP'06 Organizers"
> :notes \ "This benchmark is designed to check if the DP supports
> bignumbers."
> :status \ sat
> :difficulty \ "0"
> :category \ "check"
> :logic \ QF_RDL
> :extrafuns \ ((x1 Real))
> :extrafuns \ ((x2 Real))
> :extrafuns \ ((x3 Real))
> :extrafuns \ ((x4 Real))
> :formula
> \ and { {x1 - x2} <= {1 / 10} }
> { {x2 - x3} <= {1 / 200011} }
> { {x3 - x4} <= ~({1 / 10}) }
> { {x4 - x1} <= ~({1 / 200012})} )
>
> ; or alternatively:
> benchmark bignum \
> :source "SMT-COMP'06 Organizers" \
> :notes "This benchmark is designed to check if the DP supports
> bignumbers." \
> :status sat \
> :difficulty "0" \
> :category "check" \
> :logic QF_RDL \
> :extrafuns ((x1 Real)) \
> :extrafuns ((x2 Real)) \
> :extrafuns ((x3 Real)) \
> :extrafuns ((x4 Real)) \
> :formula \
> and { {x1 - x2} <= {1 / 10} }
> { {x2 - x3} <= {1 / 200011} }
> { {x3 - x4} <= ~({1 / 10}) }
> { {x4 - x1} <= ~({1 / 200012})} )
>
> ; If you reorder the ":formula" entry you can see why just the "\ at the
> end"
> ; doesn't completely solve the problem. You can't really do that here:
> benchmark big
Re: [Readable-discuss] Spliced information - any better ideas?
I said: > So here's another rule idea, inspired by that approach. > When doing indentation processing: > 1. A "\ " at the beginning of the line (after whitespace) is ignored > (recursively, so you can have several if you want them). > 2. INSIDE a line, "\ " means "treat this as a line break, > with the next line beginning at this same indentation level". > 3. At the END of a line, "\" means "ignore the newline"; it > basically merges the line with the next one & ignores indentation. I just realized that this has a nice side-effect; you can create single-line sequences when they make sense. E.G.: define showstats() write a \ write b \ write c Is the same as: define showstats() write a write b write c Which is the same as: (define (showstats) (write a) (write b) (write c)) Hmm, that's convenient. It's a lot like ";" as a statement terminator or separator in ALGOL-descended languages (like C and Pascal). Useful when you have highly related sets of short statements. --- David A. Wheeler - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] Spliced information - any better ideas?
Alan Manuel Gloria asked:
> How about the cond-style if of Arc?
> (if
> (condition1)
> (dothis1)
> (condition2)
> (dothis2)
> (default))
...
> if
> (condition1)
> -> (dothis1)
> (condition2)
> -> (dothis2)
> -> (default)
I presume the intent is that "->" at the beginning
of a line is ignored. Is that what you mean??
I'll comment based on that possibly wrong assumption,
please correct me if that wasn't intended.
That _looks_ nice, but two issues:
1. That rule would make "->" unusable, which in many apps is really important.
A less-common symbol could work, though, such as "\ ".
2. For short pairs that's really awkward. You still have to use 2 lines
to provide information that in traditional Lisp notation only requires
one line. For attribute-value pairs that's really important.
For example, given the SMT-LIB example:
(benchmark bignum
:source "SMT-COMP'06 Organizers"
:notes "This benchmark is designed to check if the DP supports bignumbers."
:status sat
:difficulty "0"
:category "check"
:logic QF_RDL
:extrafuns ((x1 Real))
:extrafuns ((x2 Real))
:extrafuns ((x3 Real))
:extrafuns ((x4 Real))
:formula
(and (<= (- x1 x2) (/ 1 10))
(<= (- x2 x3) (/ 1 200011))
(<= (- x3 x4) (~ (/ 1 10)))
(<= (- x4 x1) (~ (/ 1 200012)
The simple rule "-> ignored at beginning of line" could be used, but that would
produce:
benchmark bignum
:source
-> "SMT-COMP'06 Organizers"
:notes
-> "This benchmark is designed to check if the DP supports bignumbers."
:status
-> sat
:difficulty
-> "0"
:category
-> "check"
:logic
-> QF_RDL
:extrafuns
-> ((x1 Real))
:extrafuns
-> ((x2 Real))
:extrafuns
-> ((x3 Real))
:extrafuns
-> ((x4 Real))
:formula
-> and { {x1 - x2} <= {1 / 10} }
{ {x2 - x3} <= {1 / 200011} }
{ {x3 - x4} <= ~({1 / 10}) }
{ {x4 - x1} <= ~({1 / 200012})} )
Yuk. Vertical space is precious; most screens have less vertical than
horizontal space.
I think we must NOT use "->" as the symbol, anyway.
So how about "\ " (backslash followed by space)
as the special symbol? That's rather improbable outside a
string element; how many times do you need a symbol beginning
with space or newline?
So here's another rule idea, inspired by that approach.
When doing indentation processing:
1. A "\ " at the beginning of the line (after whitespace) is ignored
(recursively, so you can have several if you want them).
2. INSIDE a line, "\ " means "treat this as a line break,
with the next line beginning at this same indentation level".
3. At the END of a line, "\" means "ignore the newline"; it
basically merges the line with the next one & ignores indentation.
If we do that, we can write:
; When condition1, dothis1, etc. are lengthy, you can do this:
if
(condition1)
\ (dothis1)
(condition2)
\ (dothis2)
(default)
; When condition1, dothis1, etc. are short, you can do this:
if
(condition1) \ (dothis1)
(condition2) \ (dothis2)
(default)
benchmark bignum
:source \ "SMT-COMP'06 Organizers"
:notes \ "This benchmark is designed to check if the DP supports bignumbers."
:status \ sat
:difficulty \ "0"
:category \ "check"
:logic \ QF_RDL
:extrafuns \ ((x1 Real))
:extrafuns \ ((x2 Real))
:extrafuns \ ((x3 Real))
:extrafuns \ ((x4 Real))
:formula
\ and { {x1 - x2} <= {1 / 10} }
{ {x2 - x3} <= {1 / 200011} }
{ {x3 - x4} <= ~({1 / 10}) }
{ {x4 - x1} <= ~({1 / 200012})} )
; or alternatively:
benchmark bignum \
:source "SMT-COMP'06 Organizers" \
:notes "This benchmark is designed to check if the DP supports bignumbers." \
:status sat \
:difficulty "0" \
:category "check" \
:logic QF_RDL \
:extrafuns ((x1 Real)) \
:extrafuns ((x2 Real)) \
:extrafuns ((x3 Real)) \
:extrafuns ((x4 Real)) \
:formula \
and { {x1 - x2} <= {1 / 10} }
{ {x2 - x3} <= {1 / 200011} }
{ {x3 - x4} <= ~({1 / 10}) }
{ {x4 - x1} <= ~({1 / 200012})} )
; If you reorder the ":formula" entry you can see why just the "\ at the end"
; doesn't completely solve the problem. You can't really do that here:
benchmark bignum
:logic \ QF_RDL
:formula
\ and { {x1 - x2} <= {1 / 10} }
{ {x2 - x3} <= {1 / 200011} }
{ {x3 - x4} <= ~({1 / 10}) }
{ {x4 - x1} <= ~({1 / 200012})} )
:source \ "SMT-COMP'06 Organizers"
Re: [Readable-discuss] Spliced information - any better ideas?
On Thu, Nov 13, 2008 at 8:20 AM, David A. Wheeler <[EMAIL PROTECTED]>wrote: > Alan Manuel Gloria asked: > > > How about the cond-style if of Arc? > > > (if > > > (condition1) > > > (dothis1) > > > (condition2) > > > (dothis2) > > > (default)) if (condition1) -> (dothis1) (condition2) -> (dothis2) -> (default) ? Sincerely, AmkG - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
[Readable-discuss] Spliced information - any better ideas?
Alan Manuel Gloria asked: > > How about the cond-style if of Arc? > > (if > > (condition1) > > (dothis1) > > (condition2) > > (dothis2) > > (default)) Sweet-expressions _can_ handle this, in several ways, but I agree that they aren't optimal. The format doesn't help show "hidden" pairings inside a list. Clearly, it'd be possible to add or modify syntax to better handle cases where you'd like multiple lines to be spliced together to permit "hidden" structures inside a list of items. Both Arc and SMT-LIB show cases where you'd like to have spliced pairs (e.g., condition/result or attribute_name/values). But any such mechanism would need to be simple. Allowing "\" at the end of the line to mean "continue line" is at least simple. That wouldn't cover all use cases, though. A problem with the simple "splice line" approach is that it doesn't handle spliced-in pairs where at least one of the pairs is so complex that you'd like to keep using normal indentation processing inside them. But I haven't been able to think of a syntax that neatly handles this case, and is simple enough to be worth the trouble. This message has 3 ideas (below) - maybe someone here can think of something better? Let's start with 2 concrete cases, based on Arc's "if" and SMT-LIB's labelled-parameters (which are quite similar to Common Lisps's, so the latter is hardly an unknown case): (if a (b (xxx yyy zzz) (xxx yyy zzz)) c d (e (xxx yyy zzz) (xxx yyy zzz)) (f (xxx yyy zzz) (xxx yyy zzz)) g h i) (f :parameter1 value-for-1-that-is-really-long :parameter2 (xxx yyy zzz (q r z)) :parameter3 value-for-3-that-is-really-long) First, the "obvious" representation in sweet-expressions is: if a b xxx yyy zzz xxx yyy zzz c d e xxx yyy zzz xxx yyy zzz f xxx yyy zzz xxx yyy zzz g h i f(:parameter1 value-for-1-that-is-really-long :parameter2 xxx(yyy zzz q(r z)) :parameter3 value-for-3-that-is-really-long) Notice that on the "if", the format does not even HINT that there is a pairing, e.g., for g and h. Also, in "parameter2"'s value we can't use indentation any more to express structure... we're back to parens. So we can use (...) to disable indentation processing, but then we completely lose indentation processing inside it. Adding support for "\" to disable indentation processing can help the attributename-value stuff, as long as it's short, but otherwise it doesn't help much in these examples (I CHOSE these examples to thwart this idea, so that's expected): if a b xxx yyy zzz xxx yyy zzz c \ d e xxx yyy zzz xxx yyy zzz f xxx yyy zzz xxx yyy zzz g \ h i f(:parameter1 value-for-1-that-is-really-long \ :parameter2 xxx(yyy zzz q(r z)) \ :parameter3 value-for-3-that-is-really-long) Here are three approaches, all of which are bad :-). APPROACH 1: One approach would be to add some sort of "splicing" operator for lines, when performing indentation processing. There's precedence in Lisp for this, of course; "," typically inserts the value into a list, but ",@" splices it in. So it's understandable that there might need to be some sort of 'splicing' operator. Let's call it "@@", though "splice", "ungroup" (opposite of "group"), or other names are possible. Basically, this operator would cause the line to be spliced into its parent, INSTEAD of becoming a new sublist. If there are children, then presumably they are children of the last-named expression. E.G., perhaps something like this: if @@ a b xxx yyy zzz xxx yyy zzz @@ c d e xxx yyy zzz xxx yyy zzz f xxx yyy zzz xxx yyy zzz @@ g h i f(:parameter1 value-for-1-that-is-really-long @@ :parameter2 xxx yyy zzz q(r z) @@ :parameter3 value-for-3-that-is-really-long) This would mean that: if @@ a b 1 2 3 @@ c 4 5 6 @@d 7 8 9 @@ e Would become (if a (b 1 2 3) (c 4 5 6) Right now, I think that such a "splicing" operator would be WAY too complicated. But maybe someone can come up with a variant that is simpler to understand (or, convince everyone that it's not so bad). APPROACH 2: Maybe what's needed is an infix "splicing" operator that you place BETWEEN items, saying that these items will be spliced into the larger list enclosing them (instead of creating their own list). You'll need a way to escape this (ugh), but ignoring that problem, let's see how that looks (if "@@" is used with nothing before it, it's ignored): if a @@ b xxx yyy zzz xxx yyy zzz c @@ d e xxx yyy zzz xxx yyy zzz
