Re: Updates on Eu 4.2.0
- Posted by ghaberek (admin) Nov 23, 2021
- 2096 views
My 2 new pence worth - if the meanings follow C, then I have no problem - if it's significantly different then it could create confusion. ie if a struct in Euphoria can create a struct that C can use, then that's good. If you have to do much fiddling to get the eu struct to a c struct then that is not good. I take it the idea is to get direct insertion into C created DLLs?
Yes, that's the intent. Here's the introduction from the docs. You can read more here: Memory Structures
Introduction
Writing Euphoria code to interact with the operating system or external libraries often requires communicating via data structures stored in memory. In addition to using peeks and pokes to read and write to memory locations, Euphoria programmers can also define structures that can be used to more easily read and write values from and into memory.
The conventions used are similar to those found in the C programming language, since that's the way the most commonly encountered structures are defined and meant to be used. This is meant to provide a familiar syntax to those who already know C, and also to make it easy to define and use memory structures.
I'd say the only thing "Euphorian" about the syntax is that we're avoiding the use of the asterisk * for pointer declarations, and instead using the literal keyword pointer. However, it seems Matt still chose to use an asterisk for dereferencing pointers, which I'm not fond of.
Reading and assigning with pointers
A memstruct member that is itself a pointer has an additional way to be used. The normal assignment and reading operations deal with the value of the pointer itself. To access the value to which the pointer points, use an additional dot, then an asterisk:
memstruct PTR_TO_INT pointer int a end memstruct atom ptr = allocate( sizeof( PTR_TO_INT ) ) ptr.PTR_TO_INT.a = allocate( sizeof( int ) ) ptr.PTR_TO_INT.a.* = 5 ptr.PTR_TO_INT.a.* += 5 ? ptr.PTR_TO_INT.a.* -- prints 10
I think I'd rather see this syntax go away and instead encourage use of peek() and poke(). Internally, we'd have to adapt the parser to account for memstructs the same way it does for sizeof(). Given the example above, this would probably require introducing some new routines for operating on values memory, like incr() as shown below.
--ptr.PTR_TO_INT.a.* = 5 poke( ptr.PTR_TO_INT.a, 5 ) --ptr.PTR_TO_INT.a.* += 5 incr( ptr.PTR_TO_INT.a, 5 ) --? ptr.PTR_TO_INT.a.* -- prints 10 ? peek( ptr.PTR_TO_INT.a )
I'm not trying to hide pointers from those who want to use them. But I feel like mixing in little bits of C breaks the syntax and readability of Euphoria code. Plus, using routines to do things like this may help people better understand what the code is supposed to be doing.
This seems clear to me. It says, "increment the value at ptr.PTR_TO_INT.a by a value of 5."
incr( ptr.PTR_TO_INT.a, 5 )
Where as this... uh... what's that asterisk for again? I guess it's adding 5 to something?
ptr.PTR_TO_INT.a.* += 5
One thing I've gleaned from playing around with newer languages like Go, Rust, etc. is that they really love their punctuation-based and abbreviated-keyword syntax, to the point where a newcomer to the language can't make sense of what's going on without keeping a reference manual in their hand. The power of Euphoria, I believe, is that anyone can read the code out loud and make sense of it. I want to ensure we maintain this. I'm not sure we can lean hard on "the fastest" any more, but we can still promote "clean and readable" code.
Again, I'm open to suggestions. Changes like these may be worthwhile but will also take more time.
-Greg
