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]

Re: type declaration best practices?


On 11/12/2009 11:14 PM, Helmut Eller wrote:
I think the double colons are ugly and get in the way of macros.

I won't disagree too strongly about the double-colons being ugly, but switching to something else has problems - Kawa already has too many duplicated and semi-deprectated ways of doing things ...

if I were afraid of parens I wouldn't use Lisp in the first place.

Good point, though my personal preference might be fewer parentheses ...


I like how Goo [1] did it:

  (df tagged-vector3f ((tag symbol) (x float) (y float) (z float) =>  pair)
          ... )

Note that the return type is folded into the arglist which is IMO cute
and also works nicely for functions with multiple return values.

That's not a bad option.


Goo also offers | as infix option but something like var|type is always
translated to (var type) by the reader.

Reasonable, but alas | is already used for character-quoting in symbols. (I guess it is possible to remove that functionality, or restrict the use of | to so that it has to be the start of a symbol, but I'd rather not break compatibility that badly without a really strong reason.)

If starting from scratch I might have chosen some other character, for
example ! as in:
  (define x!integer 10)
  (define (foo arg1!type1 arg2!type) !rtype body)

But given the history of using double-colon, it seems better to stick
with using double-colon - though I could be talked into changing.

It is certainly possible to define
  x::y
as reader-sugar for
  (x y)
and that might even be a useful feature for other things like
association lists.  A possible downside is that using (name type)
as the (unsugared) type-specifier syntax is that may limit some
options for a possible pattern-matching extension to definitions.

An alternative is to define
  x::y
as syntactic sugar for (say):
  (%colon-colon% x y)
and then allow the latter form in definitions.  E.g.
  (define x::integer 12)
would become syntactic sugar for:
  (define (%colon-colon% x integer) 12)
and the define form would be enhanced to recognize that syntax.

Similarly if we decide on ! or ~ or some other replacement for :: .

An example where those double colons didn't work was the DO macro in
kawa/lib/std_syntax.scm.  For a long time it was only possible to give
the first variable a type with double colons.  But with parens it was
possible to give all variables a type:

   (do (((x int) 1 ...)
        ((y float) 1 ...))
       ...)

always worked beautifully.

I'm surprised ... even I don't know all of Kawa's features!


The new definition of DO which handles :: in
all places is long winded and complicated.
--
	--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]