OpenEuphoria

1. Integrating string types into EUPHORIA handling

• Posted by SDPringle May 04, 2014
• 1542 views

Forked from Re: Euphoria vs The Other Guys

I really mean we can use UDTs for assignments and explicit checks. In fact the standard library has 'string' so I should have said a UDT already exists there. Did you mean we cannot use UDT routines for things other than assignments and tests or did you mean we don't have operator overloading in EUPHORIA? I don't think we need to.

One could implement string the same way as sequence is. That is to say use the same structure. We would need to add a special call to make sure it is a valid string but other than that just use struct s1. We have three representations for objects: struct s1, struct d, and int. If you add another we go from binary operations having to handle 9 cases to operations having to handle 16. [/quote]

[/quote]

I have thought this out down this same path. I would love for the interpreter to magically help the user and re-encode the strings to the way they ought to be when calling C routines.

I pass the buck to library implemntations and that means us with the Standard Library. If we had different UDT for different encodings we could have ascii_string, codepage800string, utf_string, etc... The EUPHORIA type system could not always tell if they were encoded as we normally encode strings if you passed the wrong kind of string to the wrong place. You could have magic numbers in strings but they would be magic, string packages instead of just strings. We could just leave things simple and let the users figure it out. Most importantly library implementors should always specify what kind of string they are expecting for a given routine.

3. Re: Integrating string types into EUPHORIA handling

• Posted by DerekParnell (admin) May 04, 2014
• 1477 views

Both.

string A 
string B 
string C 
object D 
 
A = "Some text" 
B = "And here is some more text" 
 
C = A + B  -- Should the parser or runtime allow this? Is it addition or concatenation? 
 
D = A * B  -- And what about this (assigning to an 'object')? 

Yes, and don't forget the translator too. It emits code depending on the data types of the operands.

I too feel that string handling, especially for unicode, needs to be library based rather than built-in to the language. However, we should not also be re-inventing the wheel. There exists a few good C-Based unicode libraries already and we should leverage off those, and the best way to do that is to statically link the unicode library into the EUI executable. An alternative would be to create a DLL shim and load the unicode library at runtime as needed. Either way, the unicode specific functionality would not be coded in Euphoria, only the bare minimum required to interface with the third party routines.

5. Re: Integrating string types into EUPHORIA handling

• Posted by ghaberek (admin) May 05, 2014
• 1402 views

euadvlib does this.

override function c_func( integer rid, sequence args = {} ) 
     
    -- get the argument types and return type 
    sequence arg_types = map:get( m_args, rid, {} ) 
    atom return_type = map:get( m_retv, rid, 0 ) 
     
    -- make sure we have the correct number of arguments 
    if length( args ) = length( arg_types ) then 
         
        for i = 1 to length( args ) do 
             
            -- allocate strings as necessary 
             
            if sequence( args[i] ) and arg_types[i] = C_STRING then 
                args[i] = allocate_string( args[i], 1 ) 
            elsif sequence( args[i] ) and arg_types[i] = C_WSTRING then 
                args[i] = allocate_wstring( args[i], 1 ) 
            end if 
             
        end for 
         
    end if 
     
    -- call the function 
    object result = eu:c_func( rid, args ) 
     
    -- fetch strings as necessary 
    if return_type = C_STRING then 
        result = peek_string( result ) 
    elsif return_type = C_WSTRING then 
        result = peek_wstring( result ) 
    end if 
     
    return result 
end function 

-Greg