1. Danger! Type-checking & the translator
Hello,
I know that translated programs don't do type-checking, but I assumed
this was for built-in Euphoria types, not user-specifed types.
Apparently I was wrong. Take the following program:
integer z
z = 0
type test(object x)
z = 1
return 1
end type
test y
y = 4
? z
Now every time y is assigned a value, it has the side effect of assining
a value to z. Run with the interpreter, and the output is:
1
Translated, the output is 0 -- the type code is never called.
Unless I'm just doing something stupid, this is major. Anything that
depends on custom-types for exception handling or these type of side
effects won't work when translated. This breaks *LOTS* of code when
translating, including major libraries like Mike Nelson's Diamond. Why
isn't this in the docs? The translator docs say:
"Note: The translator assumes that your program has no run-time errors
in it that would be caught by the interpreter. The translator does not
check for: subscript out of bounds, variable not initialized, assigning
the wrong type of data to a variable, etc. "
This goes way beyond debugging. It should say, "You can't use custom
types in translated programs, period."
Please tell me I'm wrong about this...
2. Re: Danger! Type-checking & the translator
Hi Andy
You did not declare z to be local to the type(routine) so yhe code inside the
routine assigns a value ON YOUR COMMAND to the higherleveled z ouside it
:) a@t aka ekhnaton
BTW... what is the use of a type(routine) if you dont use it to check validity
of a user-defined type??
3. Re: Danger! Type-checking & the translator
Hi ekh,
He meant it that way. He is pointing out that if you use the
translator.
Then your type functions will not be executed. Ever!!
Lucius L. Hilley III
----- Original Message -----
From: <ajm.tammer at quicknet.nl>
To: "EUforum" <EUforum at topica.com>
Subject: Re: Danger! Type-checking & the translator
>
> Hi Andy
>
> You did not declare z to be local to the type(routine) so yhe code inside
the routine assigns a value ON YOUR COMMAND to the higherleveled z ouside it
>
> :) a@t aka ekhnaton
>
> BTW... what is the use of a type(routine) if you dont use it to check
validity of a user-defined type??
>
>
>
> TOPICA - Start your own email discussion group. FREE!
>
>
4. Re: Danger! Type-checking & the translator
Andy Serpa writes:
> Anything that depends on custom-types for exception handling
> or these type of side effects won't work when translated.
> This breaks *LOTS* of code when translating, including major
> libraries like Mike Nelson's Diamond. Why isn't this in the docs?
According to the Translator docs:
"User-defined types will not affect your speed. They are ignored by the
translator unless you also call them directly with normal function calls."
You can call a type, just as you would call a function,
and the Translator will do it. It just won't
call the type when you assign to a variable of that type.
As for breaking *LOTS* of code, I've found that few people bother
to define user-defined types, and when they do, the types
are very simple and side-effect free. I haven't translated any program
that broke because it was using types in weird ways.
I just translated a Diamond example, and it seemed to work ok.
It might just be the exception handling that won't work as well
with the Translator.
> It should say, "You can't use custom
> types in translated programs, period."
Of course you can, but they are ignored
just as if you had said "without type_check".
Actually, they are not completely ignored.
The Translator can still pick up information from them,
such as whether your variable is a subset of integer, sequence etc.
Type checking is meant to be used for catching errors,
and for debugging. I wouldn't recommend using it as
an integral part of your algorithm. You are free to do so of course,
but the Translator doesn't support that. In the future, it might be
possible to automatically call those types that contain side-effects.
It won't be in 2.4 though. My schedule has slipped too much already.
I'm still hoping for a release in 10 days (I added some new stuff).
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
5. Re: Danger! Type-checking & the translator
On Mon, 27 Jan 2003 23:54:15 +0000, Andy Serpa <ac at onehorseshy.com> wrote:
>
>
>> According to the Translator docs:
>>
>> "User-defined types will not affect your speed. They are ignored by the
>> translator unless you also call them directly with normal function
>> calls."
>>
> Ok, found it. It is under the section about "speed" when it ought to be
> mentioned promiently under a section about "why your code might not still
> work".
>
>>
>> > It should say, "You can't use custom
>> > types in translated programs, period."
>>
>> Of course you can, but they are ignored
>> just as if you had said "without type_check".
>> Actually, they are not completely ignored.
>> The Translator can still pick up information from them,
>> such as whether your variable is a subset of integer, sequence etc.
>>
> Well, if you have to call them explicitly, then they become normal
> functions. Effectively, you can't use types as types.
>
>> It won't be in 2.4 though. My schedule has slipped too much already.
>> I'm still hoping for a release in 10 days (I added some new stuff).
>>
>
> Please, put it on the list for 2.5...
>
>
>
> TOPICA - Start your own email discussion group. FREE!
>
>
Agreed. The only advantage of types over normal functions is that they are
called automatically. If the translator omits that, then why bother with
them at all?
--
cheers,
Derek Parnell
6. Re: Danger! Type-checking & the translator
OK, I'll try to do the following for 2.4.
It should only delay me a day or so.
If you say "without type_check",
then you'll get absolutely no user-defined type checking
(interpreter or translator).
If "with type_check" is in effect,
as it is by default, then translated code
will automatically call (i.e. on assignment) any types that
have side effects. All other type checks will be ignored
as they are now. I'm already keeping track of which routines
have side-effects - writing to a global variable,
poking into memory, doing I/O, calling another routine that
has side effects etc. So it becomes an optimization issue.
The Translator will optimize-out type calls that can
safely be removed, given that your program is supposed to be free
of type check errors when you use the Translator.
This should eliminate all "normal" type calls.
Calls that might involve side effects will be left in, and a report
will be issued if they generate a type check error.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
7. Re: Danger! Type-checking & the translator
Andy Serpa writes:
> When you say "report will be issued" that means crash, right?
Yes.
The program will halt, and a type_check failure message
will be on the screen and in ex.err.
There won't be any Euphoria call-stack
traceback, or variable dump.
That's not possible with translated code.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
8. Re: Danger! Type-checking & the translator
ACK!!!
I'm writing an exceptions lib, which would allow you to catch almost every
possible runtime error via eu_errno, rather than crashing. (I.e., using
e_puts() instead of puts(), e_close() instead of close(), op_eq() instead of
'=', op_gr() isntead of '>', etc, would catch errors and set eu_errno,
instead of letting the interpreter barf.) Its nowhere near complete however,
(only a few functions and already nearing a thousand lines! the thing, when
finished, will probably be HUGE!!!), what it does to attempt to catch type-
check errors, is always return true, but to set eu_errno, so the program can
catch the type check error in the code, after the variable has been assigned
to.
Apparently it'll be useless for the translator, however.
disappointed,
jbrown
On Tue, Jan 28, 2003 at 09:35:11AM +1100, Patrick.Barnes at transgrid.com.au
wrote:
>
> >From Robert Craig:
> >Type checking is meant to be used for catching errors,
> >and for debugging. I wouldn't recommend using it as
> >an integral part of your algorithm.
>
> Ummm, it can't catch errors if it's not used, I would think...
> The use of custom types is a valid way of programming, and having an
> interpreter and a translator looking at the code differently is an
> error, no matter how you justify it.
>
> Ok, to type check custom types every time a value is assigned is going
> to slow things down a little, so perhaps if the programmer explicitly declares
> 'with type_check' then it will...
>
> Also Pete, each of your instances of
>
> type db_error(integer s)
> if
> ---stuff
> return 1
> end if
>
> err = db_function(arg, arg2, arg3)
>
> could be replaced with
>
> type db_error(integer s)
> if
> ---stuff
> return 1
> end if
>
> if db_error( db_function(arg, arg2, arg3) ) end if
>
>
> or something similar...
>
>
> ***********************************************************************
>
>
> ***********************************************************************
>
>
>
> TOPICA - Start your own email discussion group. FREE!
--
/"\ ASCII ribbon |
\ / campain against | Linux User:190064
X HTML in e-mail and | Linux Machine:84163
/*\ news, and unneeded MIME |
