1. Re: Digest for EUforum at topica.com, issue 6333
- Posted by cchris005 at fastmail.fm
Jan 09, 2007
-
Last edited Jan 10, 2007
> Subject: Re: Digest for EUforum at topica.com, issue 6333
>
>
> posted by: Pete Lomax <petelomax at blueyonder.co.uk>
>
> CChris wrote:
> > }}}
<eucode>
> > function pop(byref sequence stack)
> > object top
> > top=stack[$]
> > stack=stack[1..$-1]
> > return top
> > end function
> > </eucode>
{{{
>
> > Currently, you need to return both the modified stack and the former top
> > element, which is awkward.
>
> FWIW, I plan something like:
> }}}
<eucode>
> function[2] pop(sequence stack)
> return stack[$], stack[1..$-1]
> end function
>
> {nextitem,stack}=pop(stack)
> </eucode>
{{{
>
> > More generally, PBR enables to transform an object, rather to return a
> > modified object which you have to copy onto the original - waste of CPU.
> Technically, I plan an "unnecessary" dword move which "true" pbr
> wouldn't; but that is trivial overhead compared to existing cow semantics
> (in fact so trivial I very much doubt it would ever show on any timing
> test).
>
Would that "dword move" also work when transforming a subscripted
quantity, like (3]?
And, by the way, would you really expect to get the modified stack in
the returned value? I probably programmed too much in asm, but I find
this a bit confusing. And you have to perform an extra s1=s[1] to get
the value you need. Your proposal doesn't look very good to me.
>
>
> > Eu has function pointers, using call_back(routine_id(rt_name)). What
> > confuses me is why I can't do it with variables. Am I the only one?
>
> Firstly, as background, a routine_id is *utterly meaningless* to any
> other than call_func, call_proc, and call_back. Agreed?
>
True. What is the issue?
> There is possibly, in some distant future, a way to get a variable_id
> that is likewise *utterly meaningless* to any other than two new Eu-only
> routines get_value and set_value. However if you have anything like
> call_back() then either:
> a) a pointer to data:
> 1) if it is a shared ref you update both.
> 2) no way whatsoever to reallocate/shrink/expand.
> or:
> b) a pointer to a ref:
> 1) you have to follow all the rules the backend does.
> 2) no way whatsoever can the backend report errors in your code.
>
> There is some mileage in variable_id(), but
> raw_pointer(variable_id(name)),
> you are looking at something the Eu back-end is *designed* to shift
> around,
> allocate, deallocate, and generally manage all memory issues for you in
> the background completely transparently. Really bad idea.
>
> I trust you didn't really mean the call_back() bit.
>
Did you ever try to allow an external dll/piece of code to access an Eu
variable? And do you think this is not right?
Using a get_this_var()/set_this_var(typeof_this_var x) pair for every
such variable looks really like a bad idea to me. That's how we wind up
doing it unfortunately.
raw_pointer() must be there, but, as you emphasized, there must be some
freedom for the backend to play with memory. Windows does so in a simple
way: you refer to memory addresses with handles, and you get a raw
pointer only when you lock the handle. The pointer becomes invalid as
soon as you unlock it.
Admittedly, you an also alloocate an address (isn't this a raw pointer?)
and use this for interfacing. Only problem is that peek/poke are so darn
slow...
But indeed, my primary point was: there's a routine_id, why is a
variable_id() any more complicated? Hence why is it not implemented?
> Regards,
> Pete
>
>
CChris
--
cchris005 at fastmail.fm
--
http://www.fastmail.fm - A no graphics, no pop-ups email service
