[plt-scheme] to define, or to let

Eli Barzilay wrote:
>>> But using letrec is not dangerous too.

Bradd wrote:
>> Relying on evaluation order in letrec most certainly is dangerous.

> Again, in *MzSchem*, relying on evaluation order is *not* dangerous.
> It is specified in the manual -- search for "evaluation order" and you
> will get there.

Speaking of context, look back to the original question, which asked
about the "spirit of Scheme." Also note that the second paragraph in the
MzScheme manual states, "MzScheme ... is R5RS-compliant," and R5RS
clearly warns users *not* to rely on evaluation order in letrec.

Doing that is very clearly not in the spirit of Scheme.

>> R5RS even goes out of its way to warn users that they must not do it!
>> You're giving very bad advice here. At best -- if you're sure that
>> your current compiler supports it -- it's a bad habit.

> It is part of the specification of the language I'm using.  If you're
> using a different language, then you're posting to the wrong list.

Again, "part of the specification" and "dangerous" are not incompatible.

>>> It would be stylistically bad, but not dangerous since it is
>>> documented & intentional.

>> "Documented & intentional" is not incompatible with "dangerous."
>> Lots of C's misfeatures are documented and intentional.  Would you
>> claim that they aren't dangerous?

> What?  C misfeatures?  I told you already about them.  I don't care.

This isn't about C. It's about the inconsistency in your argument. Are
C's misfeatures any less dangerous because they're documented and
intentional?

>> If you care about portability or good programming habits at all ....

> Good programming habits???  Where does this come from?  I'm working
> with an implementation that guarantees left to right evaluation. Since
> it is part of the implementation I'm using there is no problem at all
> for me to use it.

So you say. I still call it a bad programming habit.

>>> I believe that trying to make local environments be a little more
>>> like the global environment is the main reason for this extension.

>> And I believe that imitating the top level is exactly the wrong thing
>> to do.

> That you believe it is something that is unrelated to me.  I like the
> top level, and I use it.

That's nice. That doesn't make it any better as a model for internal
definitions. I might take your opinion more seriously if you had a
better argument for it than "I use it" and "[it] makes it completely
different than ML." I might take it more seriously if it weren't for the
many excellent Schemers who have offered compelling arguments against
the top-level behavior.

Why should I listen to you? The vast majority of "good programming
advice" I've seen you offer has run counter to every principle of good
programming I'm familiar with. You tend to ignore everything that isn't
directly useful to you. For example, in the discussion we had about the
Linux installer for DrScheme, you did nothing but complain about how it
was too difficult and not useful enough to support installation in a way
that makes sense for the platform, when it seemed that a large part of
the problem was that you simply didn't understand the platform's
conventions.

>> It's well-known that the top level is an ugly bunch of hacks designed
>> to make REPLs easier to use. Again, you're giving horrible advice.

> And in my view, saying that the top level is an ugly bunch of hacks
> and therefore should be avoided is giving horrible advice.

That's nice. I'd take it a lot more seriously if I had more confidence
in your language design and engineering judgment.
-- 
Bradd W. Szonye
http://www.szonye.com/bradd