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

[Peter Bex]

On Mon, Nov 02, 2015 at 11:03:20PM +0100, address@hidden wrote:
> > > 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.

In some way, that's inevitable.  And it's a good thing!  Right now we're
given a choice to take away a limitation that would make "bad" code
easier to write.  If I understand correctly, you're asking: why the hell
should we do that, especially if it adds more code to runtime.c?

As far as I know, R5RS doesn't say anything about a maximum number of
procedure arguments in direct calls or when using apply.  In my book,
it's "better" in some absolute way to remove any limitations beyond
those which R5RS allows for.

I think my biggest concern is with the fact that *occasionally* there are
clever hacks that completely abuse a system which could be considered
"bad" code, but allow groundbreaking new things to be done, which is a
good thing.  Arguably, even Cheney on the MTA is an example of that!

On the other hand, shitty code vastly outnumbers clever tricks like these.
And if it makes our code shittier to support such shitty code, that's
unacceptable.

> 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.

Yep, definitely.  These discussions can be very helpful in determining
the future direction and goals of the project.

For instance, one thing I particularly like about CHICKEN is that it
(mostly) removes the distinction between tail calls and non-tail calls.
It doesn't unnecessarily punish deeply recursive code, even though that's
"bad" code in some sense.  It does nudge you into the right direction
because rewriting to use tail recursion speeds up such code a lot.  This
is great design.

> 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.

We've even fixed it ourselves with the "starred" variants of the
sxml-transforms procedures, but they're nonstandard.  SSAX can't be fixed
in a backwards compatible way: It's part of the API that transformer
procedures receive their child nodes as individual arguments.

There are other examples that work similarly.  One example I can come
up with off the top of my head is "define-macro" from the bindings egg:
if you want to capture an arbitrary number of "body" expressions in a
macro it'll have to be done via rest args, but the macro itself will be
called with all the expressions as arguments.  It's also not really a
design flaw: the reason define-macro exists is because it is more
convenient to use than the core macro transformers (if you like the
macro as a whole or not is besides the point I think).

In the define-macro case, you can always switch back to the core macro
system for macros that should accept many body expressions.  On the
other hand, if you export a macro from a library, you'll never know with
how many arguments your users are going to invoke it!  Of course, bindings
is (currently) not that popular yet, so this carries less weight than SSAX.

Speaking of which, why do you consider a library's popularity to be a
weak argument?  If many people are using SSAX and it doesn't work as
well on CHICKEN, it could be a contributing (but probably not deciding)
factor for switching to a different Scheme.

> 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.

Of course!

> > > 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.

Calling a function directly with 5000 arguments will "just work" in the
common case.  However, if this call happens to occur while the stack is
full, the assertion will be triggered.  Let's say this happens in
production but not in your development setup, then it would be pretty
hard to find this bug.

However, the fact that it crashes immediately makes it easier to find
of course.  So maybe it's not as dire as I thought.

> > > 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.

Absolutely.  I am fully aware that I should do that less :(

However, there's a difference between me yelling at someone for writing
shitty code and the compiler making it absolutely impossible :)

One reason I like Scheme is that it is very malleable: it doesn't require
me to jump through hoops to do things I want to do.  It has very few
restrictions by design.

> > > 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.

We've all been in such a situation and it sucks when the tools are making
life hard, even if you know you shouldn't be doing this.  And yes, it's
a stupid and weak argument, but also a very practical one :)

Cheers,
Peter

signature.asc
Description: Digital signature