On 2/18/13, David A. Wheeler <dwhee...@dwheeler.com> wrote:
> 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).
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. Many simple Scheme's (and Lisps) use the
character=byte encoding (one of the reasons for the de facto R6RS
rejection), and just pass string bytes directly to the system, on the
assumption that the programmer wants that literally. A portable
implementation (one that works across multiple Scheme's) would have to
just know if the interpreter/compiler/whatever it's on has byte=char,
or has a universal UTF-8 assumption (NOT yet universal; our Japanese
mother company randomly uses either EUC-JP or Shift-JIS), or has ports
configurable with encoding, or has ports that autodetect (!) encoding,
just to handle non-ASCII, never mind the CJK's.
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 AFAIK
also supports various encodings (which also helps to cement its
position as the One True Implementation; other implementations have a
really, really long road to take to even reach a minor fraction of
GHC's capabilities, so typical users bend over backwards to install
GHC on their systems).
>
>> 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.
Pretty much the only use major use case for the "line-ending ENLIST" I
can see is:
define : foo x y
whatever
whatever ...
If "line-ending ENLIST" ended at either GROUP/SPLIT, SUBLIST, or an
EOL, we could do:
define : foo x y $ probe $ call/cc $ lambda (return) $ cond
: has? x 'some-property $ return 42
: has? y 'some-property $ return 41
: else $ return 0
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).
>
> 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).
> 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 *>.
Sincerely,
AmkG
------------------------------------------------------------------------------
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
