[plt-scheme] to define, or to let
On Mar 20, Bradd W. Szonye wrote:
>
> Richard Cleis wrote:
> >> I am not complaining about letrec, I was just responding. I use
> >> let* for this sort of thing anyway, and now I know why. Is that
> >> dangerous?
>
> Eli Barzilay wrote:
> > No. But using letrec is not dangerous too.
>
> 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.
> 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.
> > 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.
> > It is true that MzScheme might change tomorrow and throw an error
> > in those cases because someone achieved (a new) enlightening, but
> > the same argument holds for dropping any MzScheme development
> > tomorrow, and switching to MzPerl.
>
> C'mon, this is a ridiculous argument. If you care about portability
I care about portability between different implementations of PLT
Scheme. I already said that. Trying to write Scheme code that is
portable across different implementation is something I very
intentionally don't do.
> 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. Who says it's a bad habit to use it? My
implementation also allows mutation of bindings, should that be
considered harmful too?
> > BTW, this dependency *is* useful in cases where you want to write one
> > big function that encapsulates lots of smaller definitions:
> >
> > (define (foo ...)
> > (define a ...)
> > (define (bar x) ...)
> > (define b (bar a))
> > ...)
> >
> > 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. I believe that the top level, with all of
its (well known) defects is a major element in the design of the
language, one that makes it completely different than ML. A good
example is Stalin -- I once said that the fact that Stalin exists and
that it can compile Scheme code to run as if it was hand-optimized
assembly, all that does not make me happy. The core of what prevents
me from being happy about Stalin is its lack of a REPL, in my view,
taking that away is taking a huge part of the language that I want to
have. Because of this, I like having a repl, and I see no problem in
trying to make local environments be a bit more like it.
> 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.
--
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://www.barzilay.org/ Maze is Life!