On 7/30/2011 1:50 AM, David Barbour wrote:
On Sat, Jul 30, 2011 at 12:44 AM, BGB <cr88...@gmail.com
<mailto:cr88...@gmail.com>> wrote:
it is a generalized issue of API designs, or more correctly,
the common lack of good external APIs.
Ah. I suppose, if someone manufactured a gun that shot both ways and a
lot of people hurt themselves or their allies, you would call the
problem "a generalized issue of aim and awareness, or more correctly,
the common lack of careful aim by the users". Because blaming the tool
would be ridiculous.
I think the problem is: /too much power, with too little perspective.
/An excess of power allows developers to ignore integration and
composition concerns as they build their abstractions - i.e. because
they can hide any abstraction inside a Turing-powerful calculation.
The lack of perspective means they don't even know what integration
and composition concerns they should be considering.
That is /why/ we have 'a common lack of good external APIs'. Asking
people to design better is not a reasonable or realistic answer.
both heterogeneous address spaces, closures, etc..., work fine
with a stack model.
under what basis do you think they are problematic?...
Closures created in stacks only pass easily in one direction - i.e.
you cannot easily 'return' them.
nope.
this actually works as well, since one then "captures" the closed over
state (producing a closure object). the use of a stack-based execution
model does not mean the inability to capture lexical binding frames.
also note that stack-machine != machine-stack.
yes, they are both called "stack", but little is really in common beyond
this point.
the use of an RPN based model is largely unrelated to the use of a stack
either for representing local variables (for example, they can be stored
on the heap), or for how call-frames are represented (heap-based call
frames are possible, and in fact, not even particularly rare).
one can in-fact use a stack-machine model, and proceed to implement
operations like call/cc (call-with-current-continuation) as well.
Concurrency - stacks and interrupts don't mix in a very predictable
way, and one cannot predict how long it will be before an asynchronous
event is handled. Regarding heterogeneous address spaces: can you
actually provide an example of a single stack crossing multiple
address spaces that doesn't have a lot of 'complications' involved
with references and such? or are you assuming that using something
other than a stack machine abstraction somehow qualifies as a success
for 'stack machine'?
this is again, a matter of "the machine stack", not of a "stack machine".
one could have a stack machine, implemented in terms of lists of
cons-cells, and this still works.
the stack can in-fact be mapped purely to machine registers, and this
also works.
We've found adequate ways to hack around the stack machine
abstraction. But the need to work around the too-simple abstraction,
BGB, is the very nature of 'simplistic'. It is preferable that we work
with our abstractions, not around them.
except, that these are not the same sorts of stack.
your argument could be taken as "maybe the way x86 / ARM / ... do stacks
is not ideal" (IOW: representing "a stack" as a big region of memory
with a sliding pointer). this is more plausible.
but, this has little to do with either RPN or the stack-machine abstraction.
in-fact, a naive 1:1 mapping doesn't even really work out in a compiler
(consider the simple issue of dealing with several different calling
conventions: a naive 1:1 mapping just wouldn't work, say, if the calling
convention expects arguments in the reverse order, or expects values to
be passed in registers, or, ...).
the "stack" the compiler sees, in effect, doesn't actually exist at runtime.
_______________________________________________
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
