This is the mail archive of the
kawa@sourceware.org
mailing list for the Kawa project.
Re: type declaration best practices?
* Per Bothner [2009-11-13 08:54+0100] writes:
>> 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.)
I think R6RS removed | and since | for symbols is used so rarely
something like #"foo bar" would have been a better choice. But of
course, there's no point in making changes without 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.
Or use a single : to make the confusion perfect :-)
Maybe there could be something like a declaration at the beginning of a
file to specify reader options. Perhaps like the -*- stuff in Emacs.
One of those options could specify how those "infixy" things work.
> 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.
This seems similar to how the single : works currently. Which makes me
wonder if it work to use the same mechanism for both.
Helmut