Panicz Maciej Godek on Nostr: Kawa Scheme comes with a number of syntactic extensions: (call-with-input-string ...
Kawa Scheme comes with a number of syntactic extensions:
(call-with-input-string "a:b:c" read)
gives
($lookup$ ($lookup$ a (quasiquote b)) (quasiquote c))
and
(call-with-input-string "(a::b::c)" read)
produces a list of 5 tokens:
(a :: b :: c)
The definition of $lookup$ in the compiler does a great job for JVM interoperability (so it can be used for accessing both methods and fields of objects).
Scheme seems to generally stay away from object-orientation, but whenever it gets near it, it either does it in a very ad-hoc manner by identifying objects with lambda, or in a style of CLOS.
I wrote about the problems with CLOS approach elsewhere. The problem with lambda approach to objects is that although you can use it to model things like inheritance/mixins, the object identity seems to suffer from that approach.
The approach of #Java, while not as minimalist as that of Scheme (which could be summarized as: roll yourself your own OO system from our functions, records and vectors) seems to allow to architect programs in a way that is usually inaccessible to Scheme programmers.
Also, Kawa offers polymorphism that is not accessible in Scheme, so you can use a single function for-each, rather than its specialized variants such as string-for-each or hash-for-each.
The only thing I regret is that Kawa's extensions are going to be hard to port to other Schemes.
BTW I found this quote in Kent Dybvig's last commit in the ChezScheme repo:
"While object-oriented programming obscures control flow, tends to encourage an overly imperative style of programming, and is often overused when it's available, it has its uses when used judiciously."
https://github.com/cisco/ChezScheme/pull/596
(call-with-input-string "a:b:c" read)
gives
($lookup$ ($lookup$ a (quasiquote b)) (quasiquote c))
and
(call-with-input-string "(a::b::c)" read)
produces a list of 5 tokens:
(a :: b :: c)
The definition of $lookup$ in the compiler does a great job for JVM interoperability (so it can be used for accessing both methods and fields of objects).
Scheme seems to generally stay away from object-orientation, but whenever it gets near it, it either does it in a very ad-hoc manner by identifying objects with lambda, or in a style of CLOS.
I wrote about the problems with CLOS approach elsewhere. The problem with lambda approach to objects is that although you can use it to model things like inheritance/mixins, the object identity seems to suffer from that approach.
The approach of #Java, while not as minimalist as that of Scheme (which could be summarized as: roll yourself your own OO system from our functions, records and vectors) seems to allow to architect programs in a way that is usually inaccessible to Scheme programmers.
Also, Kawa offers polymorphism that is not accessible in Scheme, so you can use a single function for-each, rather than its specialized variants such as string-for-each or hash-for-each.
The only thing I regret is that Kawa's extensions are going to be hard to port to other Schemes.
BTW I found this quote in Kent Dybvig's last commit in the ChezScheme repo:
"While object-oriented programming obscures control flow, tends to encourage an overly imperative style of programming, and is often overused when it's available, it has its uses when used judiciously."
https://github.com/cisco/ChezScheme/pull/596