Hi Alan,

(I’m answering to both mails here)

Am Montag, 11. Februar 2013, 11:07:30 schrieb Alan Manuel Gloria:
> Your main contributions seem to be the extended "." behavior (. a =>
> a, . a b -> a b) and the ":" syntax.  I don't see any use, even in
> your examples, of the single-item-on-a-line-is-single-item-list
> behavior.

The reason for that is consistency: Making sure that when you learn a minimal 
set of rules you can understand the structure of all code you see.

> That's fine and all, but suppose I'm defining a method for Guile GOOPS?
> define-method : hack (x <cat>)
> !             do-hack-on-cat x
> Oops, except hack only works on cats anyway, so I'll just optimize
> things (because profiling shows that method calls in GOOPS take up all
> my time, LOL) and turn hack into an ordinary function:
> define : hack x
> !             do-hack-on-cat x
> Oh, no!!  Now I have to adjust the indentation of everything inside
> it!  Luckily hack x just contains do-hack-on-cat, so all I need to do
> is adjust that single line.
> define : hack (x <cat>)
> !      do-hack-on-cat x

Well, I’m a Python-Programmer. In Python you run into that everytime you remove 
or add an if. Before I used rectangle-edit, it disturbed me a bit. Now it’s 
quite painless:

C-SPACE M-↓ ↑ C-7 → C-x C-r C-k

There would be a simple way to fix it, though: Make the position of : only 
significant when you want to indent deeper. To make this consistent: Make the 
indentation of a line only relevant for deeper nested lines (child lines). Then 
the following would all be valid code:

if : = a 1

    = a 1

if : = a 1

    = a 1

If the indentation is equal or lower than a previous indentation layer, the 
bracket of that indentation layer gets closed.

> 3.  You need to explicitly specify how double-width CJK characters are
> handled when found before a ":" (ban them in code?  But what about
> strings and #| |# comments?).  Do we treat them as single character
> columns (easy implementation, but potentially confusing, and possibly
> limiting international code) or do we treat them as double character
> columns (need to consider encoding, and implementations need to keep a
> list of all such double-width characters)?

Being able to reduce indentation of later lines (as long as they stay child 
lines) would also solve this for most cases.

> ":" seems to put a lot of pressure on implementations, using your
> current explanation.  Perhaps we can change ":" to be more local (i.e.
> it won't require keeping track of column position, and won't cause
> cascading affects when text before it changes)?

For me the inline : mainly exists for consistency: It generalizes GROUP.

Essentially GROUP adds a new indentation layer, so you could just allow using 
it inline. But I use : for group, because I think that \\ looks alien to normal 
text and so it hampers readability for all people who aren’t used to 

Inline : has nice features - if used sparingly - and I think it improves the 
readability of function definitions a lot. But if it were not necessary for 
double brackets, I would not propose adding it.

Indentation based lisp syntax MUST support double brackets. That’s why : 
exists. Also it MUST support continuing the parameter list after a function 
call. That’s why . exists.

Am Montag, 11. Februar 2013, 12:23:20 schrieb Alan Manuel Gloria:
> 1.  It seems that it currently doesn't handle ":" in the middle of a line, 
> yet.

Jepp. It’s a quite limited late-night hack. It gives a draft how that parsing 
could work, but I did not get to implementing inline :.

> 2.  It seems that multiple ": " at the start of each line are ignored,
> and only the last one is used.  So the following is possibly (?)
> valid:
> define foo(bar)
> : cond
> : : meow?(bar)
> : : : cat bar
> : : woof?(bar)
> : : : dog bar
> : : else
> : : : error 'foo "error!"

It’s not valid, since the “: cond” would start at the same indentation as the 
define, but the converter would process it. So this is a bug in the converter…

> How about this semantic instead?
> ":" introduces a (, and a promise to add ) at the end of that line.

To make it more general, you can add that the ) is added before the first less 
or equally indented line, but that a later line can add a new indentation layer.

That would give the full behaviour (defining an indentation layer) while 
keeping the enhanced readability for deeply nested functions.

> In the first place, ":" can't support the shown cond-pattern.  So
> without $, it would look like (without probe):
> define-stream stream-map(f s)
>   cond
> With probe:
> define-stream stream-map(f s)
>   probe
>     cond

I think I see the merit of $ now: It wraps the rest of the code in a function 

> A new synthesis?
> Perhaps we can *keep* GROUP/SPLIT \\, SUBLIST $, and COLLECTINGLIST <*
> *>, use the EXTENDPERIOD . a b, and add the new LINELIST :
> what you think?

That would be the exact opposite of why I wrote. Instead of having 3 syntax 
elements, we now have 4 plus the . (which is just a generalization of (. a)).

My intention was not to add more syntax overhead, but to reduce it by 
generalizing existing functionality.

There is required stuff: double brackets and continuing the parameter list. 
Let’s see how many of the general usecases we can fit by just using the 
solutions to those. They must be there anyway, so generalizing them does not 
have a (high) cost. It might actually make the code easier to understand (and 
that way reduce the cost for the syntax), because the symbols then always have 
a fixed meaning.

Additionally there is syntactic sugar which optimizes some rough edges. That 
isn’t required and adds overhead for those who want to learn the language. So I 
think it should be kept at a minimum: Keep in mind that every additional 
syntax-element has a price, so its benefit has to be higher than that price to 
merit an addition.

Best wishes,
A man in the streets faces a knife.
Two policemen are there it once. They raise a sign:

    “Illegal Scene! Noone may watch this!”

The man gets robbed and stabbed and bleeds to death.
The police had to hold the sign.

…Welcome to Europe, citizen. Censorship is beautiful.

   ( http://draketo.de/stichwort/censorship )

Attachment: signature.asc
Description: This is a digitally signed message part.

Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013 
and get the hardware for free! Learn more.
Readable-discuss mailing list

Reply via email to