This is the mail archive of the kawa@sourceware.org mailing list for the Kawa project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

road-map for syntax for Kawa parameterized types


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

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.

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

Let me know what you think of this plan.
--
	--Per Bothner
per@bothner.com   http://per.bothner.com/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]