On Jan 16, 2013 3:29 PM, "David A. Wheeler" <dwhee...@dwheeler.com> wrote:
>
> > If we separate the 2 issues, I feel the no-blank-lines is the more
> > problematic of them. In Python, I'm fine with most of my defs being
> > indented because they're class methods, but couldn't live without new
lines.
> > Do you agree?
>
> I don't *exactly* agree, though you may be missing an element of
sweet-expressions that makes end-on-blank-lines work. But first, my
priorities.
>
> My current view is that the more important requirement is that the REPL
and file format need to be exactly the *same* in a Lisp-based system. In
Python you often cannot cut-and-paste from files into the command line
("REPL"), because Python files and the REPL have different blank-line
semantics. (Technically, the Python spec only covers files, but that's a
useless nuance.) That's actually a problem in Python today, and annoys me
sometimes. In a Lisp such a difference would be crazy, because Lisps are
programmable programming languages where experimentation is common.
>
I'll defer to you on this though I don't feel this is such a big problem in
python; GUI shells solve it by distinguishing pressing Enter from pasting
Enter, and/or by requiring ctrl+Enter (or backspacing the indent then
Enter) to terminate multiline command (IIRC dreampie does the latter).
Unfortunately, lisp doesn't have python's : hint that the expression will
be a multiline one.
It's indeed annoying in the terminal. IIRC ipython has some magic %paste
syntax to paste an arbitrary block. IOW, the file/repl tension does
justify a construct like this, but it's a REPL only construct...
> Now for blank lines. Blank lines ending an expression actually isn't
bad, even in a larger program, because of the rule that comment-only lines
(possibly indented) are completely ignored, and do NOT end an expression.
I agree that without that rule it'd be hideous to use, but using
comment-only lines to vertically separate material actually works very
cleanly.
>
Ah, indeed I missed that!
It changes a lot of priorities in my arguments, because if I'd keep the
indentation and only use this for empty lines, that feels a petty -
perhaps I should just live with empty comments and not need a new construct
at all; and let people who also want to reset indentation have their way...
> It's not insane to use some marker to mean "end of expression", several
languages do that. Indeed, sweet-expressions could be modified to that
easily enough. But then users have to remember to do that after every
expression. If REPL use is rare, that'd be fine. But I expect lots of
people to use the REPL, often, and I want the REPL to be very pleasant to
use. It's hard to beat "enter a blank line to evaluate".
>
Agreed. I absolutely hate SQL prompts that don't execute until I add a ;
> Well, the current notation is obviously not a disaster, since we've
written programs without it. But when the variables involve modest amounts
of calculation, it gets harder to see what you're doing than I'd prefer,
because it's easy to suddenly require more paren-nesting than is typical in
other languages.
>
> Contrast:
>
> let ((x cos(f(c))))
> ! dostuff x
>
> with:
> let <* x cos(f(c)) *>
> ! dostuff x
>
> In one-variable lets, a common mistake is to forget to embed the variable
in double-parens. Since the parens are also usually used for the
expression calculation, it can be easy to miss. Making it possible to
visually distinguish the outer "parens" that create the variable list, from
the internal parens used for the expression, makes it clearer which parens
are more structural vs. the ones involved in the variable calculation.
That, in turn, makes it easier to notice the omission of doubled parens for
one variable.
>
"<*" is 2 chars, "((" is 2 chars. Some of your win here is just from using
spaces to set apart the delimiters.
Isn't this better addressed by schemes that allow [..] in place of (..):
let [ (x cos(f(c)))
(y sin(f(c))) ]
! dostuff x y
which is more homoiconic by preserving the nesting level.
I feel that let's structure is truly annoying, but it's not the notation's
job to hide that if it becomes less homoiconic; I'd rather fix the
construct and use a let1 macro.
> or:
> let <* x $ cos $ f c *>
> ! dostuff x
>
Personally I'm not (yet?) a big fan of $.
I have even more reservations about \\ usage:
let <* x cos(f(c)) \\ y sin(f(c)) *>
where the list depth hinges on the fact that there are 2 elements between
the \\.
I see how such constructs are appealing in-line once you're used to them,
but this makes me ask: could you lift $ and/or \\ to a separate layer from
indent processing, so they remain available inside regular (..) lists?
> As it turns out, the new ruleset for <*...*> that I just posted is quite
simple, and it basically only requires one extra line in the spec to handle
the on-the-same-line case.
>
I must admit I haven't even tried to keep up with your grammar work. I'll
try to take a look - the whole thing is much shorter than the one-at-a-time
mails made me think :-)
> > IMHO, it's very ugly that "example grid ..." are indented when the body
of
> > the library isn't. Indentation should be (at least) non-decreasing!
>
> Hmm, I view this as a *solution*. There's only so much horizontal and
vertical space. If nearly the entire file is indented to several levels,
that means there's less (horizontal) room to express actual content.
>
> I completely agree that indentation should *NORMALLY* be non-decreasing,
but the point of this structure is to "restart" indentation so you're not
stuck writing all content on the right edge.
>
Understood.
I'm not against having a way to restart indentation; I just wanted to keep
the *option* to not restart it to 0, as a matter of taste.
Though in light of empty comments always being available, I'm ok with a
construct that always forces indent to 0, if it's simpler.
> Fair enough. But no other character pairs, other than <..>, are
available in least-common-denominator ASCII. Also, while I think <*...*>
is important, I do not think many lines of code will directly *use* these
symbols (especially in the multi-line case). So even if I COULD find
another character pair (and ), I don't think I would want to use up
valuable single-character pairs on this functionality; it's perfectly fine
to use multi-character markers.
>
Sure, it must be multi-char. I was think more in the directions of e.g. #(
... )# but those might well be taken for things like vectors.
> That said, if there are multi-character symbols that you think would
better "feel" like list start/end, let us know! I thought about using "<<"
and ">>", which look like guillemets and probably "feel" more like list
start/end. But Scheme systems like scsh already use these symbols (e.g.,
use >> for append-to-file).
>
I had same thoughts of << or <<< (also alluding to shell here-document
syntaxes, and to {{{...}}} blocks in some wikis and folding code editors).
But I really don't care much.
For me it triggerred the dont-start-a-list idea requiring one to also use
parens - (<* ... *>) or (!#start ... #!end) - but it's not a reason I'd
accept or reject that idea.
--
Another very unbaked idea: perhaps we can take a hint from typography and
formats such as reStructuredText, markdown and emacs outline-mode (which
all took that hint):
Represent most structure using indentation, but some structure above that
using several levels of headings.
E.g.
# library foo bar
## export ...
## import ...
## begin
define ...
define ...
#
You probably need something like the lone # at the end to indicate the H1
section ended. (And of course the choice of # is problematic.)
It's unclear whether the number of # should increase or decrease as you go
deeper. Decreasing has a nice explanation as "negative indentation" (the
char must then be ยก or at least ? <wink>), but I think only increasing
works for a finite-lookahead parser.
I think like this direction on aesthetic grounds, but I suspect the
practical convenience of having some reader macro entering the t-expr
parser in the middle of s-expr parsing will prevail.
------------------------------------------------------------------------------
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122712
_______________________________________________
Readable-discuss mailing list
Readable-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/readable-discuss
