1. Type-check behavior
Maybe this is just me, but I think it's silly for Euphoria to do this...
-- Example 1
type string(sequence s) -- abend line
...
end type
? string(5) -- abends w/ type-check fail @ "abend line" (argh!)
-- ideally, it would just print 0 here
--
..which forces us as programmers to write our types like this:
-- Example 2
type string(object s)
if not sequence(s) then -- grumble grumble
return 0 -- it is annoying
end if -- to have to do this
...
end type
? string(5) -- doesn't abend, prints 0
--
What prevents Euphoria from "passing on" the sequence type-check failure in
Example 1 to the point where the string() type was called from, so it
*doesn't* abend?
The way things currently are, I define *all* my types like Example 2 above,
which means that the "object" type is the only one that ever gets used for
my type parms, and I have to start each type with a separate "if" statement,
checking for the type I would *like* to have up in the top line of my type
declaration. This makes my types less readable, and probably makes the types
run one precious picosecond slower as well.
Additionally, with type-checking turned off, all my user-defined types
become generic objects!
-- Example 1a
without type_check
type string(sequence s)
...
end type
string message
message = 5 -- abends, 5 is not a sequence
-- Example 2a
without type_check
type string(object s)
if not sequence(s) then
return 0
end if
...
end type
string message
message = 5 -- doesn't abend!
--
Anyone else think this is a problem?
Be seeing you,
Gabriel Boehme
---------------------
The obligatory quote:
To attract and keep an audience, art must entertain, but the significance of
any art lies in its ability to express truths -- to reveal and help us
understand our world.
Bill Watterson
---------------------
2. Re: Type-check behavior
Boehme, Gabriel[SMTP:gboehme at MUSICLAND.COM] wrote:
>Maybe this is just me, but I think it's silly for Euphoria to do =
this...
>
> -- Example 1
>type string(sequence s) -- abend line
> ...
>end type
>
>? string(5) -- abends w/ type-check fail @ "abend line" (argh!)
> -- ideally, it would just print 0 here
> --
I think I agree here, this warrants a re-evaluation. I understand that =
Euphoria types are supposed to act like functions; but, this leads to =
the above situation when taken to it's extreme. After all, the above =
SHOULD return a 0. Doesn't it make since that if you use a type as a =
function to check an object, it should be able to respond TRUE or FALSE =
to that object, instead of aborting?
I know, I know, if we want to have it act that way, we should make all =
types accept objects and put the sub-type code within the type. But, if =
(in order to make types behave the way they SHOULD) we do that to all of =
our types, what's the point? Why even make (let?) programmers specify =
the "parameter" when it could lead to the above inconsistancy?
Rob, here's an idea; why not save us the hassle and inelegance of the =
above by having types be tokenized differently during the preprocessing =
stage? If for a particular type the programmer declares the parameter as =
anything other than "object", would it not solve everything to have the =
interpreter view that as an object parameter, but insert a check for the =
parameter type at the beginning of the type code? For example, the =
programmer types:
type string (sequence s)
-- the type code
end type
but the interpreter automatically tokenizes it into
type string (object s)
if not sequence (s) then
return 0
end if
-- the type code
end type
It shouldn't slow things down much, if at all... the interpreter must =
already be doing the check. And it would save us the hassle from =
implementing things in a way so that types behave "correctly" as =
functions. I can't see a reason why anyone would NOT want this added as =
a feature--those who don't define their types to accept objects wouldn't =
even notice a change.
It has my vote.
Rod Jackson
3. Re: Type-check behavior
At 01:05 PM 15-03-1999 , you wrote:
>Maybe this is just me, but I think it's silly for Euphoria to do this...
The "sillyness" is that Euphoria should understand that a user defined type
must at least be of the "basic" type of it's parameter. If that's not true,
automatically a type check error (FALSE) shouls be returned.
type foo(sequence param)
...
end type
type bar(integer param)
...
foo foobar
foo foovar
bar barrvar
barvar = 10
-- 10 is an integer, so the rest of 'bar' type checking is performed.
foovar = barvar
-- barvar ain't a sequence, 'foo' type checking is completly ommited.
I'm certain Robert will be glad to include this "optimization" to future
realeases of Euphoria.
Regards,
Daniel Berstein
[ daber at pair.com ]
4. Re: Type-check behavior
- Posted by Ralf Nieuwenhuijsen <nieuwen at XS4ALL.NL>
Mar 15, 1999
-
Last edited Mar 16, 1999
> Maybe this is just me, but I think it's silly for Euphoria to do this...
Its not you. I have pointed this out several times in the past.
Unfortunately Robert never really responded with any arguments (other than: "I
believe you mentioned that before"), and Im still
lost as the reason why this works this way. (yeah, internally it makes sense, a
type check is just a function, but by declaring
it as a type you are able to declare variables with its name and have the
associated function as the check-value function)
Someday I'll just write a preproccesor to handle that stuff, or at least, I keep
telling myself.
type bug (sequence s)
return length(s) = 3 and equal(bug[3],'G')
end type
? bug ("BUG")
-- prints 1
? bug ("BU")
-- crashes: short-circuiting, of all places, is not implemented here
? bug (1)
-- crashes: type check error ... (arrg.. I was *checking* the type)
type nobug (object s)
if sequence (s) then
if length(s) = 3 then
return equal (s[3], 'G')
else
return 0
end if
else
return 0
end if
end type
Ralf N.
nieuwen at xs4all.nl
ralf_n at email.com
