OpenEuphoria

Re: Big String Idea for v2.6

• Posted by Derek Parnell <ddparnell at bigpond.com> Jul 19, 2005
• 502 views

Robert Craig wrote:
> 
> Al Getz wrote:
> > All one would need is a simple function that gets the pointer
> > to the sequence element and the above code would reduce to something
> > like this:
> > 
> > String="ThisName"
> > retv=c_func(xSetName,{pointer(String)})
> 
> As I've said before, I don't intend to ever give you a 
> function that will tell you the address of a Euphoria 
> variable in memory. Of course you'd also need to know 
> the exact bit and byte layout of the variable, and this
> would have to be defined in the manual.
> 
> I firmly believe this would be a very bad thing to do:
> 
> * I wouldn't be able to move a variable to a new location
>   in memory (e.g. garbage collection).
> 
> * I might not be able to store two variable values in the same
>   place in memory.
> 
> * I wouldn't be able to change the internal representation
>   of Euphoria values in memory.
> 
> * ugly corruption bugs, and hard to read code would result
> 
> You could assume that all elements of a string sequence are 4-byte
> values in Intel byte order, but this is not necessarily true 
> today (some could be floating-point values), and could change drastically 
> in the future, e.g. on a non-Intel machine. Suppose I (or some other 
> implementer of Euphoria) wanted to use one-byte or one-bit per element 
> in the future in some cases?
> 
> There's just no way that I want to expose this information
> to your program. Euphoria is a language of values, not bits,
> bytes and storage locations. You can peek and poke, but only
> with your own blocks of memory, not with Euphoria variables.
> 

I don't do this often but when its due, its due: I fully support Robert's stance
here. Euphoria is *not* and never will be a low-level language.

I know that we will need to interface to non-Euphoria programs and libraries
from time to time, and the current Euphoria already gives us the tools to do
this. At worst, you could say that the tools are not as 'easy' as the rest of
Euphoria to use, so there might be a case for some more syntax sugar to be
sprinkled.

For example, a number of people have developed libraries that assist in
describing RAM layouts (structs) and moving data to and from those. Because of
the flexibility of Euphoria, each library created for this purpose has a
different 'syntax' and usage. So, as this is a commonly used activity for many
programmers, it would be nice for some built-in (i.e. RDS supplied) method of
doing this, in order for some standardization to be put in place. That could
either be a library or built-in keywords.

Simple things like ASCII strings formatted in the C style don't really need much
more assistance. However, the general case of RAM allocation and deallocation,
could be assisted a bit. For example, if RAM is allocated in a routine, Euphoria
could be told to automatically deallocate it when the function is exited. This is
a simple safety measure that would help many coders.

eg...

  procedure SetCursor(integer x, integer y)
      atom pointA
      atom pointB
      pointA = auto_allocate(SIZEOF_point)
      . . . 
      pointB = auto_allocate(SIZEOF_point)
      . . .
      -- At this point, all auto_allocated RAM calls in this
      -- routine would be deallocated.
  end procedure

But certainly, we should never need to know where in RAM Euphoria is managing
its own data items.

-- 
Derek Parnell
Melbourne, Australia
irc://irc.sorcery.net:9000/euphoria