gmane.lisp.readable-lisp

Re: Long Common Lisp loops... and sweet-expressions.

David A. Wheeler — 2013-05-15T02:39:18

Thanks for the excellent pointers!

The great article on various loop macros provides evidence for my point:
the Common Lisp loop construct is *not* copied by other loop constructs.
As the article notes, "It uses a keyword syntax which for simple examples makes it
look like broken English (this is a plus or minus, depending on who
you ask)."

All of the other loop constructs create (sub)lists for sub-constructs, which
sweet-expressions handle very nicely.  The Common Lisp one is weird in having
a varying number of terms, all at the SAME list level... and that's the one that
is awkward when you try to have indentation processing active.
But once you surround it with (...) - which of course is what it was designed for -
it's just fine.  So, the concern I had with sweet-expressions and Common Lisp loop
doesn't seem so bad, on second view.

--- David A. Wheeler

------------------------------------------------------------------------------
AlienVault Unified Security Management (USM) platform delivers complete

Re: Long Common Lisp loops... and sweet-expressions.

John Cowan — 2013-05-14T22:21:53

David A. Wheeler scripsit:


Well, Scheme does have loops too, though not yet
standardized, notably SRFI 42 Eager Comprehensions at
<http://srfi.schemers.org/srfi-42/srfi-42.html>, Riastradh's version of
foof-loop at <http://mumble.net/~campbell/scheme/foof-loop.txt>,
and Alex Shinn's version of foof-loop at
<https://chibi-scheme.googlecode.com/hg/lib/chibi/loop/loop.scm>.
R7RS-large will have a loop library, probably one of these three.
Alex also has a great article on various loop macros, with examples,
at <http://groups.google.com/group/comp.lang.scheme/msg/60dcac5ea812398>.

Re: Long Common Lisp loops... and sweet-expressions.

David A. Wheeler — 2013-05-14T21:49:53



Okay.  That's where I'm leaning, too.  But if there are last-minute discussions that need
to be raised, now would be the time.

I'm posting this question on readable-discuss, not the srfi-110 mailing list, because I can find no cases where
this kind of thing would plausibly occur in Scheme.  Even in Common Lisp, the "loop" construct
is... well... atypical.  (Feel free to say "ugly".)

As I re-read the list structure for long Common Lisp loops, it actually doesn't look too bad
when does as a list.  Or should I say, it's no worse than usual :-), and even slightly better.

There might be a case for ignoring leading "!" inside lists, if these are more common.
However, that'd make it impossible to just reuse an underlying
read implementation, and that seems undesirable.

--- David A. Wheeler

------------------------------------------------------------------------------
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily a

Re: Long Common Lisp loops... andsweet-expressions.

Beni Cherniavsky-Paskin — 2013-05-14T21:27:09

[disclaimer, which perhaps I should have been adding long ago: I haven't
written any CL in years.
Nor scheme, actually, but I much prefer it to CL.  I only occasionally do
pieces of emacs lisp.]

I think code with \\ at line ends would be annoying to maintain, for the
same reason multi-line #defines are in C.
When editing it's easy to omit \\ on one line and the meaning of the
following lines changes, perhaps creating a subtle bug instead of an
outright error.
Many people maintain an aligned column of \ (so you can validate it's
unbroken at a glance), but this is only practical with editor support.

Arne's leadlng dot syntax is somewhat better:
- It doesn't depend on all previous lines having unbroken.
- It's more visible at start of a line.
- In a long .-prefixed block the dot's are vertically aligned for free.

Also, I think trailing \\ would break some \\ symmetries:
  a b \\ c d
and
  a b
  \\ c d
are the same but
  a b \\
  c d
wouldn't be.

Personally, I'd just use parens and/or avoid overly complex lo

Long Common Lisp loops... and sweet-expressions.

David A. Wheeler — 2013-05-13T22:28:17

I'm looking for some feedback... should sweet-expressions be adjusted to handle really long Common Lisp loop statements?

Sweet-expressions work just great with relatively short Common Lisp loop statements.  But here's an example from hunchentoot version 1.2.18 file request.lisp line 176+:

(loop with buffer = (make-array +buffer-length+ :element-type 'octet)
      with content = (make-array 0 :element-type 'octet :adjustable t)
      for index = 0 then (+ index pos)
      for pos = (read-sequence buffer content-stream)
      do (adjust-array content (+ index pos))
         (replace content buffer :start1 index :end2 pos)
      while (= pos +buffer-length+)
      finally (return content))

So... what should be done with really LONG loop expressions like this?
The best approach I've found currently is to just use parens to disable indent processing:
(loop with buffer = make-array(+buffer-length+ :element-type 'octet)
      with content = make-array(0 :element-type 'octet :adjustable t)
      for index = 0 the

Re: Suggestions for improving readability ofthis code?

Alan Manuel Gloria — 2013-05-12T02:36:36

I suggest keeping it as close to the original code as possible:

defclass formatting-stream
(trivial-gray-streams:fundamental-character-input-stream)
 \\
   understream
                :initarg \\ :understream
                :reader \\ understream
   width
          :initarg \\ :width
          :initform \\ error "missing :width argument to formatting-stream
creation"
          :reader width
   column
           :initform \\ 0
           :accessor column
   word-wrap-p
                :initform \\ t
                :accessor \\ word-wrap-p
   word-buffer
                :initform \\ make-array 1000
                                      :element-type \\ 'character
                                      :adjustable \\ t
                                      :fill-pointer \\ 0
                :reader \\ word-buffer

Sincerely,
AmkG



On Sun, May 12, 2013 at 9:03 AM, David A. Wheeler <dwheeler-OyCmK+MLziRWk0Htik3J/w< at >public.gmane.org>
wrote:
defclass formatting-stream?  Per comp.lang.lisp, "This forms defines a

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 definitiv

Proposal: Release updated "readable"

David A. Wheeler — 2013-05-07T15:56:33

I intend to release, very soon, an update of the "readable" package:
* We have a new Common Lisp implementation
* We've made some small tweaks to the "readable" notation, in particular, lines with only indent chars and at least one "!" are simply ignored.
* There are various small improvements in the tools.

I intend to call it version "0.9".  Basically, I want people to be able to easily download and try this out for a short while before we freeze SRFI-110.  Once SRFI-110 freezes, I expect that we might fix bugs and add functionality, but I plan to keep the notation unchanged so that people can write code and rely on it.  (It might be *extended* in the future, but I don't want any changes that would cause a change in interpretation of valid code).

Please let me know ASAP if there's a problem doing so.

--- David A. Wheeler

------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph

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

David A. Wheeler — 2013-05-07T15:42:17

I haven't seen any other comments on this, and I don't think it's an improvement.
It complicates some things, eliminates a potential avenue for future extension
(should that be useful), and interferes with some nice symmetries.
I'll note that even the proposer isn't sure we should do this.

So for the moment I (at least) don't plan to do this.  If anyone has additional arguments for this,
please post asap...

BTW, I really appreciate Beni's willingness to post the idea now, while we can still
reasonably discuss it.  Thanks!

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

Re: Common Lisp: clisp |...| weirdness

David A. Wheeler — 2013-05-07T03:42:24

That does what's expected... but not exactly what I want.  The problem is that setting *print-escape* disables printing the |...|, even when the escapes NEED to be there.  In particular, if you don't have "-modern" mode on in CLISP (which gives you full case-sensitivity and the default function names in LOWER case), it won't escape cased characters as it needs to.

I should probably document *print-escape* in the tutorial, though; that may be enough for some, and it would stop the obvious question.

And while it's possible to create your own "write" routine, I really want to control the "write" used in the REPL.

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

Re: Common Lisp: clisp |...| weirdness

John Cowan — 2013-05-07T03:19:26

David A. Wheeler scripsit:


What happens if you replace (write x) with
(let ((*print-escape* nil)) (write x))?

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 li

Re: Why forbid ! in whitespace-only line?

David A. Wheeler — 2013-05-04T22:56:09

Beni Cherniavsky-Paskin <cben-iA+eEnwkJgzk1uMJSBkQmQ< at >public.gmane.org> wrote on May 1, arguing that "!"-only lines should be treated differently:

David Vanderson:

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

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

Arne Babenhauserheide — 2013-05-04T20:44:50

Am Freitag, 3. Mai 2013, 23:13:31 schrieb David A. Wheeler:

The inconsistency is not in $, but in treating single-item lists specially:

a → a
a b → (a b)

Since (a b) is a single item, it gets treated as single item.

It makes the code more readable, but it also leads to some side-effects.

That’s one of the things I changed in wisp: To get the single-item behaviour, you have to prefix the item with a dot (.). The advantage is added consistency, but at the same time it is a trap: It’s easy to forget the . for a return value (real coding verified that assumption from Alan (I think it was Alan)).

Not adding brackets for a single item also has the advantage, that you can copy-paste lisp-code into readable. If you do the same in wisp, you have to prepend every top-level bracket with a dot. 

Readable:

    (a b (c)) → (a b (c))

Wisp:

    . (a b (c)) → (a b (c))

On the other hand:

Readable:

    $ a b → ((a b))

Wisp:

    : a b → ((a b))
-or-
    (a b) → ((a b))

Best wishes,
Arne
--
Ein

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

David A. Wheeler — 2013-05-04T03:13:31


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




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

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


One immediately consequence is that we could not to later add semantics for "$" at the end of the line, such as the "Beni lite" semantics.  Currently a "$" at the end-of-the-line is an error, making it easy to define a later extension using it without fear of interfering with existing sweet-expressions.

That's not a disaster, but worth noting.


I don't think so.  From a quick look at the BNF (the it_expr production), it looks like it'd create a slightly more complicated BNF.

Currently leading GROUP_SPLIT and "scomments" (e.g., #|...|#) are actually handled by exactly the same branch of the same rule; there's actually no difference in how they work.  If we make *only* "$" do this, we'd have to have more branches to distinguish them, because a leading scomment like "#;(x y) z" would have to be treated differen

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

Common Lisp versions of curly-infix, neoteric,and sweet!!

David A. Wheeler — 2013-04-30T04:31:19

We now have mostly-working Common Lisp implementations of curly-infix, neoteric, and sweet-expressions.  The whole thing is in a "readable" library.  The key holdup was getting backquote and the various comma expressions are working.

So this, and many other things, work in the sweet-expression implementation for Common Lisp:
defun fact (n)
! if {n <= 1}
!   1
!   {n * fact{n - 1}}
fact 5

There are a number of little points to work out; I've tried to identify all the ones left with "TODO" in the code.   It's mainly handling weird cases, e.g., # followed by certain letters, or EOF handling in odd places.  It also needs a proper test suite, and a little more work on the packaging.

I suspect we should have a *separate* tutorial for Common Lisp, because most people will probably start with just Scheme or just Common Lisp.  Anyone disagree?

--- David A. Wheeler

------------------------------------------------------------------------------
Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET

Re: Advice on implementing backquote/comma

David A. Wheeler — 2013-04-30T00:44:35


Thanks for the reply! That's true, but then I'd have to pack/unpack the info,
and there's a fair amount of setup/unsetup to work around read's interface.

After a certain point, the effort to avoid the work is harder than doing the work :-).

What's silly is that (obviously) the underlying Common Lisp *HAS* a mechanism
for implementing backquotes and the various ,-operators. The problem is that there's
no standard way to directly *invoke* them without also invoking read.
But on re-examination, I found that re-implementation was easier than I thought.

So I ended up re-implementing just those functions, basically by copying Steele's code.
It's public domain, but I'm delighted to give him credit.

The result: the Common Lisp sweet-expression implementation now properly handles
backquoting and the comma operators (comma-at, comma-dot, and just plain comma).

Hooray!

--- David A. Wheeler

------------------------------------------------------------------------------
Introducing AppDynamics Lite, a free troubl

Re: Advice on implementing backquote/comma

Alan Manuel Gloria — 2013-04-29T23:28:11

You could use a dynamically-scoped variable (don't remember what they're
called in CL) to pass back the "reason for stopping" return value, and
return the read-in datum from the read implementation.  Dynamically-scoped
variables are even run-time-stack lifetimes, so they're highly appropriate
for simulating return values.


On Tue, Apr 30, 2013 at 5:31 AM, David A. Wheeler <dwheeler-OyCmK+MLziRWk0Htik3J/w< at >public.gmane.org>wrote:

------------------------------------------------------------------------------
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_______________________________________________
Readable-discuss mailing list
Readable-discuss-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f< at >public.gmane.org
https://lists.sourcefor

Re: Advice on implementing backquote/comma

David A. Wheeler — 2013-04-29T21:31:15

I'd earlier said:

Just to document my research...

Common Lisp can't unget multiple characters, but it does have the ability "make-concatenated-stream".  You can create a stream out of a string and park that in front of another stream, resulting in a somewhat similar result:
  http://www.lispworks.com/documentation/HyperSpec/Body/f_mk_con.htm

That lets me control what goes *into* read... but *not* the results that come *out* of read.  Sigh.  The fundamental problem is that "read" has a fixed interface, and I need read to *also* return any new indentation, if I want to be able to use backquote with indentation-sensitive constructs.  And I do.

So it looks like I'll have to re-implement backquote and comma in Common Lisp if I want a portable thread-safe Common Lisp implementation.  The good news is that there is such an implementation:

On second glance it doesn't look *too* bad.  Thankfully, this implementation can be in its own file.

--- David A. Wheeler

--------------------------------------------------