This page is part of the web mail archives of SRFI 77 from before July 7th, 2015. The new archives for SRFI 77 contain all messages, not just those from before July 7th, 2015.
Date: Wed, 26 Oct 2005 13:38:28 -0700 From: Per Bothner <per@xxxxxxxxxxx> Taylor Campbell wrote: > I'm a bit unclear on one part of your proposal: is the type > declaration syntax merely a suggestion to the compiler, or does it > actually affect the semantics of a program? The latter, but perhaps not quite the way you're thinking. (let ((V :: TYPE init)) ...) has semantics like: (let ((V (coerce-to-TYPE init))) ...) You say it only has the effect of coercion, but below you seem to imply more meaning than that, so I'm a little confused here. (More on this below where you seemed to imply that.) Also, I agree with Thomas Bushnell that it is not a good idea to introduce the core syntax like this that is fundamentally intertwined with heavy semantic operations. If you want this kind of coercion, why not provide the COERCE-TO-... procedures by which you explained the meaning of the :: syntax, which could be parameterized even further and more simply? Coercion to integers of a given modulus, for example, from other integers, is accomplished with a procedure we already have in R5RS, namely MODULO; coercion to lesser-precision numerical representations would be useful to be parameterized on rounding, too, either from greater- to lesser-precision floats or from floats to integers, for the latter of which we also already have several routines for that kind of coercion, namely FLOOR, CEILING, ROUND, and TRUNCATE. One could also specify that within the scope of V that (set! V exp) gets translated to: (set! V (coerce-to-TYPE exp)) though I don't believe Kawa actually does that. (I'd have to check.) (I think SET! and mutable variables are an abomination of which the language should be rid anyway. But that is another topic for another discussion.) > That is, if I specify > that an expression's value is an IEEE double-precision flonum, do > arithmetic operations in that context 'become' IEEE 64-bit flonum > operations, with roundoff &c. as specified by IEEE, or may the system > actually do something else? Neither: it's not the operations that change: It's the operand that changes. The operation + is already defined so that if the operands are IEEE 64-bit *values* then we use 64-bit flonum flonum addition etc. But's that's the way R5RS already works - we're just being more precise and allowing for more data types. Why would it not be perfectly allowable for, say, the * procedure to return a 128-bit flonum when given two 64-bit flonums? Similarly, why would you not specify that you want IEEE 64-bit flonum arithmetic using an explicit IEEE 64-bit flonum operation, like IEEE-FLO64*, to clearly indicate this in the program? > Would this be the case with the integer > declarations and n-bit modular arithmetic as well? The declarations coerce to an appropriate data type. I.e. you coerce an integer to a (modulo-int N), and arithmetic on the (modulo-int N) *type* is defined to be modular. So are you saying that the 'type declaration' really *does* affect the semantics of the operations on the integer objects? I'm not quite clear on how you can otherwise signify that some integer is 'modular' in a way that the + operator can distinguish by run-time tag; integers are integers. > While type declarations are useful (though I *abhor* the :: syntax), It's not the most elegant syntax, but finding something better that works in the context of the existing Scheme language isn't trivial. Suggestions welcome. I'm not fond of the Common Lisp syntax, with its verbosity and weird scoping rules. Minor syntactic verbosity is not really a concern to me. Simplicity of expression, however, is, and I think that a simple way to say to the compiler 'the value of this variable is an index into this array,' for example, is an important assertion to express which I can find no simpler way to write than (DECLARE ARRAY-INDEX I ARRAY), or something along those lines. However, as I said, that's somewhat outside the scope of this SRFI, and for this SRFI I think coercion routines suffice to express simple kinds of assertions such as 'this is a flonum, or if it's not here's how to get one from something else.'