[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

*To*: gyro@kestrel.ARPA*Subject*: types*From*: Olin.Shivers@CENTRO.SOAR.CS.CMU.EDU*Date*: Wed ,27 Apr 88 17:16:22 EDT*Cc*: T-Discussion@MC.LCS.MIT.EDU*In-reply-to*: Scott W. Layson's message of Thu, 28 Apr 88 03:19:16 PDT <8804281019.AA22798@kestrel>

Date: Thu, 28 Apr 88 03:19:16 PDT From: gyro@kestrel.ARPA (Scott W. Layson) Besides, the failure-continuation approach would be more suitable for a (gasp! heresy) strongly-typed language. I know T will never become one of THOSE, but I'm still curious what the impact would be like... T might make a nice substrate to build such a system on top of, though. Suppose you defined a T extension that had a type system like ML's or the polymorphic lambda calculus. It would be straightforward to implement a type inferencer (for ML; inferencing polymorphic lambda calculus is probably undecidable), and type checker. This would be trivial to compile into T. It really craps up the code if you have to do all the declarations with Lisp syntax. But if you used ML's type system, you wouldn't have to put declarations in your code -- they could all be inferred. The full blown polymorphic lambda calculus, though, is another matter. Voila. Strictly typed T for those who feel that it's a good thing there are laws requiring people to wear safety belts, without altering the T base level at all. -Olin P.s. Even better than the polymorphic lambda calculus type system is the one in FX -- then you can be a facist about side effects as well.

**References**:**Naive T Design Questions Addendum***From:*gyro@kestrel.ARPA (Scott W. Layson)

- Prev by Date:
**Naive T Design Questions Addendum** - Next by Date:
**GC speed** - Previous by thread:
**Naive T Design Questions Addendum** - Next by thread:
**More On Naive T Design Question 6** - Index(es):