3 ms·
It's hard to see what the author is complaining about. I understand that it may just be a bit of fun, but in this post I'm going to try to address the points ma
by jonathanyc 12y ago
It's hard to see what the author is complaining about. I understand that it may just be a bit of fun, but in this post I'm going to try to address the points made and note how they don't seem valid to me.
"What would Scheme be like if numbers followed the same style as the rest of the language?
It would be necessary to import a library before using any numbers."
Every language has primitive types. I don't see any Schemers complaining about that fact. Sure, maybe you find it annoying that you have to (import srfi-69) to use hashmaps, and that the accessor functions have verbose signatures: (hashmap-ref ht key), etc. I think the author is forgetting that Scheme gives you the power to easily define a new syntax for yourself that does not affect the regularity of the rest of the language.
"Numbers would have no printed representation."
I'm reading this as a complaint about there not being a default printing representation for types like records. I don't see how this is a valid complaint. The point of using a record is presumably to distinguish your data type from any old vector. Almost all implementations will allow you to define your own printed representation if you want.
"There would be no polymorphism. Most operations would include a type in their name."
R5RS does not have type signatures for functions. If you want to write a ref procedure that works on vectors and lists, you can. In fact:
(define (ref x n)
(cond
((list? x) (list-ref x n))
((vector? x) (vector-ref x n))
(else #f)))
"But the lack of polymorphism would make it even more obvious that in practice exactness was simply one of the type distinctions: that between floats and everything else."
For lack of a better word, this seems like a strawman. I think it was a practical idea to have the language distinguish between exact and inexact numbers. Interestingly, Chicken Scheme implements the numeric tower in an library (the numbers egg) instead of in the standard distribution.
"Names would be descriptive, like inexact-rational-square-root and exact-integer-greatest-common-divisor."
I much prefer descriptive names that I can easily shorten using macros or functions to overloading the binary shift operator to write to streams.
"Converting the lists into strings would be up to you."
I guess this is a complaint about how small the standard library is. This is part of a larger debate within the Scheme community. See R7RS-large vs. R7RS-small. Many people think the latter is more to the nature of Scheme.
"This would really be about whether numeric operations should always return fresh numbers, and whether the compiler would be allowed to copy them, but no one would mention these merely implementational issues."
Relying on undefined behavior is an implementational issue. To quote R5Rs, "Eq?'s behavior on numbers and characters is implementation-dependent, but it will always return either true or false, and will return true only when eqv? would also return true." If you want defined behavior, why are you comparing things that can't already be compared with =, string=?, & co? Comparing a vector to a number doesn't make much sense.
"There would still be no bitwise operations on integers. Schemers who understood the purpose would advise using an implementation that supports bitvectors instead of abusing numbers. Those who did not would say they're easy to implement."
This point I am sympathetic to. But it seems to me a bit like complaining new language X does not support feature Y that language Z does. If feature Y is so important, why not decide whether or not it's worth your time to implement it and if not go with whatever language would be the most convenient to you? It's the same as many other decisions in life.
- kyllo 12y agoEvery language has primitive types. Ruby for example lacks primitives, even integer numbers are actually objects of type Fixnum.
- JadeNB 12y ago> Ruby for example lacks primitives, even integer numbers are actually objects of type Fixnum. … but isn't Fixnum a primitive type? EDIT: I guess that it depends on what 'primitive' means, but there is some root to the inheritance hierarchy—for Ruby, it's BasicObject ( http://www.ruby-doc.org/core-2.2.0/BasicObject.html http://www.ruby-doc.org/core-2.2.0/BasicObject.html )—and surely that must be regarded as primitive.
- djur 12y agoI think the parent is using 'primitive' in the Java sense, which means 'a typed value that is not an object' -- that is, 'int' instead of 'Integer'. The distinction is meaningless for languages that don't have separate type systems for objects and everything else. Wikipedia makes the division between "basic types" and "built-in types": http://en.wikipedia.org/wiki/Primitive_data_type http://en.wikipedia.org/wiki/Primitive_data_type
- kyllo 12y agoYes, I am talking in the C++ or Java definition of primitive types, like int, char, float, double, long, bool. It's only meaningless to talk about primitive types in the context of Ruby because Ruby doesn't have primitive types. Every type in Ruby is an object type.
- ubernostrum 12y agoJava is the canonical example. Some types are termed primitive types; they are simply raw (numeric) values. They are not "object-like" in the sense that they do not have methods a programmer can access, they cannot be subclassed, etc. Other types are reference types, which are "object-like". For each primitive type there is a corresponding reference type which can (and in more recent versions of Java, automatically does) wrap an instance of the primitive type (known as "boxing", and as "autoboxing" when done automatically). C# calls these "value types" and "reference types". Python, once upon a time, similarly had two hierarchies of types: those which could be subclassed, and those which could not (the latter all types built in to Python). The unification of these, and elimination of the distinction so that all of Python's types shared common behavior and a common hierarchy, began in Python 2.2 (introduction of "new-style" classes inheriting from `object`) and completed with Python 3 (where "new-style" classes are the default).