Re: Equality, Assignment and The Emperor's New Clothes

bobueland@xxxxxxxxx writes:

> In the introduction to R5RS the philosphy behind Scheme is stated
>
> "Programming languages should be designed not by piling feature on top
> of feature .."

I think they had a specific scenario or two in mind. Say a language has
two features that one might think could be combined so solve a
particular type of problem. Unfortunately, the features were designed
in a way that doesn't allow them to be combined. Rather than redesign
the basic features of the language so that they can work together,
suppose the language designers create a new feature to solve that same
problem.

Or say a language feature can be used in one context but not another.
The Scheme way of designing the language would be to replace it with
something that could work in either context.

This is all in the context of features that have to be designed into the
language. I don't think it applies to features that can be easily built
on top of existing features. For example, you could easily build the
various number comparators on top of < and boolean operators, but the
langauge includes >, =, <=, >= anyway. I don't see this as violating
the stated philosophy.

> However when I come to deciding if two object are equal I have to learn
> about
>
> eq? eqv? equal? and type specific like char=?, string=?, =, ..
>
> Many of these or not easy to understand. In R5RS, three pages or used
> just to explain eqv?.

R5RS is a good thing to read, but it is written for language
implementors who need to know the details. You could just always use
equal? and be happy for years. You might even find that your Scheme
implementation makes equal? terminate on recursive data structures.

If this terminates in your implementation you could write with equal?
your whole life:

(let ((x (list 'a))) (set-cdr! x x) (equal? x x))

Given how much faster computers are these days, my own feeling is that
equal? should be required to work on recursive structures just as list?
is. Implementors already have to do tortoise and hare for list?, why
not do it for equal? as well. Users /that/ concerned about performance
can write their own equivalence predicates.

For reading others' code, just know that eq? means same-object?. All
those other predicates are there to throw errors if the objects you're
comparing don't have the types you expect. Plus the whole case
sensitivity thing. You can go back and find them when you're doing
something where you get the feeling equal? isn't what you want.

> For declaring variables and assigning values to them several constructs
> are used
>
> define, let, let*, letrec, named let
>
> They are not easy to understand. To get some feeling for them you must
> translate them into underlying lambda expressions which are not so easy
> to analyze themeselves.

No you mustn't. Especially named let can be much better understood from
examples of its usage. Use define for globals and the rest for
limited-scope definitions. Even with the fuzziest idea of what the
various let forms do you can start coding. You can find the right form
with trial and error.

> Now people who wrote R5RS are smart, much smarter than me. How come
> that such difficult constructs are allowed for seemingly simple things.
> The complexity in assignment and equality test is *not* an a priori
> difficulty since they are not that hard to understand in other
> languages.

Or rather, they used to not be. Time was when PHP only had ==, same as
eqv? in Scheme. Then they realized that some objects are equaler than
others and came up with ===, which I believe works like eq? in Scheme.
They're so object-oriented these days that if they haven't already
realized people will want to do == recursively, they soon will, and
we'll have an equivalent of equal?, or maybe == will be made the same as
equal? and some old PHP code will break.

In C you have == being very much like Scheme's eq?, and lots of people
by the results they get when using it on strings. You have to know what
type of data you're comparing and use strcmp(), etc. There's no option
like eqv? to compare two objects without thinking about their types.

In short, equality tests in other languages are just as complicated,
because you still have to think about same-object tests vs type-specific
tests, and about whether you want to compare recursively.

For assignment, there's something you need to understand about the R5RS
authors. Yes, they're very smart. They are also obsessive about
hygiene. Little Johnny is not allowed to touch that variable unless he
knows where it comes from and who else might be touching it. He also
needs to be precise about how his own variables touch each other.

He must use let if his variables get their values from the outside
without depending on each other.

He must use let* if within his set of variables subsequent ones depend
on prior ones.

He must use letrec when defining mutually recursive functions.

Sometimes you can use the wrong let form and get away with it, just
don't let the R5RS authors catch you at it. Especially watch out for
that Will Clinger guy. ;-)

> If there are some people reading this who have discussed R5RS, have you
> the same feeling as I that this unneccessary complicated, or am I
> seeing ghosts in broad daylight?
>
> (I'm not saying that I have any good alternative, but when simple
> things in my own work start to get complicated I usually go back to the
> foundations themeselves and try to figure out the source of these
> difficulties).

More precisely, you try to figure out whether the complexity is inherent
in the problem you're trying to solve, or whether you've manufactured
the complexity yourself as you went along.

I think it's clear that the equivalence complexity is inherent in the
problem. Assignment might be somewhat debatable, but there have been
times when Scheme's hygiene has kept me out of trouble.

--

http://ourdoings.com/ Easily organize and disseminate news and
photos for your family or group.
.

Relevant Pages

  • Re: How C is better then C++
    ... Each language has its strengths and weaknesses, and for each of those languages there are some contexts where it's advantages make it the superior one; and there are additional context where neither language is appropriate ... While most C++ programmers use only a limited subset of C++ features that may, in itself, be no more complicated than C, anyone who intends to do maintenance work on C++ code written by someone else will have to be at least familiar with every feature that the other person might choose to use. ... However, the designers of C++ were not idiots; most of the additional features of C++ were designed with the explicit intent of making it easier to avoid making particular types of errors, when those features are used correctly. ...
    (comp.lang.c.moderated)
  • Re: Where did the prophet really live?
    ... features were in the spoken language or not. ... Now the point that Macdonald makes is that Sabaic was the prestige ... medieval arab historians had reported inscriptions ...
    (soc.religion.islam)
  • Re: Is C99 the final C? (some suggestions)
    ... I can't think of a single feature in C99 that would come as ... There are a number of features in C99 that I will steer away from if ... > * a library function that allows the retrieval of the size of a memory ... With the restrictions of the C language, I think you are going to find ...
    (comp.lang.c)
  • Re: OT: compilers, interpreters, and VMs
    ... by people used to languages that don't have these features. ... a language should absorb each and every feature? ... run-time code generation, anonymous functions, exceptions and so on. ... general-purpose language should not include dynamic code generation. ...
    (comp.lang.misc)
  • Re: dynamic vs. static: the age-old debate
    ... I am not saying that the features themselves are necissarily either ... static implementation of a dynamic language. ... static typing dictates that such programs be rejected at compile time. ...
    (comp.lang.misc)