gmane.lisp.readable-lisp

Suggestions for improving readability of thiscode?

David A. Wheeler — 2013-05-12T01:03:33

I took this code:
  http://paste.lisp.org/display/137116

and sweetened it into:
  http://paste.lisp.org/display/137111

Any suggestions on how to make it even better, especially around the defclass formatting-stream?  Per comp.lang.lisp, "This forms defines a class formatting-stream inherited from trivial-gray-streams:fundamental-character-input-stream and having 5 slots: understream, width, column, word-wrap-p, word-buffer. The sweet-expression variant reflects this not very clearly."  I'll take a crack at it later, but suggestions from others welcome.

--- David A. Wheeler



------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and 
their applications. This 200-page book is written by three acclaimed 
leaders in the field. The early access version is available now. 
Download your free book today! http://p.sf.net/sfu/neotech_d2d_may

Readable 0.9.0 now posted

David A. Wheeler — 2013-05-09T04:09:32

The readable project download area ( https://sourceforge.net/projects/readable/files/ )
now has a shiny new easily-downloaded file: readable-0.9.0.tar.gz

This has the Common Lisp implementation, as well as the updated interpretation of lines
with at least one "!" and only indent chars (such lines are ignored). It also has the latest SRFI-110 draft.

My intent is to try to announce it to some Common Lisp sites.  Some will poo-poo, but others may be
interested, and we might get some last-minute feedback.  I want the same notation to apply to both
Common Lisp and Scheme, so if there are any last-minute comments from Common Lispers I'd like to
hear them.  Once SRFI-110 freezes, I intend for people to be able to depend on the specification
(so correctly-written code will not, in future, have a silent change in interpretation).

--- David A. Wheeler

------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and 
their applications. This 200-page book is written by three acclaimed 
leaders in the field. The early access version is available now. 
Download your free book today! http://p.sf.net/sfu/neotech_d2d_may

Common Lisp: clisp |...| weirdness

David A. Wheeler — 2013-05-07T01:15:47

FYI...

The Common Lisp implementation of all the "readable" notation tiers seems to be working well.

One oddness is that clisp (a widely-used Common Lisp implementation) forces all the symbols to be displayed with |...| around them when using neoteric- or sweet-expressions.  I've tracked this down to an oddity of its implementation of "write", which varies its display depending on the readtable.  I don't see an easy way to change this in the short term, and it works as-is, so in the short term I'll just document this as an oddity in the tutorial.

In the long term, this could be fixed through a small patch to clisp.  I've already posted a feeler Qon the clisp mailing list, to see if the clisp folks would be willing to entertain a patch.  Below is part of that message, for your information.

--- David A. Wheeler

=======================================================

Okay, I've looked through the clisp code and I found the problem.
The issue is in file "src/io.d" function "pr_symbol_part"
(which starts line 7004 on 2013-05-06), with this code.
It forces |...| around symbols based on what happens to be in the current readtable:

======================================================
var object syntax_table; /* syntaxcode-table, with char_code_limit elements */
var uintW rtcase; /* readtable-case */
{
var object readtable;
get_readtable(readtable = ); /* current Readtable */
syntax_table = TheReadtable(readtable)->readtable_syntax_table;
rtcase = RTCase(readtable);
}
/* traverse string: */
SstringDispatch(string,X, {
...
if (!(syntax_table_get(syntax_table,c) == syntax_constituent))
goto surround; /* no -> must use |...| */
======================================================



Would the clisp folks be willing to entertain a tweak so that
users could better control this auto-escaping, if they desire?

For example, perhaps there could be a *pr-symbol-readtable* variable that defaults
to nil. Then, in the code above, use the readtable referenced in *pr-symbol-readtable*
if it's non-nil, and if it's nil (the default), use the current readtable.
That would maintain the current behavior by default, but be more flexible.

--- David A. Wheeler


------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and 
their applications. This 200-page book is written by three acclaimed 
leaders in the field. The early access version is available now. 
Download your free book today! http://p.sf.net/sfu/neotech_d2d_may

Fwd: Proposal: make $ serve as GROUP,leave \ to always be SPLIT

David A. Wheeler — 2013-05-03T21:41:32

All: The following proposal was sent by Beni Cherniavsky-Paskin to the SRFI-110 mailing list.  Since it proposes a massive change to the sweet-expression notation, I wanted to make sure it was also posted on this mailing list (readable-discuss).

I'm not so sure about this proposal (and to be fair, neither is the proposer!).  Even if I *loved* it, I'd hate to make a big change this late in the game.  But I want to consider all ideas fairly, and I also want everyone to be aware of discussion items like this that would change fundamental semantics.  And it's fair to say that NOW is the time to change semantics (if we do) - not later.

Right now I'm just mulling over this idea in my mind.  I'll reply once I've thought it through further.  If anyone else has a thought, though, PLEASE speak up.  In this particular case cross-posting is probably appropriate (I hate to see much of that, but this really does cross the goals of both mailing lists).

--- David A. Wheeler


----- Start Forwarded Message -----
Sent: Thu, 2 May 2013 01:46:16 -0700
From: Beni Cherniavsky-Paskin <cben-iA+eEnwkJgzk1uMJSBkQmQ< at >public.gmane.org>
To: srfi-110 <srfi-110-D5jPTyc31mpbJb6xxNauyti2O/JbrIOy< at >public.gmane.org>
Subject: Proposal: make $ serve as GROUP, leave \ to always be SPLIT

This is kinda late to say this, and I'm not at all sure it's an
improvement.  But the thought won't leave me, so better now than never...

\\'s dual duty is nagging me.  Intuitively, I grasp the operators like this:
- SPLIT prevents creation of lists ("a \\ b") or at least fractures them
("a b \\ c d").
- GROUP's sole reason[*] for existence is to express a list of child lines.
- SUBLIST (usually) creates lists.

Which leads me to feel that \\'s two meanings are opposite — SPLIT is
"anti-list", GROUP is "pro-list".
=> What if we make a lone $ on a line serve as GROUP, making $ always
"pro-list"?
Then we'd write:

let
! $
! ! x foo()
! ! y bar()
! do-stuff(x y ...)

[this currently isn't legal (trailing $), and would produce a spurious (((x
...) (y ...))) level if it were legal.]

I don't really think the "pro-list vs anti-list" argument is critical; the
more important criteria are:
* Can this unify the handling of leading $ vs head $ rest?
  If this can reduce us from 3 central constructs to 2, it's a major win.
  If leading $ remains a special case, just subtler, maybe it's a loss.
* Is this consistent with $ in haskell?  [don't know if this Q even means
anything]

Another issue I see with the current leading $ behavior is this
inconsistency:

foo (a b) ==> (foo (a b))
foo $ a b ==> (foo (a b))
(a b) ==> (a b)
$ a b ==> ((a b))  ; huh?!

foo a ==> (foo a)
foo $ a ==> (foo a)
a ==> a
$ a ==> (a)  ; huh?!

In other words, I feel that since "$ ..." always produces one object
(whether atom or list), it should be exempt from wrapping in a list if "$
..." is the first thing on a line.
This implies that "$ $ $ a" ==> a.  I'm not sure I love that, but that's
how "\\ \\ \\ a" works now.

[*] I've  ignored the do-nothing leading \\ usage for stylisitically
indenting some things, e.g. Arc's flat if and keyword args:

if
! cond1
! \\ then1 ...
func
! kw:
! \\ arg ...

IIRC this is currently ascribed to GROUP's disappearing act, but the same
effect with \\ could also be explained as a SPLIT with nothing on one side.
Alternatively, you can drop the behavior from \\ and use $ instead:

if
! cond1
! $ then1 ...
func
! kw:
! $ arg ...

but that'd miss the symmetry that now exists with one-liner form:

if
! cond1 \\ then1 ...
func
! kw: \\ arg ...

P.S. Cosmetic points:

- We'd lose the diagonal look of \\ which felt appropriate for GROUP.

+ The remaining sense of \\ will be familiar to TeX users ;-|
  Curiously, the blank-line semantics (comment = not blank) also match.


----- End Forwarded Message -----------------------------------------------------------------------------------
Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2_______________________________________________
Readable-discuss mailing list
Readable-discuss-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f< at >public.gmane.org
https://lists.sourceforge.net/lists/listinfo/readable-discuss

Advice on implementing backquote/comma

David A. Wheeler — 2013-04-29T02:53:54

I'm looking for advice on how to implement, in Common Lisp, the sweet-expression semantics for {backquote,comma,comma-at}+whitespace.

The "obvious" way is to re-implement these capabilities; Steele's 2nd edition appendix C
gives public domain code to do this:
  http://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node367.html
This seems a little error-prone, and it won't take advantage of whatever simplifications exist in the underlying CL implementation.  In general, CL handles this stuff in non-portable ways, and a re-implementation won't "work the same way".

It'd be nice to invoke the "actual" backquote or comma/comma-at, but if I do, they will invoke "read".  Yet I need to regain control of the reader, and pass that reader the indentation level ... preferably in a thread-safe way.  Basically, historically "read" didn't care about indentation levels.. but any indentation processing system will.  One way to do that is to set a special variable (!!) with the indent level, and use the readtable that already redirects all chars.  The readtable would redirect to a procedure that, if the special variable indent is set, invoke the sweet-reader with that indent level.

Am I missing a simpler alternative to implement the intended semantic?

--- David A. Wheeler

------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr

Sweet-expressions, now in Common Lisp!

David A. Wheeler — 2013-04-29T02:42:33

The "develop" branch now has an implementation of curly-infix, neoteric, and sweet-expressions directly written in Common Lisp.

You can try them out, e.g.:
cd $READABLE_DIRECTORY
clisp # Or your_favorite_cl

(require 'asdf) ; or (load "tests/my-asdf.lisp")
(asdf:load-system :readable)
(readable:enable-sweet)


It works well enough that you can just enter the factorial example and it will work.  Sweet-expression semantics for #|...|# and #;datum work correctly too, as does '+space.  Since it can get to that point, I'm counting it as yet another implementation for purposes of SRFI-110 (which can now note that sweet-expressions have been implemented 4 times: old Scheme, new Scheme, ANTLR, and Common Lisp).

There are still a number of "TODOs" in the Common Lisp version, particularly for backquote and comma, but it's still progress!

--- David A. Wheeler


------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr

clisp bug?

David A. Wheeler — 2013-04-23T04:04:54

I think I've hit an ugly clisp bug that hits the Common Lisp implementation of neoteric-expressions. Has anyone seen anything like this?  Or, am I misunderstanding something?

Here's the details: I think clisp version  2.47 and 2.48 don't preserve any whitespace, even when you call "read-preserve-whitespace", immediately after the call.  As a result, "(a ())" and "(a())" look exactly alike, and both get translated to "((a))".  Similarly, "{a + {b * c}}" becomes "{a +{b * c}}".  The expression "(a  ())", with TWO spaces after the "a", is handled correctly.

My test script is:
(progn (write (read-preserving-whitespace *standard-input* t nil)) (write (peek-char)) (princ " ") (write (read-preserving-whitespace *standard-input* t nil)) (values))

With the input:
q56 t78
(one space between)

Running this on sbcl (Steel Bank), I get the expected:
Q56#\  T78


On GNU CLISP 2.47 (2008-10-23), I get the really-really-wrong result:
Q56#\t T78

That is, after reading the atom "q56" the following delimiting whitespace is *consumed* by read-preserving-whitespace.  Using TWO spaces as the separator makes it work fine again.

Such a bug was reported on clisp, but was reported fixed in 2008:
http://sourceforge.net/tracker/?func=detail&atid=101355&aid=1890854&group_id=1355

This could be worked around, but with pain. I prefer to avoid pain :-).

--- David A. Wheeler

------------------------------------------------------------------------------
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter

sweet processing inside brackets

Arne Babenhauserheide — 2013-04-21T07:39:04

Hi,

I’m currently writing real code with wisp, and while thinking about ways to make non-tail-call functions as elegant as tail-called ones, I found a form which should work with sweet, too:

let : : origfile ( open-file : nth 1 : command-line ) "r"

Essentially that’s the realization, that brackets are much less visually jarring, if they are (a) used sparingly and (b) are used to actually structure the code without taking over the code.

The requirement for that it to keep limited non-indetation syntax active inside brackets (what wisp currently does not do). Essentially it means providing the optimizations for whitespace sensitive syntax also for code in brackets.

For sweet, that could mean

a ( b c \\ d e \\ f g ) h

compare the lisp

(a (b c) (d c) (f g) h)

that way, the brackets become a way to structure the code.

Best wishes,
Arne

Common Lisp "basic-curly.cl"

David A. Wheeler — 2013-04-18T22:59:48

I've added a new Common Lisp file "basic-curly.cl" that *just* implements basic curly-infix.  In basic curly-infix, the list elements are more basic curly-infix (NOT neoteric)... which is WAY easier to implement, and can work on *any* Common Lisp implementation that implements the specs.

When you "make install", it installs this file in the usual place so asdf can find it (By default, /usr/local/share/common-lisp/source/readable/basic-curly.cl).  I'd like to make it so that people can just "load" this file (so I don't want to have dependencies), or use asdf and "require" it.

Currently it auto-enables it, but I'm thinking that maybe enabling it should be separate, especially since I hope to turn this into part of a larger package.  Thoughts?

If anyone has experience packaging Common Lisp libraries to make it easy-to-use, I'd love to hear about it.. or have help doing it.  I'm using the asdf and Fedora packaging-for-Common-Lisp docs as guidance, but haven't done it before.

--- David A. Wheeler


------------------------------------------------------------------------------
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter

Comparision to wisp in SRFI; Was: Re: wisp: Whitespace to Lisp: An indentation to brackets preprocessor

David A. Wheeler — 2013-04-16T04:50:56

Okay, I've tried to merge all the emails and add my own thoughts about wisp.  Basically, I've added a whole new section on wisp. I like the sweet-expression approach better (no surprise), but I think the wisp approach is both interesting and worthy, and it definitely deserves discussion.

I'd love to hear feedback on this draft.

To get it:
Open http://sourceforge.net/p/readable/wiki/Home/
Select "git repository" (at top)
Click on "Develop" branch (left hand side)
Click on "SRFI-110.html".

Or, just do a "git clone" or "git pull" from the repo.

Thoughts?

--- David A. Wheeler



------------------------------------------------------------------------------
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter

Common Lisp results

David A. Wheeler — 2013-04-08T04:36:33

The Common Lisp stuff now works passably well for prototyping, though it's nowhere *near* as mature as the Scheme implementation.  Until someone creates a *real* Common Lisp implementation, we at least have a prototype that'll work for some purposes.

Below are some results after running some tests to see if the Common Lisp stuff *could* be used (it can).

--- David A. Wheeler


To test out the Common Lisp stuff,  I snagged the Common Lisp source code from:
  http://norvig.com/paip/README.html
and ran this:
  ./diff-s-sweet -C -w paip/*.lisp

This program's "-w" option is primarily to help you find s-expressions that aren't well-formatted, but it also helps to test "unsweeten"'s Common Lisp implementation.

Unsurprisingly, nearly all Common Lisp code (at least, in this sample) is also well-formed.   In the guile test suite, *EVERY* file in the test suite was well-formed.  In the Common Lisp set, I did find a few exceptions, though they were rare:
* In a few places it uses "f(x)" to mean the two datums "f (x)".  This is in a section where it tries to process lists that are math expressions.  Of course, in sweet-expressions f(x) is (f x). This turns out to be rare, unsurprisingly, and easily fixed in the few places they occur by inserting a space between "f" and "(x)".  The whole point of that code is to try to simulate a notation that in my opinion is better handled with sweet-expressions... so in fact that whole section of code could disappear.
* In a few places there are multiple datums on one line, esp. in grammar.lisp where there are a number of declarations about words (multiple declarations are put on a line).  Inserting 1+ spaces in front of the line fixes this completely, and it actually doesn't happen very often.

I also found a few weaknesses in its handling of Common Lisp, which *could* be fixed:
1. The sequence ".," is currently interpreted as a symbol (as does guile!), which isn't correct for Common Lisp:
(defun make-clause (clause)
  "Translate a message from define-class into a case clause."
  `(,(first clause) #'(lambda ,(second clause) .,(rest2 clause))))
That could be fixed in our reader, but for the moment, it doesn't seem worth the trouble.
2. The |...| is consumed by the reader, and not printed back out later, so |.| is mis-interpreted later as the set-cdr operator in "examples.lisp" section "(defexamples 7 ...".

It's a rough count, but there are 11738 lines in this sample code set (per wc -l paip/*.lisp); note that is *not* pretty-printed.  The # of lines of code where there were problems, was 197 (per ./diff-s-sweet -C -w paip/*.lisp | grep '^- ' | wc -l), which is 1.7%.  Generally the problem was that one construct, say ".,", would cause an entire datum to fail, so it's not as bad as it looks.  It's basically a very small set of lines that have to be changed before nearly all of them can be read as-is.


------------------------------------------------------------------------------
Minimize network downtime and maximize team effectiveness.
Reduce network management and security costs.Learn how to hire 
the most talented Cisco Certified professionals. Visit the 
Employer Resources Portal
http://www.cisco.com/web/learning/employer_resources/index.html

StackOverflow - please vote for relevant answers

David A. Wheeler — 2013-04-01T23:24:57

I think it's important that StackOverflow help interested people learn about our work.  We need to make sure the answers exist, and that the votes are high enough so people will read about them.

There are at least 2 questions on StackOverflow where people should be able to learn about this "readable" project and (for Scheme users) SRFI-110.  If you could vote for relevant answers (I tried to give one for each), that'd be great.

Here are ones I found:
http://stackoverflow.com/questions/4607310/are-there-good-alternative-scheme-syntaxes/15421584#15421584
http://stackoverflow.com/questions/2720843/can-a-language-have-lisps-powerful-macros-without-the-parentheses/15421628#15421628

If there are other StackOverflow questions where people might want to know about our work, please post about them here!

 --- David A. Wheeler

------------------------------------------------------------------------------
Own the Future-Intel&reg; Level Up Game Demo Contest 2013
Rise to greatness in Intel's independent game demo contest.
Compete for recognition, cash, and the chance to get your game 
on Steam. $5K grand prize plus 10 genre and skill prizes. 
Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d

Time for a new release (0.7.1)

David A. Wheeler — 2013-03-30T12:57:23

I think it's time for a new release, which I suggest calling version 0.7.1.
This one:
* Allows a collecting list after ".", e.g. "a b . <* c *>".  The draft SRFI specifically gives this as an example, so it'd be nice if the easily-downloaded version actually supported it.
* Initial indents now allow "!"
* Adds a new tool, "diff-s-sweet"
* The Scheme implementation detects "*>" without matching "<*".
* Updates the draft SRFI-110.

Any objections or last-minute tweaks?  Please speak up quickly, if so!

 --- David A. Wheeler

------------------------------------------------------------------------------
Own the Future-Intel(R) Level Up Game Demo Contest 2013
Rise to greatness in Intel's independent game demo contest. Compete 
for recognition, cash, and the chance to get your game on Steam. 
$5K grand prize plus 10 genre and skill prizes. Submit your demo 
by 6/6/13. http://altfarm.mediaplex.com/ad/ck/12124-176961-30367-2

wisp: Whitespace to Lisp: An indentation tobrackets preprocessor

Arne Babenhauserheide — 2013-03-26T06:27:45

Hi,

I finally managed to get the simple indentation to lisp preprocessor into a working state and thought you might be interested.

It includes the simpler semantic of linelist via a colon (:), parameter list continuation with a dot (.) and visualizing indentation with initial underscores (_). And that’s it.

All syntax elements except for the dot can be escaped, so you can still use underscores or a colon as function or variable names, and it’s a simple preprocessor which can either read the code from a file or from stdin, so lisp implementations could simply run code they want to read through the preprocessor.

It has almost no error checking, though: You can write non-conforming code and the preprocessor will still turn it into something which looks like lisp but could even miss closing brackets.

But at least I managed to write a real release text with an explanation of the syntax and code-examples: 
http://draketo.de/light/english/wisp-lisp-indentation-preprocessor

I hope you enjoy the read!

Best wishes,
Arne

PS: < at >David: I just realized that I had missed quite a few of your answers because they were sent only to the list while Alans answers were also addressed to me… sorry for that. 
(mails with my mail address in the receivers are automatically pulled into a special folder in my mail setup to allow me to scale my mail reading down, when I have little time, and just read stuff I should react to because it is addressed at me)

--
Ich hab' nichts zu verbergen – hab ich gedacht: 

- http://draketo.de/licht/lieder/ich-hab-nichts-zu-verbergen

------------------------------------------------------------------------------
Own the Future-Intel&reg; Level Up Game Demo Contest 2013
Rise to greatness in Intel's independent game demo contest.
Compete for recognition, cash, and the chance to get your game 
on Steam. $5K grand prize plus 10 genre and skill prizes. 
Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d_______________________________________________
Readable-discuss mailing list
Readable-discuss-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f< at >public.gmane.org
https://lists.sourceforge.net/lists/listinfo/readable-discuss

Shoudl I add antlrworks-1.4.3.jar to the gitrepo?

David A. Wheeler — 2013-03-19T10:54:26

The BNF requires the "antlrworks-1.4.3.jar" tool, which is an old version.
Unfortunately, later versions don't work, and it looks like it'd be nontrivial to fix.

I'm thinking about adding antlrworks-1.4.3.jar to the git repo.
That way, people can get it without trawling the network.
This would add a 3.5M file (ugh).
I don't plan to add it to the distribution file, so it's only git clone
users who would see the load.

Thoughts?

 --- David A. Wheeler

------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar

Down "readable" version 0.7.0 released!

David A. Wheeler — 2013-03-10T14:17:41

I've released version 0.7.0 of the "readable" results, here:
  https://sourceforge.net/projects/readable/files/?source=navbar

This includes an implementation of sweet-expression version 0.7.

The major *semantic* change is the addition of collecting lists
in sweet-expressions.

This also includes a BNF of sweet-expressions (written and checked
with ANTLR), as well as a Scheme re-implementation to match the BNF.
It also includes many more tests.  All of this was done with the of
moving to that is correct and is convincingly correct.
Of course, it's certainly possible for there to be a mistake anyway,
so please let us know of any.

The release also includes the current draft of SRFI-110,
spec for the Scheme implementation of sweet-expressions.

I plan to announce this in a while on the SRFI-110 mailing list
as well.

 --- David A. Wheeler

------------------------------------------------------------------------------
Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester  
Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the  
endpoint security space. For insight on selecting the right partner to 
tackle endpoint security challenges, access the full report. 
http://p.sf.net/sfu/symantec-dev2dev

Plan to release 0.7

David A. Wheeler — 2013-03-08T00:33:07

I plan to release a "0.7" ASAP so that people can easily download and install a sweet-expression reader, etc.

That should help, for example, people experimenting with the first draft of the SRFI.

 --- David A. Wheeler

------------------------------------------------------------------------------
Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester  
Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the  
endpoint security space. For insight on selecting the right partner to 
tackle endpoint security challenges, access the full report. 
http://p.sf.net/sfu/symantec-dev2dev

New SRFI-110: Sweet-expressions!!!!!

David A. Wheeler — 2013-03-05T17:39:14

BIG NEWS!

We now have a new SRFI process, SRFI-110, for "sweet-expressions" in Scheme.  The current draft is here:
  http://srfi.schemers.org/srfi-110/

I STRONGLY encourage everyone here to also join the SRFI-110 mailing list. Just send mail with a "subscribe" subject line to: srfi minus 110 minus request at srfi dot schemers dot org

Also, *please* let others in the Scheme community know about SRFI-110.

For issues that apply to the SRFI (which is obviously specific to Scheme), please post to the SRFI-110 mailing list.

 --- David A. Wheeler

------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_feb

Comments on SRFI proposal (sweet-expressions)

David A. Wheeler — 2013-03-03T16:19:29

I just got an email from Michael Sperber (a SRFI editor).

Overall he thought it was a "nice job" for an initial submission,
with two comments:
1. We should  probably reference Honu:
  http://www.cs.utah.edu/plt/publications/gpce12-rf.pdf
2. We should also provide the ANTLR file as an external file
   in addition to being in-line.

#2 is trivial to do.

#1 will require a little work, but not too bad.

Once we do that, he thinks he can get the SRFI process
started very quickly.
 
--- David A. Wheeler

------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_feb

Sent first draft to SRFI editors!

David A. Wheeler — 2013-03-03T03:08:56

Big news: I've sent the current sweet-expression
SRFI draft and reference implementation to the SRFI editors.
It's commit f6a4ba0128f2d9ade33c5361507ce659e7fb6542,
for those of you keeping score :-).

I expect we'll have even more participation and comments
through the SRFI process, but at this point I think we've got
a reasonable starting point.

My heartfelt thanks to EVERYONE who has contributed
through comments, thoughts, etc.  Please keep doing so!

 --- David A. Wheeler

------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_feb

Should #!curly-infix stop #!sweet?

David A. Wheeler — 2013-03-02T06:09:05

Should #!curly-infix stop #!sweet?

Originally it did.  I implemented "#!curly-infix" and found that our enable-curly-infix didn't disable, so #!curly-infix didn't, and so I changed the SRFI to match.  Now I'm not sure I did the right thing.

You could argue that #!curly-infix should NOT stop #!sweet, since #!sweet embeds curly-infix, and this means that #!curly-infix is "safe" to arbitrarily add.

You could argue that #!curly-infix SHOULD stop #!sweet, so that you can switch modes.

Thoughts?

 --- David A. Wheeler

------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_feb