gcl-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gcl-devel] call-arguments-limit


From: Camm Maguire
Subject: Re: [Gcl-devel] call-arguments-limit
Date: Mon, 04 Nov 2013 11:38:31 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux)

Greetings!

Henry Baker <address@hidden> writes:

> Does GCL use some sort of bit mask for argument lists?
>
> That's fine, but I'm having trouble understanding when a bit mask will be 
> useful beyond -- e.g., 32 arguments.
>
> After than, either the function accepts _any_ number of arguments, or it 
> doesn't accept that many at all.
>

Its a 32bit wide call descriptor which has 6 bits each for the maximum
and minimum number of arguments, in addition to type info for the first
6 arguments, return value info, etc.

In addition, we have a 64 statement switch for dispatching the call in
debug mode.

> More precisely, we're (or at least I'm) only asking about APPLY, which 
> clearly should be willing to accept any number of arguments up to several 
> thousand arguments.  E.g., it should be possibly to use APPLY 
> +,a_very_long_argument_list.
>
> Yes, Common Lisp has a REDUCE sequence function, but there are many people 
> who still use APPLY + instead of REDUCE +.
>
> So I think GCL is being a little too pissy in this case.
>

Probably :-).  I do think however it is worth reflecting on what we
really want here.  If you are writing both the caller and callee, and
want to pass a long string of data, there is no reason to do

(defun callee (&rest x) ...) (defun caller (x) (apply 'callee x))

as opposed to 

(defun callee (x) ...) (defun caller (x) (callee x))

At least in safe mode, the implementation *must* at least count the
arguments in the first call to be compliant, and might even recons the
list.  The counting for your purposes appears to be useless overhead.
You want no lesser barrier at all short of machine memory to prevent the
call, so you really want the second version.

I would be very surprised if the maxima $matrix function did not fall
into this category.

Even if you are generating calls in macros and specify all 100+ symbols,
&rest will eventually cons them up, so the macro might as well do that
in the first place.

Now if you do not control the callee, like '+, then you have already
described the situation -- there is #'reduce but some people don't want
to use it.  Its hard to figure out where such an argument might end.

If for some reason one really wants to use apply, but to avoid the
checking that apply entails, one can compile in non-safe mode:

=============================================================================
(defun foo (x) (apply '+ x))

FOO

>(setq a (let ((i -1)) (mapl (lambda (x) (setf (car x) (incf i))) (make-list 
>1000))))

...

>(foo a)

Error:  Lisps arglist maximum surpassed
Fast links are on: do (si::use-fast-links nil) for debugging
Error signalled by APPLY.
Broken at APPLY.  Type :H for Help.
>>:q

Top level.
>(compile 'foo)

Compiling /tmp/gazonk_11010_0.lsp.
End of Pass 1.  
End of Pass 2.  
OPTIMIZE levels: Safety=0 (No runtime error checking), Space=0, Speed=3
Finished compiling /tmp/gazonk_11010_0.lsp.
Loading /tmp/gazonk_11010_0.o
start address -T 0xf0e510 Finished loading /tmp/gazonk_11010_0.o
#<compiled-function FOO>
NIL
NIL

>(foo a)

499500

>
=============================================================================

Of course the limit could push pushed out of mind and into the future,
only to antagonize another day.  That approach is depressingly
reminiscent of current politics :-).

Take care,
-- 
Camm Maguire                                        address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah



reply via email to

[Prev in Thread] Current Thread [Next in Thread]