Alan Manuel Gloria wrote: > Subject: [Readable-discuss] Proposal: ENLIST (Arne's ":") > Here's the semantic of ENLIST:
Whew! Thanks for drilling down a potential semantic. I do not think we should do this (for reasons described below), but the first step is to have something concrete enough to discuss, and I really appreciate that you've turned vague discussions into details. > 1. ENLIST-at-the-start: ... Plausible enough. > 2. ENLIST-inline: > > When found inline, ENLIST detects its column location. It then acts as > if ithere were an EOL followed by an indentation to its column location. > > Specifically, to determine the indentation text to insert: > > 2.1. Copy the current line's indentation (tabs, spaces, and !) directly. > 2.2. Any non-whitespace character on the current line after the > line's indentation, and before the ":" being considered, is replaced > with a space. > > CAVEAT: Because a "character" may vary between different encodings, > and because different Lisplike's have different capabilities regarding > reading text in different encodings, ONLY ASCII CHARACTERS ARE > CONSIDERED. If 2.2 above finds a character that is not in the ASCII > domain (0->126) then it throws an error. Ack! Ack! Ack! 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). > Programmers are thus restricted in that non-ASCII characters cannot be > used before an ENLIST on the same line. I understand *why*, but to me, that limitation suggests that it's just too broken to accept. I really appreciate the effort to formalize this, but with these details exposed to the light of analysis, I think this particular baby is pretty ugly. :-). Or is that ^.^ ? There was another variation of ENLIST that closed matching parens at the end of the line; that at least wasn't sensitive to visual character widths, etc. Not that I'm sold on that variant either, but at least it didn't have that (to-me-fatal) flaw. 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. 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. --- 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
