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