OpenEuphoria

Re: Digest for EUforum at topica.com, issue 6333

• Posted by cchris005 at fastmail.fm Jan 09, 2007
• 461 views

> 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