Wcp Ess Expressions

Costin's conjecture: wikis badly need structured data.

WikiChangeProposal is initially targeted to geeks who think that XmlSucks and XmlIsaPoorCopyOfEssExpressions and so on, so forth, but hardly do anything about it so the market is left to Microsoft, Sun and Apache XML pars. On the other hand I found myself hating the situation where somebody would force me to type XML in a edit box. I could have used one of the many high quality Scheme implementation for Java, but ended up writing my own S-Expression parser for a particular syntax, partly because of the challenge and hubris involved, and partly because I thought I needed a few extra-features and I had prototyped something on another of my pet projects.

I think it was a good design decision to use s-expressions because I now find myself adding any kind of feature in no time.

So here's the basic syntax for S-Expression:

Simple data types: currently atoms (symbols), strings, and numbers as in scheme/lisp
- Atoms anything that starts with an identifier character (all the ASCII 127 alphabet except the non-printable, white spaces and the special characters like " .
- Numbers anything that can be parsed as a number. (including the 1.23E-127 scientific notation)
- Strings. In several flavors.
  - Traditional Lisp/Scheme "this is a string" with Java/C style escaping (\n \r \uXXXX for an unicode character)
  - For use in wikis, if you need to write a hole damn paragraph it is bothersome to escape so there's Unix shell-like escaping mechanism for big string input (terminator is a place holder for any end of input delimiting word the user sees fit, traditionally EOF is used):

#<< TERMINATOR all kinds of things go here until the terminating word is recognized after a new line TERMINATOR

Booleans as in Scheme: #t and #f
Characters as in Scheme 'a'
byte-arrays as in Rivest's proposal [1]
Lists and conses Scheme LISP style
- ( a . b ) is a pair (cons) containing the symbols a and b
- ( a b ) is a list with the symbols a and b and lists are NIL terminated
- () the empty list (which is the same as NIL)
- ( a b c . d ) is a pair (cons) containing the list (a b c) and the symbol d - thus it will be not be nil terminated and will not be the same as (a b c d), but ( a b c d ) is the same as (a b c d . ()) and the same as (a b c . (d))

What I've been contemplating lately is to introduce a syntax for shortcutting the clsing of paranthesis. Because closing paranthesis in Scheme/Lisp is a drag, and it looks ugly. The syntax I am thinking of is not general (cannot shortcut all paranthesis), but should cover a majority of the situations.

For example:

 (define (split-in-two lst)
   (if (null? lst)
      '()
       (letrec ((iter (lambda (p1 p2)
                      (cond ((null? p2) (cons '() p1))
                            ((null? (cdr p2)) (cons '() p1))
                            (#t (let ((result (iter (cdr p1) (cddr p2))))
                                  (cons (cons (car p1) (car result)) (cdr result)
                     ))))))
               )
        (iter lst lst)
   )))

where I avoided the typical Scheme conventions in order to show the paranthesis that are just too many too close and kind of a sore to the eye. So in the new notation I would have:

 (define (split-in-two lst)
   (if (null? lst)
      '()
      (letrec ((iter (lambda (p1 p2)
                      (cond ((null? p2) (cons '() p1))
                            ((null? (cdr p2)) (cons '() p1))
                            (#t (let ((result (iter (cdr p1) (cddr p2))))
                                  (cons (cons (car p1) (car result)) (cdr result)
                     )/iter  )
        (iter lst lst)
   )/define

Where )/sname closes all the lists up to the list that started with the first element being a the symbol designated by sname. I find this closing of many paranthesis to be a very common occurrence in Lisp/Scheme and it kind of bothered me, especially if you want to edit S-Expression in the text box of a browser. Anybody cares to comment, or is anybody having a better idea?

Behold the mighty SuperBracket?: ] ! It has been cleaning up the tails of Lisp EssExpressions for many a year.

Yes, and nice clean EssExpressions still look better and I'm guessing make drag and drop or cut and paste of entire expressions much easier. The super bracket must die.

I don't get it, I fired my Scheme and `[((] gave me a read error. So did my LispWorks. I thought [] are just garden variety () used for diversification only not some kind of super-bracket. I also tried `((( :] to no avail, so I simply don't get this SuperBracket? thingie. I was trying to invent a syntax that is more readable and less error prone when you are outside an environment that highlits S-Expression blocks upon closing paranthesis. I hate when I have to close 6 or 7 of them, and keep the count somehow. Am I totally off the mark? -- Costin
I've seen mention of the super bracket (aka super parentheses) before (see http://www.gavilan.edu/csis/languages/parentheses.html) but it doesn't seem to work in GNU Common Lisp, either. -- DV

"Super brackets" (more commonly called "super parenthesis") are quite ancient by now, and way back when, it meant "close all currently open parens"). They used to be popular.

But for a long while now, bracket has instead been used, as someone said above, "for diversification". That's not the whole of the story, though. It's very important that close bracket only matches open bracket, not an open paren; that helps to group things in an error-free way.

The above code using the bracket convention is simply (with mild and imperfect change of indent to accentuate a bracket):

 [define (split-in-two lst)
   (if (null? lst)
      '()
      (letrec (
                     [iter (lambda (p1 p2)
                      (cond ((null? p2) (cons '() p1))
                            ((null? (cdr p2)) (cons '() p1))
                            (#t (let ((result (iter (cdr p1) (cddr p2))))
                                  (cons (cons (car p1) (car result)) (cdr result)
                     ]  )
        (iter lst lst)
 ]

Paren levels are guaranteed to match (sum to zero) within each bracket expression.

Anyway, Costin's notation might combine well with that standard bracket convention. I wouldn't want the bracket convention to be outright replaced, though. -- DougMerritt

[1] WcpEssExpressions closely follows RonaldRivest's proposal http://theory.lcs.mit.edu/~rivest/sexp.html , but with more primitive types.

CategoryWikiChangeProposal