Re: Size of a non numerical indexed table

[David Given <dg@...>]

On Thursday 01 September 2005 17:47, Rici Lake wrote:
[...]
> Not if ... had a lot of elements. I think eachi would have to use two
> different strategies: if called with more than maxupval arguments, it
> would have to create a table and use a different next function.

How does ... work, anyway? Does it actually *copy* the data from its original 
place on the stack, or does it do something smarter?

I ask because I found an interesting idiom recently for doing work with large 
amounts of constant data --- it was while writing the BF compiler, oddly 
enough --- reminiscent of some of the structures used in functional 
programming languages:

function process(item1, item2, ...)
	dosomethingwith(item1, item2)
	return process(...)
end

process("one", "two",
        "three", "four",
        ...etc...
)

In this case it's not really worth it, but I can think of situations when 
something like this might be useful, and I was wondering just how horribly 
inefficient it is. When writing BF, this is a plus, but anything BF-related 
is rather a special case... will I end up with the parameter list duplicated 
lots of times on the stack?

-- 
+- David Given --McQ-+ "I must have spent at least ten minutes out of my
|  dg@cowlark.com    | life talking to this joker like he was a sane
| (dg@tao-group.com) | person. I want a refund." --- Louann Miller, on
+- www.cowlark.com --+ rasfw

Attachment: pgpA2I8Z0eSmT.pgp
Description: PGP signature