OpenEuphoria

Re: Big String Idea for v2.6

• Posted by Al Getz <Xaxo at aol.com> Jul 19, 2005
• 470 views

Hi Rob and Derek,

Rob:
I see what you mean now...and i see you're going for the most timeless
solution possible.  That makes a lot of sense.  Thanks much for your
rather detailed explanation and i see already others have taken note too.

Derek:
Yes :)  As you can see from the above, I cant help but agree with Rob, and
also with your reply; esp with...
  "Simple things like ASCII strings formatted in the C style don't really
   need much more assistance."
Thanks for your added comments.


Take care,
Al


Derek Parnell wrote:
> 
> 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
> 



And, good luck with your Euphoria programming!

My bumper sticker: "I brake for LED's"