headers
David A. Wheeler | 12 May 2013 03:03
Favicon
Gravatar

Suggestions for improving readability of this code?

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
Permalink | Reply | 6 comments |
headers
David A. Wheeler | 9 May 2013 06:09
Favicon
Gravatar

Readable 0.9.0 now posted

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
Permalink | Reply | 0 comments |
headers
David A. Wheeler | 7 May 2013 03:15
Favicon
Gravatar

Common Lisp: clisp |...| weirdness

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;
(Continue reading)

Permalink | Reply | 2 comments |
headers
David A. Wheeler | 5 May 2013 00:56
Favicon
Gravatar

Re: Why forbid ! in whitespace-only line?

Beni Cherniavsky-Paskin <cben@...> wrote on May 1, arguing
that "!"-only lines should be treated differently:
> >> define long-func(x)
> >>    let ((foo bar(x)))
> >>    ! do stuff
> >>    ! ...
> >>    !
> >>    ! more stuff
> >>    ! ...

David Vanderson:
> I think I've convinced myself that indentation should NOT be enforced.  
> Anybody else?

Those are excellent points, I agree we should change it.

I've changed draft SRFI-110 so that lines with only space, tab, and at least one "!", are utterly ignored. 
I've also modified the implementations in Scheme and Common Lisp.  The ANTLR implementation will be
tweaked soon.

--- David A. Wheeler

------------------------------------------------------------------------------
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
Permalink | Reply | 0 comments |
headers
David A. Wheeler | 4 May 2013 05:13
Favicon
Gravatar

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

On Thu, 2 May 2013 01:46:16 -0700, Beni Cherniavsky-Paskin <cben <at> users.sf.net> wrote:

> 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...

I'm a little skeptical, but it's important that we think this through *now* vs. later.

> \\'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".

Well... that's not really the original intent.

But let's go with that thought and see where it takes us!

> => 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
(Continue reading)

Permalink | Reply | 3 comments |
headers
David A. Wheeler | 3 May 2013 23:41
Favicon
Gravatar

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

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@...>
To: srfi-110 <srfi-110@...>
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.
(Continue reading)

Permalink | Reply | 0 comments |
headers
David A. Wheeler | 29 Apr 2013 04:53
Favicon
Gravatar

Advice on implementing backquote/comma

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
Permalink | Reply | 4 comments |
headers
David A. Wheeler | 29 Apr 2013 04:42
Favicon
Gravatar

Sweet-expressions, now in Common Lisp!

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
Permalink | Reply | 0 comments |
headers
David A. Wheeler | 23 Apr 2013 06:04
Favicon
Gravatar

clisp bug?

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 :-).
(Continue reading)

Permalink | Reply | 1 comment |
headers
Arne Babenhauserheide | 21 Apr 2013 09:39
Picon
Gravatar

sweet processing inside brackets

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
--

-- 
1w6 sie zu achten,
sie alle zu finden,
in Spiele zu leiten
(Continue reading)

Permalink | Reply | 4 comments |
headers
David A. Wheeler | 19 Apr 2013 00:59
Favicon
Gravatar

Common Lisp "basic-curly.cl"

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
Permalink | Reply | 0 comments |

Gmane