road-map for syntax for Kawa parameterized types

[Jamison Hope]

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).

Square brackets seem fine to me.  So a java.util.Enumeration<String>  
would be
represented as
  java.util.Enumeration[String]
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]?)

> Square brackets don't really cause any new problems - the Kawa
> reader already handles square brackets.  For example:
>  map[string object]
> is read as:
>  ($bracket-apply$ map string object)
> The code that expands type-specifiers would of course have to  
> recognize
> this pattern, and of course the type-checking machinery would need  
> changes.
> No promises if/when this would happen!
>
> Note also I'm only talking about type "expressions" - not how to  
> declare
> parameterized types and methods in Scheme.  That is a lower priority.
> Also, handling of wild-cards or variance (as in List<? extends T>)  
> is left
> for another day.  I'm leaning towards Scala-style specification of  
> variance
> at definition site, not use site (as in Java).

I'm not sure I understand this part, as I know virtually nothing of  
Scala.
I found this page:
  http://www.scala-lang.org/node/129
and, after reading it a couple of times, I... sort of get it, I think.

> 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

> 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.)

> Let me know what you think of this plan.

I'm always in favor of approaching feature parity with Java language  
constructs,
so two thumbs up here.

--
Jamison Hope
The PTR Group
www.theptrgroup.com