1. fundamental data types in Euphoria cf C/C++
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?
Thank you
sunpsych
2. Re: fundamental data types in Euphoria cf C/C++
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
3. Re: fundamental data types in Euphoria cf C/C++
On Tuesday 07 August 2001 22:12, Derek Parnell wrote:
<snip>
> type Address(object x)
> if not sequence (x) then
> return 0
> end if
> if length(x) != AddressLength then
> return 0
> end if
> if not equal(x[aType], AddressType) then
> return 0
> end if
> if not StringASCII(x[aBuilding]) then
> return 0
> end if
> if not StringASCII(x[aStreet]) then
> return 0
> end if
> if not StringASCII(x[aCity]) then
> return 0
> end if
> if not StringASCII(x[aPostCode]) then
> return 0
> end if
> if not StringASCII(x[aCountry]) then
> return 0
> end if
> if not StringASCII(x[aState]) then
> return 0
> end if
>
> return 1
> end type
<snipping resumes>
And, of course you should point out that this is of purely academic
interest, since user-written (as well as built-in) type checking can
only respond by either silently allowing a successful assignment,
or ending the program. Ending a program on a data input error
went out of favor along with the card deck, so programmers must
validate all input anyway. Once validated, there's little reason not
to just store it all as an "object", and dispense with type checking.
Regards,
Irv
4. Re: fundamental data types in Euphoria cf C/C++
Hi Irv,
> From: Irv Mullins <irvm at ellijay.com>
> To: EUforum <EUforum at topica.com>
> Reply-To: EUforum at topica.com
> Subject: Re: fundamental data types in Euphoria cf C/C++
> Date: 8/08/2001 12:54:57 PM
> <snipping resumes>
LOL
> And, of course you should point out that this is of purely academic
> interest, since user-written (as well as built-in) type checking can
> only respond by either silently allowing a successful assignment,
> or ending the program. Ending a program on a data input error
> went out of favor along with the card deck, so programmers must
> validate all input anyway. Once validated, there's little reason not
> to just store it all as an "object", and dispense with type checking.
Couldn't agree more - when we are talking about runtime data validation.
However, I hope that one day Euphoria can do a bit more to help us out with
some improved type checking at program load time, before any data is used in
the program.
----
Cheers,
Derek.
confidential information intended solely for the use of the individual or
entity to whom they are addressed. If you are not the intended recipient of
this message you are hereby notified that any use, dissemination,
distribution or reproduction of this message is prohibited. If you have
received this message in error please notify the sender immediately. Any
views expressed in this message are those of the individual sender and may
not necessarily reflect the views of Global Technology Australasia Limited.
