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
b
c
if
= a 1
b
c
if : = a 1
b
c
if
= a 1
b
c
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
bash-escaping.
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
call.
> 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,
Arne
--
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 )
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. http://p.sf.net/sfu/sophos-d2d-feb
_______________________________________________ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
