On 2/18/13, David A. Wheeler <dwhee...@dwheeler.com> wrote:
> 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
> :-).
Well, it's very easy to describe ENLIST informally:
1. The ":" marker, called ENLIST, marks a new "indent level" without
requiring a separate line. This basically means that you can consider
":" as a newline, followed by an indentation to that position.
And with ENLIST, you get most of what you want for GROUP and a good
portion of SUBLIST - it's just that our current GROUP is GROUP/SPLIT
and SUBLIST's greedy nature is the source of much of its power (for
good or ill).
The problems with ENLIST only arise when ENLIST semantics are looked
at more deeply, and largely only for international code.
One could argue that using non-ASCII characters for code elements
(variable names, function names, etc.) is bad style, every programmer
should have access to fixed-width fonts (otherwise we are revoking
your geek license), and international strings should be implemented
using GNU gettext, the way god intended international text to be
implemented. This means that programming in a strict ASCII-only style
with fixed-width fonts is probably fine, until you want international
text without fooling around with the GNU gettext mark of the beast
_(), someone *else* (like your boss) forcibly revokes your geek
license and prevents you from using fixed-width fonts, and if you're
being a jerk about your PhD dissertation and write all your variable
names as single greek letters in UTF-8, just to make your paper more
interesting ("Γ is a mapping between symbols and their types,
which in our text we will call the 'type-environment'").
We *could* argue that for 90% of the code you'd want to write, the
ASCII-only restriction is not a big problem, and for 90% of the
environments you'd want to program in, having a fixed-width font is a
given. Then we could say that for international text, you can't have
":" after any international parts (not portably, anyway). We lose
some code density (due to loss of SPLIT and SUBLIST) and the ability
to read code meaningfully when presented in a variable-width font, but
gain a very simple (informally) semantic, which is (relatively) easy
for the uninitiated to grasp.
>
> 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 :-).
Dunno 'bout you, but I hear the Mule has taken over the Foundation and
we'd better look for the second one.
--
As an aside, I have no idea how right-to-left text works in Unicode
(arabic text, I think hebrew text too). I do know there are
"direction changed" code points in Unicode. So, more complexity in
order to keep track of "real characters". And then there's text
normalization, where multiple code points should end up being treated
as single characters semantically....
>
>
> --- 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
>
------------------------------------------------------------------------------
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
