Beni Cherniavsky-Paskin:
> "<*" 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.
I agree that let's structure in the 1-variable case is annoying (I also
sometimes use a let1 macro), and I agree that it's not a notation's job to
*hide* annoying structures.
But if a structure is common and annoying to *use*, it's reasonable to look for
notations that make it *easier* to use. Hiding bad, ease-of-use good :-).
> Personally I'm not (yet?) a big fan of $.
Not a problem. It's grown on me. Once you have it, you find that patterns
where it applies are remarkably common.
> 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,
I think that's the key point. It needs to be easy for people to mentally map a
construct to the underlying list structure, of course, but after a while, you
learn that certain visual patterns are the "easy" way to use a construct. The
same thing happens in other languages; I read the following C construct:
for (i=0; i < max; i++) ...
as a single trivial idea, because it's such a common pattern.
> but this makes me ask: could you lift $ and/or \\ to a separate layer from
> indent processing, so they remain available inside regular (..) lists?
Sure, that's possible. But do we *want* to?
1. That would mean that you'd have to escape them even inside (...).
2. It mildly interferes with backwards compatibility. I'd like traditional
code to mostly work "as is" - in a backward-compatible way - if it's cleanly
formatted. Programs that use symbols $ or \\ would then have problems.
3. I'd like to be able to call down to the underlying reader as much as
possible to implement constructs; doing this *requires* that we override
processing the contents of a list, even if it already has a curly-infix reader.
> 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 :-)
Thanks!
> 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.
It's much simpler. There are some nasty subtleties in *starting* with a
non-zero indent and trying to make it "mean the obvious" in a Lisp-based
language; see the draft SRFI for more details if you're curious. It could work
in other languages, but in Scheme, it's hard because (1) the "read" interface
of Scheme is already fixed, and (2) standard Scheme doesn't support unlimited
unread-char.
> 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.
Yes, "#(" introduces a vector comment. And "#" is busy enough; there are a lot
of nonstandard Scheme extensions that start with "#", so anything starting with
"#" is frankly not safe for use (it'd probably conflict with SOMETHING).
> 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.
Not a crazy idea, but that would only deal with the case for multi-line that
begins on the left edge. That wouldn't deal with the "small let" case, or
anything that has some simple prefix. I know you don't care about "short let",
but *I* do :-).
> 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.
Yes, that's my thinking too.
--- David A. Wheeler
------------------------------------------------------------------------------
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
