[plt-scheme] Re: Paren Paralysis Sufferers Unite
On 16 Oct, 20:50, Joe Marshall <jmarsh... at alum.mit.edu> wrote:
> On Fri, Oct 16, 2009 at 12:29 PM, Morgan <lianci... at gmail.com> wrote:
>
> > It just seems a bit unreasonable, c++ and java are entirely happy to
> > allow my superfluous parentheses I'm accustomed to using, it can make
> > the code easier to read after all.
>
> What compiler are you using? My C++ and Java compilers get all bent
> out of shape if there are superfluous parenthesis:
>
> int ma(in() ))
> {
> prin))tf("hello, wor(ld");
> r)etu(rn 0;)
> }(((
>
> --
> ~jrm
> _________________________________________________
> For list-related administrative tasks:
> http://list.cs.brown.edu/mailman/listinfo/plt-scheme
LOL! No, I mean something a wee bit different to that.
taking an example; the difference between these two pieces of code.
(define (get-smallest x y z)
(cond ((and (< x y) (< x z)) x)
((and (< y x) (< y z)) y)
((and (< z x) (< z y)) z)
)
)
scheme is all happy with that, but not with what's below:
(define (get-smallest x y z)
(cond (((and (< x y) (< x z))) x)
(((and (< y x) (< y z))) y)
(((and (< z x) (< z y))) z)
)
)
which results in this lot:
(get-smallest 1 2 3)
. . procedure application: expected procedure, given: #t (no
arguments)
Now, I freely admit there's absolutely no utility in having those
extra parens. But they do no harm! [I think. Being a newb could
possibly mean being wrong about these things. However the sky hasn't
fallen in yet, so I'm fairly hopeful]
taking the typical math example ((2 + 2) * 3) I mean, we know those
parens are useless, but they potentially help to clarify the situation
if you're uncertain of the order of evaluation with arithmetric
operators.
In C++ and Java, superfluous parentheses like those are o.k. but not
so in scheme, an extra pair of parens is OTT. Which it is. But it
still seems a wee bit inflexible.
Thoughts?