OpenEuphoria

Re: fundamental data types in Euphoria cf C/C++

• Posted by Irv Mullins <irvm at ellijay.com> Aug 07, 2001
• 409 views

On Tuesday 07 August 2001 20:41, Alex Caracatsanis wrote:

> I'm intrigued at the difference in number of  basic data types in
> Euphoria compared with C/C++ ( with its int, float, double, short, long,
> etc  ),  and the need to cast from one type to another.
>
> Do you ever have to worry about these things in Euphoria? Does it
> automatically choose the correct type? Does it always automatically cast
> types? Can  Euphoria programs go awry because of the type issue?

Hello Alex:

Euphoria is more of a 'user-typed' language. It has provision for the most 
basic type checking (integer vs. float vs. sequence), but that's all. The 
rest is left up to the programmer to handle. 

Meaning: if you have a sequence that looks like: {65,66,67,68}, then what 
these numbers mean is up to you. Either it is a list of numbers (integers, 
from the looks of them) or it's the string "ABCD".

If the above are stored in a sequence named s, then puts(1,s) prints them
as a string "ABCD", while print(1,s) will print {65,66,67,68}.
Euphoria doesn't care what's there, and does no checking. 

Likewise, if you declare a loop:
for i = 1 to 10 do ..... then i is treated as an integer.
for i = 1 to 10 by .2 do ... i will be treated as an atom.
for i = 'A' to 'D' do ... i will be treated as a number (65,66.....etc)
     puts(1,i)  -- prints "ABCD"
     print(1,i) -- prints 65666768

To save the programmer from a lot of needless mistakes, it is possible to 
declare a variable as an integer, and Euphoria will type check it for you.
It won't let you store a sequence there, or a float, for example. And it 
won't let you store a single number in a sequence. That's about the 
limits of the built-in type checking.

Beyond that, you can declare your own special types, and write type 
checking functions for them.  These can be just about anything (sets,
odd integers, whatever)

Yes, sometimes things don't work as expected because of the lack of 
types. More often, however, the lack of any need for casting makes for 
fewer subtle errors.

Regards,
Irv