I said:
> > I think this is just broken. Devising a human-readable
> > data notation in 2013 that cannot work with non-ASCII characters is,
> > in my opinion, a complete non-starter.
> > Even if you only use ASCII, this notation ignores the problem of
> > variable-width fonts (I'm currently writing this using a variable-width
> > font).
Alan Manuel Gloria:
> Even in fixed-width fonts, many (all?) CJK chars are displayed
> double-width, making the term "fixed width" a misnomer. And then
> there's encoding troubles...
Wow, even *more* problems!!!
Those are even *more* reasons to not accept "magic position" semantics.
I thought my list of problems was scarey enough...!
> As an aside, Haskell gets away with this (magic column position)
> because it has evolved in such a way that there is now One True
> Implementation for it. GHC AFAIK handles CJK quite well, and ...
But that's obviously not true for Scheme, or really for most Lisps
(and I'd the notation to work with many other Lisps too).
I just don't think we should import that kind of improbable assumption
into our notation, *especially* without some world-ending rationale
for needing it.
> Pretty much the only use major use case for the "line-ending ENLIST" I
> can see is:
...
> So: line-ending ENLIST has its niche. It just doesn't seem to be a
> powerful enough niche (I personally think it's bad style to put
> complicated code in the conditions of cond, or if, or whatever, so
> something like has?(x 'some-property) is acceptable. Arguably in the
> above case {x has? 'some-property} is even clearer, and doesn't even
> need the line-ending ENLIST).
I can think of a use case using Common Lisp defun:
defun x : parameter1 parameter2
! stuff
But I think that is *less* clear than:
defun x (parameter1 parameter2)
! stuff
So basically I'm agreeing with you on that part,
I don't see a use case for line-ending ENLIST
that would justify adding it. So, back to discussing
magic columns...
> > Perhaps even worse, I don't think there's enough justification for WHY we
> > need yet
> > another syntactic construct. ENLIST (either meaning) is not powerful enough
> > to
> > replace any of the existing constructs... so it must be in ADDITION to the
> > rest.
>
> *shrug* If we're willing to sacrifice the "SPLIT" meaning of
> GROUP/SPLIT, and the sheer overwhelming power of SUBLIST, we can use
> ENLIST semantics for both. but we'd have to use the "magic column
> position" ENLIST (with all the implementation baggage that implies).
The magic column semantics make strong assumptions about visual widths
and encodings that are simply absurd in the current international environment,
as noted above.
No matter what, those assumptions are clearly false... and we just keep
identifying
more reasons they are false.
I think any notational change that requires clearly-false assumptions
has to bring with it a very long list of concrete advantages.
I don't see that type of gain, relative to our current draft.
We have a lot of use cases for SUBLIST for example, and many examples
of SPLIT being useful. I don't think ENLIST with magic positioning
has that kind of strength; I haven't developed or seen use cases that are
even STARTING to be THAT compelling.
> > And every new construct we add means we have to define their interactions;
> > that complexity increases O(n^2) where n is the number of constructs.
>
> Yes, and GROUP/SPLIT and SUBLIST's interaction is simple: SUBLIST only
> consumes until the end of the current expression, and GROUP/SPLIT (in
> its SPLIT incarnation) ends the current expression. Meaning:
>
> a $ b \\ c $ d \\ e
>
> is:
>
> (a b)
> (c d)
> e
>
>
> COLLECTINGLIST is a datum as far as GROUP/SPLIT and SUBLIST is
> concerned (as long as the GROUP/SPLIT or SUBLIST is outside the
> COLLECTINGLIST). Inside a COLLECTINGLIST, GROUP/SPLIT and SUBLIST's
> effect is trumped by the ending *>.
I agree with you about the GROUP/SPLIT, SUBLIST, and COLLECTINGLIST
interactions;
there's a fairly obvious way for them to interact. But that's why adding yet
another
operator is concerning for me; I want to *keep* it clear.
So while I appreciate your efforts to make concrete exactly what ENLIST would
entail, I'm becoming convinced that we should definitely *NOT* add any form of
ENLIST to the sweet-expression notation. The line-ending one is too limited,
and
the magic-column version depends on assumptions that we KNOW are widely false.
Forcing to ASCII-only doesn't deal with variable-width types and is absurd since
not everyone uses English for everything.
In general, depending on really knowing the widths of different characters is
just
absurd in an internationalized world. And even after all that, neither
interpretation
has the strength of strong use cases that just can't be reasonably done another
way.
If anyone has a strong counter-argument, I'd certainly like to hear it ASAP.
What I want to see is a load of use cases that are really important and
really hard to do otherwise... so much that false assumptions are acceptable
:-).
I really do want to hear all ideas, but I think we've delved so deeply into
this idea
that at least one Balrog has shown up. Lacking Gandalf's flame of Anor, I'm
planning on
running to Moria's exit :-).
--- David A. Wheeler
------------------------------------------------------------------------------
The Go Parallel Website, sponsored by Intel - in partnership with Geeknet,
is your hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials, tech docs,
whitepapers, evaluation guides, and opinion stories. Check out the most
recent posts - join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Readable-discuss mailing list
Readable-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/readable-discuss
