Re: [Chicken-hackers] [PATCH][5] Make temporary stack resizable (fixes #1098)

[felix . winkelmann]

> > That doesn't change the fact that it is very bad programming style. It 
> > doesn't
> > scale, is not portable and very inefficient. Endorsing such a programming 
> > style
> > encourages writing bad code, therefore I really recommend a hard limit.
>
> It's not up to us to tell other how to write their code (except when it
> goes into the core, of course!), and SSAX *is* one of the few popular
> portable Scheme libraries in actual use.  But if you think the change in
> runtime.c is too nasty, I don't care *that* much to press the issue.

We very much tell others how to code, in countless small or big decisions about
technical issues in the design and implementation of the language.
I will not dig through the mailing list archives now, but remember that several 
times issues of
programming style has influenced core- and library code design. We all just 
happen to sometimes
have different opinions of good or bad programming style.

Popularity is a weak argument, BTW. Using "apply" for arbitrarily long
arguments lists is always due to laziness and can be fixed, even in SSAX.

I never said the change is "too nasty". Apply it, if you want (since Evan 
approves of it
as well). I just wanted to make my point, if you allow.

> > Can you elaborate on those "certain conditions"?
>
> If you just called a function that accepts a whole lot of arguments and
> needs to allocate on the stack, then it will trigger a GC.  This means
> it saves all its arguments on the temporary stack.  This is when this
> assertion will be triggered.
>
> If the stack is *not* full, the number of arguments don't matter.
> This means that you can have such a situation in your code lurking for
> a long time before actually _hitting_ the assertion one day when the
> stack layout changes due to external factors, like when you rewrite a
> completely unrelated piece of code.  That's what I meant by hard to debug.

Sorry, I don't understand this.

> > But that is not the main motivation for my concern.
>
> Then what is?  I don't think it's our place to be deciding on the coding
> style of others.

I remarked on this above. You are not immune to judgements on other
people's coding style, and I'm sure you know that.

> > I think 4096 is fine, as is anything larger. Memory consumption is not a
> > problem in the moment (a minimal program, or csi when started fresh, 
> > consumes relatively
> > little memory, at least the last time I checked)
>
> I know it's only a minor win, but I think the new code is somewhat more
> flexible with almost no runtime cost for "better" programs, which is a
> bonus.

That is technically correct, seen from your perspective.

> > Using apply with potentially unlimited argument lists (or even potentially 
> > very
> > large lists) looks sometimes like an easy way out, but is always wrong and 
> > should be
> > avoided (and can, in all cases I have encountered so far).
>
> True, but sometimes when on a tight deadline it can be good if you
> can get away with a nasty hack.  As long as it's for a throwaway program
> or if not, that you later fix it.  As long as you actually do that :)

That kind of reasoning is understandable, but somewhat weak, and can never be
refuted.


felix