1. Types
Some questions about types and type-checking:
The Euphoria manual says:
"Even when you turn off type checking, Euphoria reserves the right
to make checks at strategic places, since this can actually allow
it to run your program faster in many cases. So you may still get
a type check failure even when you have turned off type checking."
I would like some more specific information about this: I might need
to do some half-forbidden stuff.
Example 1:
integer i
without type_check
i = 3.45 -- this will crash
with type_check
Example 2:
integer i
without type_check
i = {} -- this won't work either
with type_check
Example 3:
sequence s
without type_check
s = 8 -- neither will this
with type_check
Example 4:
atom a
without type_check
a = {} -- this works!!!!
with type_check
Example 5:
type my_integer(object x)
return integer(x)
end type
type my_sequence(object x)
return sequence(x)
end type
type my_constant(object x)
return 0
end type
my_integer i
my_sequence s
my_constant c
without type_check
i = {} -- works
s = 8 -- works
c = "qwertyuiop" -- works
with type_check
Question: Will the above examples always turn out the same way?
(i e: when type-checking is turned off, variables declared as
integers or sequences are always type-checked, while atoms and
user-defined types are never checked)
-------
Another issue:
"types
These are special functions that may be used in declaring the
allowed values for a variable. A type must have exactly one parameter
and should return an atom that is either true (non-zero) or false
(zero). Types can also be called just like other functions."
Question: Are these the ONLY differences? (logically as well as
performanceically)
i e: Could I, if I by some perverted reason wanted to do so, declare
all my functions that take one argument and return integers, as types?
As far as I understand, types have routine-id:s, and can have side-
effects.
Just want to be really sure.
Thanks in advance
Martin Nilsson
2. Re: Types
On Sun, 26 Mar 2000, Martin Nilsson wrote:
<snip>
> Another issue:
>
> "types
>
> These are special functions that may be used in declaring the
> allowed values for a variable. A type must have exactly one parameter
> and should return an atom that is either true (non-zero) or false
> (zero). Types can also be called just like other functions."
>
>
> Question: Are these the ONLY differences? (logically as well as
> performanceically)
> i e: Could I, if I by some perverted reason wanted to do so, declare
> all my functions that take one argument and return integers, as types?
> As far as I understand, types have routine-id:s, and can have side-
> effects.
There must be some differences in implementation. When type() is called in the
course of an assignment to a typed variable, the call takes 8 - 10% longer
than a plain function call. If type() is called as a function, then it takes a
whopping 2.5x longer!
x = 0 -- .62 sec for 10000000 iterations plain assignment
x = myfunc(0) -- 3.0 sec. function call
mt = 0 -- 3.25 sec. typed assignment
x = mytype(0) -- 7.7 sec. calling type() as a function
Regards,
Irv
3. Re: Types
----- Original Message -----
From: "Martin Nilsson" <skrjablin at MAIL.COM>
To: <EUPHORIA at LISTSERV.MUOHIO.EDU>
Sent: Sunday, March 26, 2000 11:58 AM
Subject: Types
> Some questions about types and type-checking:
>
> The Euphoria manual says:
>
> "Even when you turn off type checking, Euphoria reserves the right
> to make checks at strategic places, since this can actually allow
> it to run your program faster in many cases. So you may still get
> a type check failure even when you have turned off type checking."
>
> I would like some more specific information about this: I might need
> to do some half-forbidden stuff.
>
> Example 1:
>
> integer i
>
> without type_check
> i = 3.45 -- this will crash
> with type_check
>
<snip>
Can you define then all as objects, then do the type checking as you need
to? You can put anything into an object, right?, then in your code, when you
need to know if it is an atom, use the atom test, if you need to know if
it's a sequence, check for that, etc. If you need to know if it's an
integer, test for that.
Kat
4. Re: Types
- Posted by Robert Craig <rds at ATTCANADA.NET>
Mar 26, 2000
-
Last edited Mar 27, 2000
Martin Nilson writes:
> Question: Will the above examples always turn out the same way?
> (i e: when type-checking is turned off, variables declared as
> integers or sequences are always type-checked, while atoms and
> user-defined types are never checked)
The manual is deliberately vague about the
type-checking that will continue to happen even when
you say "without type_check". It's vague because this
is meant to be left up to the implementer of Euphoria,
and the details could change in future releases of the interpreter,
or might be different in a Euphoria compiler (if ever).
With the *current* implementation, Euphoria will continue
to enforce the integer and sequence type checks,
for example,
atom a
sequence s
integer i
s = 5 -- this will be caught
i = {} -- this will be caught
a = {1,2,3} -- this will *not* be caught
and if you have a user-defined type:
type foo(integer x)
return x >= 0 and x < 10
end type
foo f
f = 99 -- this will not be caught
f = 1.5 -- this will be caught
f = {} -- this will be caught
In other words, it will enforce integer and sequence
when they are in the parameter declaration of the type,
but it will not execute any code inside the type.
There are generally more, often many more, references
to the value of a variable, than there are assignments to the
variable. A type-check wastes a bit of time when
you assign, but makes up for it when you read the
value of the variable. In Euphoria this is particularly true
of integers and sequences, but not so much in the
case of atoms (long story omitted).
> "Types can also be called just like other functions."
> Question: Are these the ONLY differences? (logically as
> well as performanceically)
Yes.
Irv Mullins writes:
> If type() is called as a function, then it takes a
> whopping 2.5x longer!
I can't think of any reason why declaring a function as
a type would affect its performance. A quick test I just
tried showed equal performance.
function foo(integer i) -- same time when this is "type foo"
return i
end function
integer x
atom t
t = time()
for i = 1 to 10000000 do
x = foo(0)
end for
?time()-t -- 3.4 seconds on Pentium-350
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
5. Re: Types
Robert Craig wrote:
>With the *current* implementation, Euphoria will continue
>to enforce the integer and sequence type checks,
. . .
>and if you have a user-defined type:
>
>type foo(integer x)
> return x >= 0 and x < 10
>end type
>
>foo f
>
>f = 99 -- this will not be caught
>f = 1.5 -- this will be caught
Thanks. I realize this is a very special question - you shouldn't fool
around with stuff like this normally; I'm experimenting about how to get
the side effects of Kafka's variable declarations to appear in the right
order.
6. Re: Types
Alan replied to Jiri's argument against types:
> As John asked, are you serious? One must check if arguments are
> legal. Would you like to have a calculation crash because way back
> there month was entered as 13/ Social security could crash that way
> because of a typo.
Using types is a debugging tool, but hardly a way to do validation. After
all, if you defined a 'month' type and passed it a 13, that would cause your
program to abort as well.
>> If you accept my previous point about a total uselessness of types,
>> and I expect the more orthodox types among you (sorry about the
>> pun), especially some youngsters, might have a real problem with
>> it, then it follows we should have just one type: objects.
>
> You are suggesting that these object declarations are like constants now,
> that their "type" just be determined internally.
Heh. Except that there are large values that constants can't take on, like
#FFFFFFFF.
But that's beside the point.
Yes, you could replace all the type declarations in your code with 'object',
and the code would run as "correctly" as it did with types - but not as
fast, since Euphoria relies on the types to optimize the code it generates.
>> And they would be automatically declared at, and their names recognized
>> as valid from the point of the first assignment. Note, we would
>> still need the sequence(), atom() and integer() functions!
>
> Jiri, Jiri, Jiri. What's the point? If there's only one type (objects),
> then how can you test for other types? YOU HAVE ONE TYPE.
As Jiri pointed out, there are still sequences, atoms and integers, even if
they are only implicitly declared. Re-read what you wrote about constants:
no declarations, but still different data types.
Here's a snipped of a hypothetical example:
s1 = "foo" & bar
if atom( s1 ) then
The variable s1 is not explicitly declared, but you can still determine the
type, just like with constants.
> Lie down before you e-mail us. Seriously. Like I said, I'm listening,
> and took the time (when I should be writing a news story) to respond.
> I'm not putting you down, but some of what you said is awlfully off base
Actually, you *are* putting him down, both in your condescending tone
("Jiri, Jiri, Jiri") and comments like the ones above.
It's almost as bad as John calling Jiri's ideas "silly" or mine "insane."
Personal attacks are bad form, folks - and certainly not called for!
-- David Cuny
7. Re: Types
- Posted by jiri babor <jbabor at PARADISE.NET.NZ>
Sep 10, 1998
-
Last edited Sep 11, 1998
David Cuny wrote:
>Yes, you could replace all the type declarations in your code with
'object',
>and the code would run as "correctly" as it did with types - but not as
>fast, since Euphoria relies on the types to optimize the code it generates.
Yes and No, David. In fact it will run faster, and sometimes *much* faster
(I do not know why), if you make everything an object, because Euphoria has
nothing to check in case of an object. Just try it, I was initially also
puzzled. But of course there is no difference when the type_check is turned
off. jiri
8. Types
Ralf Nieuwenhuijsen:
>puts(1, "It seems /"TEXT/" is an positive integer\n")
[...]
>This program will crash, unless you change the type definition to:
[...]
It'll also crash if you don't change the forward slashes to backslashes.
:)
That "True/False condition must be an atom" thing did drive me crazy for
awhile too, though. Kinda like figuring out when to use "k" and when to use
'k' in comparisons. I'm beginning to get the hang of that part though.
(yay!)
Ad Rienks:
>if compare(string, {}) = 0 then
[...]
>if not find(string[n], "0123456789.")
[...]
>Hope this helps
Yep! That's even better than the (if not find( string[n],
{'0','1','2','3','4','5','6','7','8','9','.'} ) then) answer I finally came
up with. There's one more place I should use "" instead of ' ' ! :)
Also found the necessity to check for null-strings. Was letting me have
rectangles with only half of one coordinate like "[ 43 ]" instead of "[ 43
24 87 140 ]"
>IMO a better solution would be to reprogram the type definition as a
>function, that can be inside a loop, checking for good input.
Actually that's the way I'm using these. Not to check upon assigning,
but to check before I assign the data, so I can ensure that my complex
sequences are properly structured. Guess I declared 'em as types just
because. That's the way I think of 'em, types of data that you can build
big complex stuff out of. Booleans, Numbers, Strings, Arrays, Dictionarys,
etc.. Maybe it's just a QBasic habit. Seems right somehow, though...since
they're only verifying the validity of the data instead of manipulating it.
I dunno..
(In case you're wondering, I'm on my 3rd different approach at working on
some routines for PDF files now. Complex beasts, they are....)
Arthur Adamson:
> Rob, dictionaries, trees, etc would require considerably less space
>if there was a data type, useable in sequences, one byte instead of 4, to
>hold characters.
> Perhaps bit twiddling can be used instead but it gets tedious and
>difficult.
> Or have I overlooked another way?
I've thought about that a bit myself, especially for string
manipulation. Then I realized that a lot of character sets now use two-byte
characters. (Unicode?) And from what I understand, (disclaimer: I read
this in a book somewhere) the 32-bit data bus in 386dxs and up is actually
quicker and more space efficient with 4-byte chunks than single bytes.
Every memory operation gets/puts 4 bytes anyway, so if you only want one the
CPU has to specify which and 'mask out' the others. Of course, then there's
caches and pipelines and prefetch queues that vary from one processor to the
next to counter that.. So maybe it could be done, but I think it'd turn out
less optimal than it looks unless you special tuned it for each individual
CPU/Bus/Memory configuration. That could get tedious and difficult too.
And of course then someone would want word-sized types... :)
Falkon
9. Types
Just my personal opinion of something I would like to see come down the
pipe some time in the near future hint hint =)
My current beef is with custom types...
=====
Example:
type hour(integer x)
return x >= 0 and x <= 23
end type
hour h1, h2
h1 = 10 -- ok
h2 = 25 -- error! program aborts with a message
=====
Easy to understand yes, but most (actually just about all) of the
regular types in other languages just dont behave this way. What I
would like to propose is more control and flexibility over the final
outcome of a variables value.
=====
Example:
type hour(integer x)
while x < 0 do
x += 24
end while
while x > 23 do
x -= 24
end while
return x -- assigned back to variable
end type
hour h1, h2
h1 = 10 -- ok
h2 = 25 -- ok, h2 is actually assigned the value of 1
=====
While I do agree that the above case is rather striking in its
appearance and effects, and if misused could seriously create hard to
track down bugs, but I also think this kind of addition would create
clearer code in most cases.
In addition, it also paves the way for some very interesting
possibilities like default parameters and other such things...
=====
type args(object params)
-- {required,def=1,def=2}
if atom(params)
return( {params,1,2} )
else
if length(params) = 1 then
return( params & 1 & 2 )
elsif length(params) = 2
return( params & 2 )
end if
end if
return( params[1..3] )
end type
=====
Heh, aww nevermind me... im just blabbing...
I would never actually expect anything like this to actually make it
into production as it violates too many of Euphorias principles.
IMO though it would be nice to have ,)
