> This is not possible in either Scheme or Kernel. In both
> languages, programming generically requires one to use a
> cascade of type predicates (e.g. number?).
This is a strange claim. If it's possible to create a cascade of type predicates to identify types, then it's possible to make type-of identically that cascade (plus a lookup for the user-defined types), and now you've got the functionality in Scheme.
This is a little bit like someone complaining that Scheme isn't an object-oriented language. If you want to do OOP in Scheme, you absolutely can.
The point is that with first-class types you can do O(1) method lookups, whereas with type predicates you can't get better than O(N), where N is the number of types.
Not true. In Scheme you could implement an O(1) lookup for user types plus a cascade for built-in types. The number of built-in types is small and constant, so it should not impose much overhead.
It's true. Yes you can get O(1) for user-defined types and O(N) for built-in types (of which Scheme has at least a dozen), but you can't get O(1) for all types, as with first-class type tags.
I like the idea. Seems really powerful and neat. But I can't escape the sense that in classic Lisp and Scheme the data is supposed to be transparent, and this notion of opaque, strongly-typed data came later. When you see all the supporting APIs in Common Lisp for plists and alists and whatnot, it seems to me that 'cons' was the abstraction.
Totally. And, I think that this was a problem, though.
This is probably my least-favorite lisp feature. The fact that 'cons' was a fundamental abstraction is elegant, but I don't think it makes sense to model everything in terms of lists.
Most lisps support different ways to construct data structures, though, and this is a manifestation of that.
It doesn't make sense to model everything in terms of lists, but using 'cons' to make your own data structures doesn't force you to. A-lists and p-lists are both mappings that happen to use 'cons'. Are they efficient for thousands of entries? Absolutely not, but they work fine for a dozen, and you can certainly implement more efficient data structures on top of them.
It's certainly true that modern Lisps have more structured approaches and this is a very cool improvement on those offerings. I just think "Scheme's approach to data is broken" is a little over the top.
Since to my knowledge Scheme has been replaced with Racket, is this blog out of date or is he just holding on to the old name. In any event, I've not had any problems with the existing approach and don't see quite why this 'change' is needed. Likewise, since the Racket list is quite active and quite open, I wonder why this wasn't discussed there (or maybe I just missed it---the volume of the list is quite large). Full disclosure, my default motto for such things is "Change is evil" so that might explain my position.
Scheme has not been replaced by Racket. Racket is a distinct language from Scheme. There are still many implementations of scheme besides the previous plt scheme.
Huh? I think you're getting Scheme and PLT Scheme confused. Racket has replaced PLT Scheme, but there's a whole world of non-Racket Scheme implementations out there.
This is a little bit like someone complaining that Scheme isn't an object-oriented language. If you want to do OOP in Scheme, you absolutely can.