readable-discuss — Discuss methods to improve readability of s-expressions for code

Re: [Readable-discuss] Readable Lisp 2.0, brainstorming

[Arne B. <arn...@we...>]

Alan Manuel Gloria writes:

…<snip definitions which make this concept effective>…
> 4.  Backquotes "invert" the use of a symbol: foo is a prefix symbol, `foo`
> is an infix symbol; while + is an infix symbol while `+` is a prefix symbol.

This sounds pretty useful - close to an implicit, but clearly defined,
curly infix, right?

Best wishes,
Arne

Re: [Readable-discuss] Readable Lisp 2.0, brainstorming

[Alan M. G. <alm...@gm...>]

A set of rules I'm planning out, which would break with most lisp
conventions but preserve the essence of allowing redefinitions of
everything are:

1.  Symbols are of two types:

1.1.  Normally-prefix: /[A-Za-z_][A-Za-z0-9_]*/ or /[.][.]+/

1.2.  Normally-infix: /[+-*/\!@#$%^&:?<>~]+/

2.  Other datums as in typical Lisp.

3.  An out-of-line declaration indicates infix precedence levels and types
(well, at least out-of-line for "normal" datums).

4.  Backquotes "invert" the use of a symbol: foo is a prefix symbol, `foo`
is an infix symbol; while + is an infix symbol while `+` is a prefix symbol.

Processing proceeds as follows:

1.  Use "intuitive" parenthesis insertion based on indentation (in the
example below, the "." are just used to indicate indentation:

map f (a:as) =
. f a:map f as

=>

(map f (a : as) =
  (f a:map f as))


select b t f =
. if b
. . then t
. . else f

=>

(select b t f =
  (if b
    (then t)
    (else f)))

Handle $ SUBLIST at this stage too.

2.  Process infixes.  This involves converting infix forms to prefix forms
and handling precedence.  An infix symbol will cause () to be added to its
left and right hand sides, unless the left/right hand side is composed of
single datums; lower precedence is handled first. Example:

(1 + 2 * 3) => (`+` 1 (2 * 3)) => (`+` 1 (`*` 2 3))

(map f (a : as) = (f a : map f as))
=>
(`=` (map f (a : as)) (f a : map f as))
=>
(`=` (map f (a : as)) (`:` (f a) (map f as)))
=>
(`=` (map f (`:` a as)) (`:` (f a) (map f as)))

The final form is the one used internally, and is a Lisp.

Sincerely,
AmkG

Re: [Readable-discuss] Readable Lisp 2.0, brainstorming

[Arne B. <arn...@we...>]

luke wallace writes:

> If all lisp functions can be defined or redefined by the user,
> then in order to make using those lisp functions readable to an editor in
> the end, the functions would need to be designed with extra functions that
> serve as in-line comments to their arguments
…
> if
> this-is-true 5 + x = 10
> then save-file
> else close-file

This sounds a lot like autocomplete with keyword arguments, and it could
be implemented (conceptually¹) easily using docstrings.

¹: It would still need quite some effort to realize it in an editor.

Example:

(import (ice-9 optargs))
(define* (if #:key this-is-true then else)
  "
auto-complete:
  #:this-is-true
  #:then
  #:else
"
  (cond (this-is-true
         then)
        (else
         else)))

(if
  #:this-is-true #t
  #:then 1
  #:else 3)

(display (procedure-documentation if))
->
auto-complete:
  #:this-is-true
  #:then
  #:else

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken

Re: [Readable-discuss] Readable Lisp 2.0, brainstorming

[luke w. <luk...@gm...>]

If all lisp functions can be defined or redefined by the user,
then in order to make using those lisp functions readable to an editor in
the end, the functions would need to be designed with extra functions that
serve as in-line comments to their arguments

for example, wrapping a then() and else() function for an if-expression
function, no matter if the symbol is 'if' or not

when a symbol 'if' is used to do something else, the author could just use
different functions to explain what is going on, and the software would
just format it like any other lisp, the author controls what helper-text is
generated when they author a function using defun or whatever is used to
define functions in that lisp.

however by removing the parentheses, adding in whitespace, etc, in an
editor, these more complex definitions start to look like english

one functionality that lisp may not have (I'm not sure) is the ability to
make up a new function like "then()" without defining it, and automatically
have it do nothing but return what's inside it (a "comment function")
this might have to be implemented like they implemented "quote", for
example prefixing a function with $then() would mean it just returns whats
inside it (and evaluates it) but requires no function definition to use it

in the general solution this would work like this,
you create an if-expression function with the symbol 'if'

its first argument is wrapped in this-is-true() function (or omitted if the
context for 'if' is clear)
its second argument is wrapped in a then() function
its third argument is wrapped in an else() function
but both of those functions are just returning what's inside them - they
have no complex functionality, their purpose is to help a software editor
auto-complete the symbol 'if' with its first two arguments, which are
then() and else()
anything written after "then" and before "else" goes inside the then()
anything written after "else" goes inside the else()
anything two lines down in the editor does not belong to either (closes the
'if')

so it would look like this in practice:

if
this-is-true
then
else

then the user writes

if
this-is-true 5 + x = 10
then save-file
else close-file


one empty line down, the 'if' symbol is closed...

now if a user redefines 'if' to mean something else, they can wrap the
function arguments in other function names to explain the arguments, or if
there is only one argument, omit it

for example a mouse-move-xy(x,y) function might look like

mouse-move(x(int) y(int))

which in the editor would format as

mouse-move
x 10
y 5

one empty line down, the mouse-move is closed...

Re: [Readable-discuss] Readable Lisp 2.0, brainstorming

[David A. W. <dwh...@dw...>]

On Thu, 1 Sep 2016 19:37:43 -0400, luke wallace <luk...@gm...> wrote:
> My idea is that by converting lisp into a simplified abstract syntax tree
> form, and then performing formatting options on that abstract syntax tree
> (such as prefixing parts of it with syntactic sugar, or compacting some
> levels of the tree, or reformatting the order of operators and operands, we
> are able to create human-readable formatting for conventional lisp code
> 
> Below are two theoretical examples:
> 
> http://i.imgur.com/JNOXQ4M.png

The pictures are fine representations of abstract syntax trees (ASTs).
You need to handle "lists of lists" (like let's first argument);
that can be tricky but is doable.
If you mean for people to view them directly (say auto-generated as you edit),
I'd be a little worried about screenspace - that's always limited compared
to the amount of code being managed.  If you only showed "the part you're
working on" that might not be bad.

Constantly updating a graphical AST representation
of "what I'm working on" might be snappy; if you just keep regenerating from the
text you completely eliminate the problem of selecting things, and you can
highlight "where the cursor is".

If you mean for people to *edit* those directly,
it can be tricky work out how to select the "right spot" for insertion, etc.
I think trying to edit that would be more work than useful.
It's been done for stuff like mathematics:
  http://icm.mcs.kent.edu/reports/2006/ICM-200601-0001.pdf
However, that presumes that you can know what a given operation is
given its name, and how many parameters that operation would take,
which is not true in Lisp.

I'm guessing that you really mean to show those final representations, though, e.g.,
sqrt(a+b*(c-d)) or whatever.  If you use a Lisp as a subset of Python
that can work out fine.... but Python is a better Python.
A key power of Lisp is that you can define your own languages (e.g., macros),
use templating (e.g., ","), and other powerful techniques that exploit homomorphism.
The earlier AST is trivially homomorphic.  However, the "final" representation
shown does *not* appear to be homomorphic.  That's fatal.

Trivial example: the final version added a "then" and "else" after an "if".
But there's no reason to believe that the "if" is actually
the built-in Lisp "if". I could easily define a macro that rewrites "if" into
something else (and indeed, that's a common thing to do in packages).
For example, maybe "if" means "interface" at that point.
Similarly, "defun" (Common Lisp) or "define" (Scheme) might mean the
specific names predefined in the language.. or not.

If you just want a specialized language inside a larger Lisp program,
feel free to create it.  Many have.  But if you want to write Lisp programs in
a "more readable" way, your notation has to be homomorphic & handle
arbitrary s-expressions.  There's simply no way to know what the symbols
"mean" while you're editing them.

I'm *not* saying it's impossible.  It's doable.  Sweet-expressions are one solution,
and the wisp developers have created another.
But you have to consider the general case.  If you limit yourself to
symbols with fixed meanings, there are other languages that already do the job.
If you're going to use a Lisp, it should be because Lisp provides some
advantage to you.

--- David A. Wheeler

Re: [Readable-discuss] Readable Lisp 2.0, brainstorming

[David A. W. <dwh...@dw...>]

On Thu, 1 Sep 2016 19:37:43 -0400, luke wallace <luk...@gm...> wrote:
> Let's try to use wishful thinking in order to reinvent how to make lisp
> more accessible and useful to complete newbies.

Thanks for sharing your thoughts!  I'd prefer this discussion be public, if possible,
so that everyone can share in the results.

> The editor would do all the box drawing for
> you, and be saved as lisp in source files (the editor would just display it
> in readable format once opened).

As I understand it, you want to have a bidirectional translation within the
editor, so that what is *saved* is traditional Lisp code, but what is *viewed*
is some more readable format.

Interestingly enough, bidirectional translation is already *partly* possible with
the readable notations right now. We already have programs that translate each way.
Presuming you choose the top level (sweet-expressions), you could convert to sweet,
edit, then translate back on save.  It's not ideal though (see below).

However, there are several issues with bidirectional translation (translations on read and save):
1. You *really* have to trust the bi-directional translation tools.
    Even the slightest defect can cause problems, because "what you run" isn't "what you see".
2. You have to be careful on handling comments.
    The current sweetening routine drops comments outside the top level.
    This lossiness is not ideal, but for its intended purpose it's okay... but for bidirectional
    work it's not a good thing.
3. You either lose the formatting on both ends, or you spend a *lot* of time trying to
    "fix up" formatting.  If someone formats it in a certain way in the traditional Lisp code,
    it's tricky to retain that, and the other way as well.
4. If you work with other people who use different formatting, you can end up
    with a lot of pseudo-changes, which would greatly interfere with version control systems
    (it'd look like you changed a lot of lines, when it was just reformatted).
    This is easy to solve: Pick a specific formatter and its options, and *always* run that
    before saving.

It's certainly *possible* to do bidirectional translations.  But it's a lot of work.
Most GUI programming tools, for example, store a representation of the GUI display
and only do 1-way translations from the GUI to the underlying representation.
You're certainly welcome to try some things out - I'm a little skeptical that it's worth
the work, but the proof is always in the doing.

--- David A. Wheeler

[Readable-discuss] Readable Lisp 2.0, brainstorming

[luke w. <luk...@gm...>]

Let's try to use wishful thinking in order to reinvent how to make lisp
more accessible and useful to complete newbies.

My idea is that by converting lisp into a simplified abstract syntax tree
form, and then performing formatting options on that abstract syntax tree
(such as prefixing parts of it with syntactic sugar, or compacting some
levels of the tree, or reformatting the order of operators and operands, we
are able to create human-readable formatting for conventional lisp code

Below are two theoretical examples:

http://i.imgur.com/JNOXQ4M.png

You may be thinking, "the end result looks a lot like coding in simpler
languages, like Python or Ruby". That is correct, the novel thing about
this, if created, is that you would still be coding in conventional lisp,
with formatting to make it easier to understand, not actually changing the
underlying syntax. This would, in theory, allow oneself to code in a human
readable way, without losing the power of lisp.

Comments, ideas, etc. are welcome.

[Readable-discuss] S-exploration

[David A. W. <dwh...@dw...>]

Fyi, there is an interesting s-expression visualization tool here:
https://github.com/ympbyc/s-exploration/
--- David A.Wheeler

[Readable-discuss] "Readable" 1.0.9 posted

[David A. W. <dwh...@dw...>]

"Readable" library version 1.0.9 is now available!

It has various minor changes.

--- David A. Wheeler

[Readable-discuss] Plan to post updated "readable" library

[David A. W. <dwh...@dw...>]

I plan to release an updated "readable" library, based on the current development version.
The changes are relatively small, and most of the changes are for Common Lisp.
If there are any issues, please post quickly.

Thanks!

--- David A. Wheeler

[Readable-discuss] wisp as draft SRFI-119

[Arne B. <arn...@we...>]

Hi,

Wisp is now in draft state as SRFI-119: http://srfi.schemers.org/srfi-119/

The version up there is mostly what we discussed here. The main part
which changed are the clarifications.

- To represent tail notation like (define (foo . args)), either avoid
  a linebreak before the dot as in define : foo . args or use a double
  dot to start the line: . . args. The first dot mark the line as
  continuation, the second enters the scheme code.

- A dot as symbol at the end of a line is reserved for potential
  future use. It should be a syntax error if the next non-empty line
  starts with non-zero indentation. A lone dot at the end of a line
  calls for hard to catch errors.

- A dot as only symbol in a line has no useful meaning: the line is by
  definition empty. As such, a dot as only symbol on a line is also
  reserved for future use and should be treated as a syntax error to
  avoid locking out future possibilities.


The part I like best in the draft is the example which shows all
features of wisp (including compatibility with curly infix)
in just 7 lines:


define : factorial n
__  if : zero? n
____   . 1
____   * n : factorial {n - 1}

display : factorial 5 
newline


Best wishes,
Arne

Re: [Readable-discuss] :depends-on "readable" not working

[David A. W. <dwh...@dw...>]

On Sat, 06 Dec 2014 12:17:31 -0800, Alexander Dunn <dun...@ic...> wrote:
> Hi readable, ...
> If I execute (readable:enable-sweet) in the REPL before I execute (ql:quickload “help"), it compiles just fine.  But, I don’t understand why the same doesn’t work when I put (readable:enable-sweet) inside my help.lisp.  

Sorry about the bug.  I just posted to the "devel" branch an updated version of the "readable" library that fixes the bug.

This is a pretty important problem, so I plan to post an update to the package tonight on the master branch.  If anyone objects, please let me know asap.

The change is pretty straightforward; here's a quick summary.  This version turns the enable-* functions into macros so that they can invoke "eval-when".  During compilation the macros can only call functions that are *already* compiled, so the enabling macros have been moved into a separate file (so we can easily ensure that the macros only call already-compiled functions).

It'll take a little time before QuickLisp picks up the updated master branch version.  As a temporary workaround, I suggest replacing any call to (readable:enable-sweet) with:
(eval-when (:compile-toplevel :load-toplevel :execute)
  (readable:enable-sweet))

Once QuickLisp picks up the update, the problem should disappear.

--- David A. Wheeler

Re: [Readable-discuss] :depends-on "readable" not working

[David A. W. <dwh...@dw...>]

On Sat, 06 Dec 2014 12:17:31 -0800, Alexander Dunn <dun...@ic...> wrote:
> Hi readable, 
> Thanks for making this fantastic package!  I’m new to LISP and this has made LISP programming far more appealing.  
> I’m trying to use the Quicklisp package “readable" as a dependency in a package I created using QuickLisp’s quickproject....

Okay, I'm back at a real computer instead of a smart phone.

Try this: In your code, replace the line:
(readable:enable-sweet)

with the following:
(eval-when (:compile-toplevel :load-toplevel :execute)
  (readable:enable-sweet))

It worked for me, but I want to know if it works for you.

If it *does* work, then the next step is to decide what to do about it longer term.
I certainly welcome comments from someone else.
But let's get Alexander Dunn back to doing good things, first,
and we then can decide how to make sure no one else has a problem.

--- David A. Wheeler

Re: [Readable-discuss] :depends-on "readable" not working

[David A. W. <dwh...@dw...>]

On Sat, 06 Dec 2014 12:17:31 -0800, Alexander Dunn <dun...@ic...> wrote:
> If I execute (readable:enable-sweet) in the REPL before I execute (ql:quickload “help"), it compiles just fine.  But, I don’t understand why the same doesn’t work when I put (readable:enable-sweet) inside my help.lisp.  

On first blush, this looks like missing 'eval-when' clauses in the "readable" package.

--- David A. Wheeler

Re: [Readable-discuss] :depends-on "readable" not working

[David A. W. <dwh...@dw...>]

On Sat, 06 Dec 2014 12:17:31 -0800, Alexander Dunn <dun...@ic...> wrote:
> Hi readable, 
> 
> Thanks for making this fantastic package!  I’m new to LISP and this has made LISP programming far more appealing.  

Great!

> 
> I’m trying to use the Quicklisp package “readable" as a dependency in a package I created using QuickLisp’s quickproject.  
> 
> Attached is an example project to demonstrate my problem.

Thanks for the report! I can reproduce the problem, but I'm not sure how to best fix it,
and I have to run off right now.

Anyone else have thoughts?

I can reproduce on Linux using:
mkdir /home/dwheeler/local-projects/help
... unzipped and put .lisp, .asd, etc. in that directory ...
sbcl
(push #p"/home/dwheeler/local-projects/help/" asdf:*central-registry*)
(ql:quickload "help")

--- David A. Wheeler

[Readable-discuss] :depends-on "readable" not working

[Alexander D. <dun...@ic...>]

Hi readable, 

Thanks for making this fantastic package!  I’m new to LISP and this has made LISP programming far more appealing.  

I’m trying to use the Quicklisp package “readable" as a dependency in a package I created using QuickLisp’s quickproject.  

Attached is an example project to demonstrate my problem.  I’ve added readable to depends-on in package.lisp and written a sample hello-world function that uses the syntax made possible by readable.  I execute (ql:quickload “help”) and it fails to compile because it’s incorrectly trying to interpret it as Common Lisp rather than the syntax that should be activated with readable.

If I execute (readable:enable-sweet) in the REPL before I execute (ql:quickload “help"), it compiles just fine.  But, I don’t understand why the same doesn’t work when I put (readable:enable-sweet) inside my help.lisp.  

To make clear that my problem is specific to the readable package, I’ve also made use of the 1am package.  You can see that a function written using 1am symbols compiles and executes just fine without first loading it in the REPL beforehand.  

I suspect I’m missing something obvious. 

Thanks a lot,
Alex

Re: [Readable-discuss] Discussion: Should leading "." in sweet-expressions have wisp semantics?

[Arne B. <arn...@we...>]

Am Freitag, 28. November 2014, 08:38:26 schrieb David A. Wheeler:
> Perhaps more interestingly, I would expect this:
> foo bar
>   aaa bbb ccc
>   . ddd eee fff
>   ggg hhh
> =>
> (foo bar (aaa bbb ccc) ddd eee fff (ggg hhh))

Yepp, that’s how wisp would transform that. It’s the core reason for
the existence of the leading-period rule: Making most kinds of general
tree/list-of-list structures look similar.

I know that that’s not the best description of its effect, but I don’t
find a better description right now… I hope you understand what I mean
anyway.

Best wishes,
Arne
--
Konstruktive Kritik: 

- http://draketo.de/licht/krude-ideen/konstruktive-kritik

-- 
1w6 sie zu achten,
sie alle zu finden,
in Spiele zu leiten
und sacht zu verbinden.
→ http://1w6.org

Re: [Readable-discuss] Discussion: Should leading "." in sweet-expressions have wisp semantics?

[David A. W. <dwh...@dw...>]

Arne can best give the wisp answer, but here is what I would expect:


1.:
foo bar
 . aaa bbb ccc
 . ddd eee
=>
(foo bar aaa bbb ccc ddd eee)


2.:

foo bar
 . aaa bbb . ccc
 . ddd eee
Error.  Period after leading period.

Perhaps more interestingly, I would expect this:
foo bar
  aaa bbb ccc
  . ddd eee fff
  ggg hhh
=>
(foo bar (aaa bbb ccc) ddd eee fff (ggg hhh))





On November 28, 2014 5:59:14 AM EST, "Jörg F. Wittenberger" <Joe...@so...> wrote:
>Am 27.11.2014 um 20:03 schrieb Arne Babenhauserheide:
>> Am Donnerstag, 27. November 2014, 08:47:49 schrieb David A. Wheeler:
>>>> However within "normal" s-expressions or neotheric expressions I'd
>have
>>> second thoughts.  How would this be parsed?:
>>>
>>>> foo bar
>>>>  . aaa . bbb ccc
>>>
>>> I agree, that should be an error. It doesn't really make any sense
>to me either. I expect this would continue to be ok:
>>>
>>> aaa bbb . ccc
>>> =>
>>> (aaa bbb . ccc)
>>>
>>> And the following would still be an error:
>>> aaa bbb . ccc ddd
>
>+1
>
>> 
>> That’s also what wisp does: The leading dot is interpreted as
>> continuation if it’s the first character in a line in
>> indentation-sensitive code.
>> 
>> It would be cool to see sweet and wisp move closer together here!
>
>+1
>
>How does wisp deal with these?
>
>1.:
>
>foo bar
> . aaa bbb ccc
> . ddd eee
>
>2.:
>
>foo bar
> . aaa bbb . ccc
> . ddd eee

--- David A.Wheeler

Re: [Readable-discuss] Discussion: Should leading "." in sweet-expressions have wisp semantics?

[Jörg F. W. <Joe...@so...>]

Am 27.11.2014 um 20:03 schrieb Arne Babenhauserheide:
> Am Donnerstag, 27. November 2014, 08:47:49 schrieb David A. Wheeler:
>>> However within "normal" s-expressions or neotheric expressions I'd have
>> second thoughts.  How would this be parsed?:
>>
>>> foo bar
>>>  . aaa . bbb ccc
>>
>> I agree, that should be an error. It doesn't really make any sense to me either. I expect this would continue to be ok:
>>
>> aaa bbb . ccc
>> =>
>> (aaa bbb . ccc)
>>
>> And the following would still be an error:
>> aaa bbb . ccc ddd

+1

> 
> That’s also what wisp does: The leading dot is interpreted as
> continuation if it’s the first character in a line in
> indentation-sensitive code.
> 
> It would be cool to see sweet and wisp move closer together here!

+1

How does wisp deal with these?

1.:

foo bar
 . aaa bbb ccc
 . ddd eee

2.:

foo bar
 . aaa bbb . ccc
 . ddd eee

Re: [Readable-discuss] Discussion: Should leading "." in sweet-expressions have wisp semantics?

[Arne B. <arn...@we...>]

Am Donnerstag, 27. November 2014, 08:47:49 schrieb David A. Wheeler:
> > However within "normal" s-expressions or neotheric expressions I'd have
> second thoughts.  How would this be parsed?:
> 
> > foo bar
> >  . aaa . bbb ccc
> 
> I agree, that should be an error. It doesn't really make any sense to me either. I expect this would continue to be ok:
> 
> aaa bbb . ccc
> =>
> (aaa bbb . ccc)
> 
> And the following would still be an error:
> aaa bbb . ccc ddd

That’s also what wisp does: The leading dot is interpreted as
continuation if it’s the first character in a line in
indentation-sensitive code.

It would be cool to see sweet and wisp move closer together here!

Best wishes,
Arne

Re: [Readable-discuss] Discussion: Should leading "." in sweet-expressions have wisp semantics?

[David A. W. <dwh...@dw...>]

> However within "normal" s-expressions or neotheric expressions I'd have
second thoughts.  How would this be parsed?:

> foo bar
>  . aaa . bbb ccc

I agree, that should be an error. It doesn't really make any sense to me either. I expect this would continue to be ok:

aaa bbb . ccc
=>
(aaa bbb . ccc)

And the following would still be an error:
aaa bbb . ccc ddd




On November 27, 2014 6:04:47 AM EST, "Jörg F. Wittenberger" <Joe...@so...> wrote:
>Am 26.11.2014 um 23:32 schrieb David A. Wheeler:
>> This is a request for comment:
>> In sweet-expressions, should a line beginning with "." have the same
>semantics as wisp?
>> 
>> In wisp, I understand that a line beginning with "." is interpreted
>as a sequence of expressions at the same level. E.G.,:
>> foo bar
>>   . aaa bbb ccc
>> =>
>> (foo bar aaa bbb ccc).
>> 
>> A "." with a single n-expression is interpreted this way now. 
>Currently, it's illegal to have more than 1 n-expression on a line;
>this change would relax that rule.
>> 
>> Anyway, thoughts welcome, pro or con.
>
>For indentation sensitive mode as the first element on a line: I fail
>to
>see what damage it could do.  => pro
>
>However within "normal" s-expressions or neotheric expressions I'd have
>second thoughts.  How would this be parsed?:
>
>foo bar
> . aaa . bbb ccc
>
>Here I'd prefer to get a parsing error.  => con
>
>/Jörg
>
>------------------------------------------------------------------------------
>Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
>from Actuate! Instantly Supercharge Your Business Reports and
>Dashboards
>with Interactivity, Sharing, Native Excel Exports, App Integration &
>more
>Get technology previously reserved for billion-dollar corporations,
>FREE
>http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
>_______________________________________________
>Readable-discuss mailing list
>Rea...@li...
>https://lists.sourceforge.net/lists/listinfo/readable-discuss

--- David A.Wheeler

Re: [Readable-discuss] Discussion: Should leading "." in sweet-expressions have wisp semantics?

[Jörg F. W. <Joe...@so...>]

Am 26.11.2014 um 23:32 schrieb David A. Wheeler:
> This is a request for comment:
> In sweet-expressions, should a line beginning with "." have the same semantics as wisp?
> 
> In wisp, I understand that a line beginning with "." is interpreted as a sequence of expressions at the same level. E.G.,:
> foo bar
>   . aaa bbb ccc
> =>
> (foo bar aaa bbb ccc).
> 
> A "." with a single n-expression is interpreted this way now.  Currently, it's illegal to have more than 1 n-expression on a line; this change would relax that rule.
> 
> Anyway, thoughts welcome, pro or con.

For indentation sensitive mode as the first element on a line: I fail to
see what damage it could do.  => pro

However within "normal" s-expressions or neotheric expressions I'd have
second thoughts.  How would this be parsed?:

foo bar
 . aaa . bbb ccc

Here I'd prefer to get a parsing error.  => con

/Jörg

[Readable-discuss] Discussion: Should leading "." in sweet-expressions have wisp semantics?

[David A. W. <dwh...@dw...>]

This is a request for comment:
In sweet-expressions, should a line beginning with "." have the same semantics as wisp?

In wisp, I understand that a line beginning with "." is interpreted as a sequence of expressions at the same level. E.G.,:
foo bar
  . aaa bbb ccc
=>
(foo bar aaa bbb ccc).

A "." with a single n-expression is interpreted this way now.  Currently, it's illegal to have more than 1 n-expression on a line; this change would relax that rule.

Anyway, thoughts welcome, pro or con.

--- David A. Wheeler

Re: [Readable-discuss] wisp and readable - common expressions

[Arne B. <arn...@we...>]

Am Freitag, 21. November 2014, 19:31:54 schrieb David A. Wheeler:
> David A. Wheeler:
> > wisp:
> >     define : hello
> >       display "Hello World!"
> >       newline
> >     define : hello2 who
> >       format #t "Hello ~A!\n" who
> 
> If you're using wisp you probably do *not* want to use
> a neoteric expression as the *first* element on a line
> (unless you're actually calculating what function/procedure to call).
> So teach that style rule, and you avoid that (wisp) gotcha.

I don’t consider it a gotcha to always treat the first element on a
line as a function call. But the elegancy of neoteric expressions only
shows with seeing a single item on a line as variable an not as
function call: Then defining a function and calling it becomes mostly
symmetric. But only mostly.

In wisp the inline colon provides a similar symmetry.

> However, in *both* wisp and sweet-expressions there are MANY 
> uses for neoteric-expressions in the REST of the line.
> For example, here's a line from math.slisp:
>   cons car(lyst) flatten-operation(op cdr(lyst))

For my taste of code, that already becomes too deeply nested: The last
part is quite hard to parse. I had trouble keeping in mind that op is
just a parameter. Alternative:

   cons : car lyst
          flatten-operation op : cdr lyst

While car(lyst) looks very readable to me, 

    flatten-operation(op cdr(lyst)) 

already looks complex. It looks as if op and cdr belong together. That
might actually be one reason why C-like languages add a comma for
separating arguments:

    flatten-operation(op, cdr(lyst)) 

Now op and cdr are clearly separated. But here, s-expressions actually
seem more readable to me:

    (flatten-operation op (cdr lyst))

This keeps together what belongs together. 

In my opinion, nested function calls in C-like function notation
generally look worse than as s-expressions. They look really good when
going only one level deep, but nested they are strange.

> It's pretty common to have several short parameters on a line;
> neoteric-expressions are quite useful in this case.  A quick grep finds many examples.

> I always use the "car(lyst)" form when it's a call, never the "(car
> lyst)" form, so there's no problem of "which format do I use".
> Being readable in great part depends on building on what people
> already know, and this is the more familiar notation.  Besides,
> neoteric-expressions are *already* supported in curly-infix.

They are supported in SRFI-105, but if I tested it correctly not
activated when explicitly activating curly-infix.

I agree on the readability, by the way, just not on the tradeoff
against simplicity.

Best wishes,
Arne
-- 
1w6 sie zu achten,
sie alle zu finden,
in Spiele zu leiten
und sacht zu verbinden.
→ http://1w6.org

Re: [Readable-discuss] wisp and readable - common expressions

[Arne B. <arn...@we...>]

Am Freitag, 21. November 2014, 18:48:16 schrieb David A. Wheeler:
> It is obviously possible to change the semantics of leading period.
> I am hesitant to add yet another operator; you may disagree but I
> really tried to make it a short list.

I know you did. Every single additional operator came from a structure
you found in code which wasn’t represented elegantly enough in
sweet. I decided to forgo that goal and instead assume that the coding
style will adapt to some degree to the language as long as the
technically necessary features as well as 90% of the general cases are
represented elegantly.

Since the leading period is already almost part of the syntax, it
might have a much lower conceptual cost than other operators. That’s
why I chose it for that, after all ☺

> I also really wanted to fix the notation, but leading period is
> basically never used so that is probably not really a problem.
> 
> Let me think about it.

Happily :)

Best wishes,
Arne