On Sat, Oct 31, 2015 at 08:19:44PM +0100, Peter Bex wrote:
> So, here we go, a patch to dynamically resize the temporary stack.
Even mentioned on IRC that it may be useful to have the current
behaviour (a fixed temp stack size), but with resizing as the default
behaviour.
Attached is a new
On Mon, Nov 02, 2015 at 11:03:20PM +0100, felix.winkelm...@bevuta.com 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,
Peter Bex scripsit:
> 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.
The general permission to
> On Sun, Nov 01, 2015 at 01:36:53AM +0100, felix.winkelm...@bevuta.com wrote:
> > Is this really necessary? I think runtime.c is already complicated enough
> > as it
> > is. I understand your intent, but I'm always wary of "arbitrary fixes to
> > reasonable
> > limitations, just because they
On Mon, Nov 02, 2015 at 07:21:06PM +0100, felix.winkelm...@bevuta.com wrote:
> > I know what you mean, but we've seen that in practice there are some
> > libraries that heavily rely on apply, most notably SSAX's sxml
> > transformations. And an XML element with 4096 child nodes isn't
> >
> > 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
Em 01/11/2015 07:44, "Peter Bex" escreveu:
>
> On Sun, Nov 01, 2015 at 01:36:53AM +0100, felix.winkelm...@bevuta.com
wrote:
> > Is this really necessary? I think runtime.c is already complicated
enough as it
> > is. I understand your intent, but I'm always wary of "arbitrary
On Sun, Nov 01, 2015 at 01:36:53AM +0100, felix.winkelm...@bevuta.com wrote:
> Is this really necessary? I think runtime.c is already complicated enough as
> it
> is. I understand your intent, but I'm always wary of "arbitrary fixes to
> reasonable
> limitations, just because they are
On 2015-11-01 1:36, felix.winkelm...@bevuta.com wrote:
> Is this really necessary? I think runtime.c is already complicated
> enough as it is. I understand your intent, but I'm always wary of
> "arbitrary fixes to reasonable limitations, just because they are
> limitations".
I agree about the
Hi all,
Now that we're using argvectors, we're no longer limited by any arbitrary
C macros or platform-specific hacks. The only two things that determine
the number of arguments that can be passed to a procedure are:
1) The size of the C stack (because that's where argvectors are allocated)
2)
felix.winkelm...@bevuta.com scripsit:
> If I have to pass 10 million arguments to a procedure, I'm probably
> doing something wrong.
In general this is true, but `apply` is an exception: when you say
`(apply fn giant-list)` you end up invoking fn with an argument count
that's equal to the length
> Hi all,
>
> Now that we're using argvectors, we're no longer limited by any arbitrary
> C macros or platform-specific hacks. The only two things that determine
> the number of arguments that can be passed to a procedure are:
>
> 1) The size of the C stack (because that's where argvectors are
12 matches
Mail list logo