Common Lisp solved this problem 20 years ago Alan Watson (25 Oct 2005 11:02 UTC)
Re: Common Lisp solved this problem 20 years ago Marcin 'Qrczak' Kowalczyk (25 Oct 2005 19:11 UTC)
Re: Common Lisp solved this problem 20 years ago Per Bothner (25 Oct 2005 19:22 UTC)
Re: Common Lisp solved this problem 20 years ago Alan Watson (25 Oct 2005 20:11 UTC)
Re: Common Lisp solved this problem 20 years ago Alan Watson (25 Oct 2005 20:12 UTC)
Re: Common Lisp solved this problem 20 years ago Marcin 'Qrczak' Kowalczyk (25 Oct 2005 22:08 UTC)
Re: Common Lisp solved this problem 20 years ago Alan Watson (25 Oct 2005 20:28 UTC)
Re: Common Lisp solved this problem 20 years ago Alan Watson (25 Oct 2005 20:22 UTC)
Re: Common Lisp solved this problem 20 years ago Aubrey Jaffer (25 Oct 2005 21:54 UTC)
Re: Common Lisp solved this problem 20 years ago Alan Watson (25 Oct 2005 22:23 UTC)
Re: Common Lisp solved this problem 20 years ago Aubrey Jaffer (26 Oct 2005 02:25 UTC)
Re: Common Lisp solved this problem 20 years ago Alan Watson (26 Oct 2005 03:52 UTC)
Re: Common Lisp solved this problem 20 years ago Per Bothner (26 Oct 2005 05:46 UTC)
Re: Common Lisp solved this problem 20 years ago Taylor Campbell (26 Oct 2005 20:05 UTC)
Re: Common Lisp solved this problem 20 years ago John.Cowan (26 Oct 2005 20:12 UTC)
Re: Common Lisp solved this problem 20 years ago Per Bothner (26 Oct 2005 20:38 UTC)
Re: Common Lisp solved this problem 20 years ago Thomas Bushnell BSG (26 Oct 2005 21:53 UTC)
Re: Common Lisp solved this problem 20 years ago Per Bothner (26 Oct 2005 22:13 UTC)
Re: Common Lisp solved this problem 20 years ago Thomas Bushnell BSG (26 Oct 2005 22:20 UTC)
Re: Common Lisp solved this problem 20 years ago Alan Watson (26 Oct 2005 23:31 UTC)
Re: Common Lisp solved this problem 20 years ago Per Bothner (27 Oct 2005 00:20 UTC)
Re: Common Lisp solved this problem 20 years ago Thomas Bushnell BSG (27 Oct 2005 03:20 UTC)
Re: Common Lisp solved this problem 20 years ago Per Bothner (27 Oct 2005 05:52 UTC)
Re: Common Lisp solved this problem 20 years ago Taylor Campbell (26 Oct 2005 23:51 UTC)
Re: Common Lisp solved this problem 20 years ago Per Bothner (27 Oct 2005 00:14 UTC)
Re: Common Lisp solved this problem 20 years ago Thomas Bushnell BSG (27 Oct 2005 03:21 UTC)
Re: Common Lisp solved this problem 20 years ago Per Bothner (27 Oct 2005 05:41 UTC)
Re: Common Lisp solved this problem 20 years ago Thomas Bushnell BSG (26 Oct 2005 21:52 UTC)
Re: Common Lisp solved this problem 20 years ago John.Cowan (26 Oct 2005 22:14 UTC)
Re: Common Lisp solved this problem 20 years ago Thomas Bushnell BSG (26 Oct 2005 22:17 UTC)
Re: Common Lisp solved this problem 20 years ago Alan Watson (26 Oct 2005 06:15 UTC)
Re: Common Lisp solved this problem 20 years ago Per Bothner (26 Oct 2005 06:51 UTC)
Re: Common Lisp solved this problem 20 years ago Alan Watson (26 Oct 2005 07:15 UTC)
Re: Common Lisp solved this problem 20 years ago Per Bothner (26 Oct 2005 07:38 UTC)
Re: Common Lisp solved this problem 20 years ago Alan Watson (26 Oct 2005 07:49 UTC)
Re: Common Lisp solved this problem 20 years ago Marcin 'Qrczak' Kowalczyk (26 Oct 2005 09:09 UTC)

Re: Common Lisp solved this problem 20 years ago Per Bothner 26 Oct 2005 20:38 UTC

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

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

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

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

> 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.
--
	--Per Bothner
xxxxxx@bothner.com   http://per.bothner.com/