gmane.lisp.readable-lisp

Re: Lisp as interactive command line?(sweet-scsh), using with Common Lisp

David A. Wheeler — 2013-05-24T15:18:19

On Thu, 23 May 2013 23:59:40 -0400, John Cowan <cowan-x6Fv9fcoW1Y+uZM1RHzMvw< at >public.gmane.org> wrote:

Ah, thanks for the correction.  R7RS's ability to use a "-" followed by letter or "-"
as a valid identifier should make any Scheme-based shell much easier
to implement portably.  With the exception of "-i" of course.


I realize that || is *legal*, but I think it'd be confusing to actually use ||.
The notion of defining something whose real name is the empty string
just somehow seems wrong :-).  Maybe not, since it can be read and written,
though any users of symbol->string for debugging better be prepared.

I suspect that "pipe" would be a more pleasant name to use than "|\||",
even though it's the same number of characters.

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

Re: Lisp as interactive command line?(sweet-scsh), using with Common Lisp

John Cowan — 2013-05-24T03:59:40

David A. Wheeler scripsit:


More precisely, R5RS does not.  In R6RS, -g is a lexical syntax error,
and in R7RS it's a valid identifier.


Yes, we recognized that | was going to be problematic: it has to be
typed as |\|| now.  || is fine, though; it's the result of
`(string->symbol "")`.

Re: Lisp as interactive command line(sweet-scsh), using with Common Lisp

David A. Wheeler — 2013-05-24T03:44:54


We've actually previously discussed using sweet-expressions to implement a Lisp-powered interactive shell.  It's quite doable.

In fact, you can experience it right now. Just install scsh and run:
  ./unsweeten | scsh

You can then type in stuff like:
run $ grep "Wheeler" "README"

As with all sweet-expressions, be sure to press ENTER ENTER to execute it.


I think a better approach is scsh's, which defines special lists called "extended process forms".  Since they are special forms, they can deal with string literals and symbols.  It actually meshes nicely with Scheme.

Basically, you can use symbols as always... but if the context demands that they be sent outside as strings, off they go.


Yes, that's exactly what scsh does.

http://www.scsh.net/docu/html/man.html
Section 2.1 says: "The subforms of a redirection are implicitly backquoted, and symbols stand for their print-names. So (> ,x) means ``output to the file named by Scheme variable x,'' and (< /usr/shivers/.login) means ``read from /usr/shivers/

Re: Lisp as interactive command line(sweet-scsh), using with Common Lisp

Ben Booth — 2013-05-23T16:15:22

I read on the guile user mailing list that version 0.2 of scsh for guile has been released. This got me thinking what a real lisp-powered interactive shell would need in order to be useful:


1. A modified version of sweet-expressions, where barewords are treated as string literals instead of symbols. Bareword string literals could be used along with normal quoted string literals

2. Some way to designate what is a symbol. Bash uses $var or "$var" for variable substitution. A scheme shell could use , and ,< at > (the unquote and unquote-splicing operators) for this purpose. The REPL would then need to convert barewords to strings, and then quasiquote the parsed S-expr before evaluating it

3. If a bareword or a string literal is at the head of a list, it should automatically be interpreted as a function name

4. If a function is called that does not exist in the current scope, the *runtime* needs to call a dispatch function to search for a command in $PATH that matches the function name and execute it. Any argume

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