This page is part of the web mail archives of SRFI 58 from before July 7th, 2015. The new archives for SRFI 58 contain all messages, not just those from before July 7th, 2015.
Taylor Campbell wrote:
>>> [Now] the syntax is still as complicated -- perhaps even slightly
>>> more so --, not possible to implement based on SRFI 10, and even
>>> incompatible with Common Lisp & SLIB!
Bradd wrote:
>> I don't get this. It looks like a purely cosmetic change to me, no
>> more incompatible with other formats than the original was.
> The only matter at hand _is_ cosmetics: that's what the whole debate
> of syntax is!
By "purely cosmetic," I meant that nothing changed but the names of the
heterogeneous array types. The only syntactic change was making the rank
mandatory: #[n]A[tag] became #nA[tag]. How can you possibly portray this
as "slightly more complicated"? Making the rank mandatory simplifies
parsing somewhat.
> The original format, however, was, I believe, compatible with both
> Common Lisp & SLIB, for the subsets where there was semantic
> intersection (with heterogeneous arrays).
How has this changed? You still write #5A(...) for a rank-5 array, just
like the original proposal, and just like Common Lisp.
>>> ... Scheme's syntax ... is fundamentally centred around lists &
>>> symbols, but which has nothing to do with arrays at all.
>> You say that like it's a good thing. I disagree; like Bear and
>> Aubrey, I believe that the lack of a terse array syntax is a weakness
>> in the language.
> This claim has not been defended. What is important is not the way one
> can write a literal array but the ease with which one can _operate_ on
> arrays ....
Sorry, you keep saying this, and it simply isn't true. Bear did defend
the claim, with a list of applications that demand terse syntax (because
array literals are very common) /and/ a good library (because they
perform non-trivial array manipulation).
>> I don't know how you came to this conclusion, and I don't know why
>> you're repeating this false claim even after Bear's extended example
>> (literal matrices for coordinate transformations in graphics
>> programming).
> I came to this conclusion after bear mentioned such programs _dumping_
> _S-expressions_. Furthermore, I showed that bear's example is _hardly_
> more verbose or column-consuming than his original vectors ....
Hang on, there's something fishy here.
You objected to Bear's original list of array-heavy applications,
asking: "How often do you find yourself in Scheme code wanting to write
literal arrays /by hand/?" (emphasis mine).
He replied, "Look again at the list. Those are precisely what you asked
for: all are applications of STATIC arrays .... My source code in some
cases is almost five percent literal vectors. A recent example ...."
Later, when Aubrey quoted Bear, you objected again, saying, "I have
responded to this already: these are all uses for arrays, but they have
very little to do with _hand-written_ literal arrays ...." You wrote
this /after/ having read and replied to Bear's quote above.
Here's the sequence:
1. Bear gave a list of applications that use arrays heavily.
2. You doubted the relevance of the list, asking whether they use array
/literals/ heavily.
3. Bear confirmed that they do, in fact, use literals heavily, sometimes
up to 5% of the source code.
4. You read and replied to Bear's followup.
5. Later, you claimed that the applications "have very little to do with
hand-written literal arrays."
After reading Bear's followup, how can you honestly make that claim? He
demonstrated knowledge and experience in those application areas, as
confirmed by his code example and the agreement of other practitioners.
Despite this, you've gone from doubt to denial to vehement denial. What
is the basis for your claim? You insist that we haven't defended our
claim, while you make increasingly hostile claims of your own about
application areas that you seem to have little experience with.
I suggest that you step back and reconsider the arguments against you,
to make sure that you've understood them and evaluated them fairly.
> The part of the sentence that you deleted had significance as well:
> '...and a lot of them will involve large data sets that will
> completely dwarf the size of the initial few characters of the literal
> array.'
No, that's not significant. You've attempted this line of argument
several times now: "X is insignificant to a lot of Foo. Therefore, X is
insignificant in general." That doesn't stand up to scrutiny.
>> I think SRFI 10 itself unnecessarily complicates the language. The
>> syntax is cumbersome and verbose, and the specification has some
>> bugs.
> Cumbersome & verbose as compared to what equally general syntactic
> extension ....
We don't want an "equally general syntactic extension." The generality
is exactly what makes it cumbersome and verbose. Like all things that
try to please everyone equally well, it pleases them equally poorly.
> ... and what bugs do you refer to aside from what you allege to be
> problems with how SRFI 10 relates to quasiquotation?
Aside from? That isn't enough on its own?
>> Worse, [SRFI 10] does not (as written) permit quasiquotation, which
>> is important for describing arrays with fixed shape but variable
>> elements ....
> The facts you discovered concerning the allowed placement of SRFI 10
> #,(...) forms are correct. The conclusions drawn are not. It does
> not always make sense that quasiquotation should apply to all SRFI 10
> constructors, such as homogeneous arrays, which _can't_ hold list
> structures (the structures that, for example, the #\, syntax expands
> to, (UNQUOTE ...)) ....
Huh? Your examples don't make sense. Suppose that INTEGER-VECTOR is a #,
constructor for constructing homogeneous vectors of integers. This
quasiquotation makes perfect sense:
`#,(integer-vector 1 2 ,a 4 5)
If a is 3, that's a reasonable expression (assuming a quasiquote
implementation that does the right thing). If a is (list 3 3 3), it's an
error, but it's exactly the same error as writing
'#,(integer-vector 1 2 (3 3 3) 4 5)
which is already allowed by the #, syntax. How exactly does
quasiquotation "not make sense" here? How does it fail in a way that
doesn't also fail in the equivalent QUOTE form?
> On the other hand, there is nothing that SRFI 10 instated to _prevent_
> new SRFIs from defining constructor tags such that the surrounding
> #,(...) may be used within a quasiquotation.
On the contrary, the rationale, the specification, and the recommended
implementation strategy all strongly emphasize read-time evaluation,
which precludes quasiquotation (a run-time feature).
> The more significant issue, however, is whether or not the unquoting
> within the #,(...) will be processed by the macro transformer for
> QUASIQUOTE, which must be extended for every new data type given a new
> #,(...) tag that one wishes to allow to be used as lists & vectors may
> be in quasiquotations.
I think that's correct, and it doesn't play well with the
"define-reader-ctor" implementation offered in SRFI 10 and actually used
by the implementations that support it.
> Note, by the way, that your `,'#,(...) example -- (QUASIQUOTE (UNQUOTE
> (QUOTE #,(...)))) -- would not have the same effect as simply
> `#,(...), even assuming all SRFI 10 data were allowed in
> quasiquotations. The SRFI 10 datum is simply embedded in a quote; it
> is the same as writing '#,(...) -- (QUOTE #,(...)) -- in the first
> place. This is consistent with the rest of SRFI 10, which does not
> specify how the #,(...) form operates with quasiquotation.
Again: Huh? I think you misunderstood me. I don't expect `,'#,(...) to
work like `#,(...) -- that is, I wasn't looking for a way to trick the
reader into doing quasiquotation inside a #, form. Instead, I was
complaining that you can't even use #,(...) as a literal in a
quasiquotation.
Even if you can't unquote inside a #, form, you should be able to write:
`(1 ,foo #,(bar)) ==> (1 <foo-thingy> <bar-thingy>)
However, the SRFI syntax does not allow this. Instead, one must write:
`(1 ,foo ,'#,(bar))
Which is silly.
>> The SRFI is no good unless the array syntax is usable, and SRFI 10
>> isn't good enough, technically or aesthetically.
> This has not been substantiated technically, and it is worthless to
> repeatedly argue of aesthetics when neither side has any clear
> advantage.
As written, it doesn't work with quasiquotation, and I doubt that it
ever will work well with quasiquotation, because it doesn't play nicely
with the define-reader-ctor approach recommended in the SRFI. Making it
a datum instead of a self-evaluating value adds insult to injury, since
you can't even use it in the literal part of a quasiquotation. That
makes it a poor choice for literal syntax, especially for a general-
purpose structure like arrays.
As for aesthetics, just typing #,(...) is horrible, on a US keyboard.
While my "whimsical note" was half-joking, that's only /half/ joking.
It'd take some effort to come up with a worse combination of keystrokes!
> I deny ... that it is worthwhile to unnecessarily complicate Scheme's
> syntax just so that it is made almost the _tiniest_ bit more
> convenient to write a literal array.
I don't think you've demonstrated "complicated" yet, let alone
"unnecessarily." And SRFI 10 vs Common Lisp syntax is more than a "tiny"
bit less convenient.
--
Bradd W. Szonye
http://www.szonye.com/bradd