This is the mail archive of the firstname.lastname@example.org mailing list for the Kawa project. See the Kawa home page for more information.
I also checked in support for type specifiers for local variables. Specifically, Kawa supports these extensions: (let ((VAR [TYPE] INIT) ...) BODY) (let NAME ((VAR [TYPE] INIT) ...) BODY) (let* ((VAR [TYPE] INIT) ...) BODY) (letrec ((VAR [TYPE] INIT) ...) BODY) and I plan to add: (do ((VAR [TYPE] INIT [STEP]) ...) (TEST EXPR ...) BODY ...) In all cases, the optional TYPE causes VAR to be declared to have the specied type. This may cause more efficient code, especially when primitive types are used. I do have some concerns about the syntax, because we have an optional sub-form which is not the last sub-form. This makes parsing slightly more complex, and is especially ugly for (do ...). However, I think the TYPE really should be near the VAR, since we are specifying the type of the VAR, not the INIT. One option is to use extra parentheses: (let (((i <int>) 10)) ...) but I think Scheme (and Lisp) uses too many parnetheses as it is; adding an extra pair makes it even more difficult to read. (One of the purposes of type specifiers is documentation, so readability is important.) Maybe we can use some magic syntax to specify a type specifier, such as: (let ((i :: <int> 10)) ...) Bigloo does something similar, except it puts the VAR and the TYPE together, so it looks like one symbol: (let ((i::int 10)) ...) That does not work in Kawa, since I don't want to rule out using more complex expressions for TYPE. We could allow something like: though in that case one could do something like: (let ((i::<int> 10)) ...) (let ((i::(array-of <int>) ...)) ...) I did just notice that the syntax for type-specifiers for optional and keyword arguments in lambda expressions has the type come after the default value. That needs to be made consistent. At this point, I'm leaning towards this syntax: (let ((i :: <int> 10)) ...) since it is generalizable to complex specifiers, syntactically unambiguous and quite readable. It can also be applied to define: (define i :: <int> 10) However, it is not what is in the current snapshot. Any comments? --Per Bothner Cygnus Solutions email@example.com http://www.cygnus.com/~bothner