This is the mail archive of the
kawa@sourceware.org
mailing list for the Kawa project.
Re: road-map for syntax for Kawa parameterized types
On 06/03/2011 02:32 PM, Jamison Hope wrote:
On Jun 3, 2011, at 2:48 PM, Per Bothner wrote:
I'm proposing that Kawa should use square brackets for parameterized
(generic) types. This matches Scala - but not Java. Note this is a
long-term plan,
and it will probably start out with just some special cases (as in my
next message).
Using angle brackets would cause parsing (reader) problems.
In particular, this is because the characters #\< and #\> are legal for
identifiers, right? On the other hand, #\: is also allowed in
identifiers and
yet Kawa manages to treat it specially (by jumping through hoops, I know).
But for parameterized types we need a pair of open-bracket and
close-bracket.
#\< and #\> are commonly used stand-alone, so the reader can't just look
for a #\> after it sees a #\<. If we restricted ourselves to single symbol
tokens, like list<integer> it would be doable, but a type parameter
might have complex structure in itself.
Square brackets seem fine to me. So a java.util.Enumeration<String>
would be
represented as
java.util.Enumeration[String]
Yes.
in Kawa, and java.util.Map.Entry<K,V> would be
java.util.Map:Entry[K V]
(or is that java.util.Map$Entry[K V]?)
Probably either would work, but the former seems preferable.
There is a semi-inconsistency with arrays, which also use angle-brackets.
A solution (not super elegant but tolerable) is to define:
T[]
a short-hand for:
java-array[T]
for some pseudo-parameterized-type java-array.
Right now it just notices that $bracket-apply$ has a single argument,
right?
Could it not continue to do this? Unless implementing this java-array would
be less inelegant than BracketApply.java's "if (pair.getCdr() !=
LList.Empty)".
So in practice, would these be as I'm interpreting them:
map[] -> an array of map
map[string object] -> a map whose keys are strings and whose values are
objects
map[string object][] -> an array of map[string object]
map[object string[]] -> a map whose keys are objects and whose values
are string[]s
Yes. Somewhat ugly, I agree. I don't have any better ideas, though.
We might consider deprecating the T[] syntax for arrays - but not for a
while.
Note also that a plain bracket list:
[v1 v2 v3]
is reader sugar for:
($bracket-list$ v1 v2 v3)
which evaluates to the same as (vector v1 v2 v3) except that the
result is immutable (a gnu.lists.ConstVector).
Except in situations where the value is being assigned to an array, as in
(define nums ::int[] [0 1 2])
right? Or is there still a short-lived ConstVector in there? (Off-topic,
I know.)
Currently, this is handled specially. It would be cleaner to say that
[0 1 2] evaluates to a ConstVector, and a ConstVector can be automatically
converted to a Java array. Then the current behavior would just be an
optimization. However, that's not currently the case.
--
--Per Bothner
per@bothner.com http://per.bothner.com/