Re: RE: Danger! Type-checking & the translator
Hi the list!
Andy, sos your statement mean that the code should be run with
type_check on, which sometimes slows things down in a significant way?
Unless you use the side effect types in routine arguments only, since
type checking is not likely to be skipped there. The docs are
notoriously vague about this: the definition of "crucial places" is
missing. I never relied on this for this reason.
CChris
> ajm.tammer at quicknet.nl wrote:
> > 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??
> >
>
> Yes, that's right -- I don't want z to be local to the type -- I want z
> to be a side-effect of assigning something to y. (In practice, z would
> take on different values depending on what you assigned to y).
>
> As to what use that type of thing is, there are lots of uses, and lots
> of people have taken advantage of them. You can look at custom defined
> types as "functions which are automatically called when assigning a
> value to a variable of that type." That can be very useful. Which is
> why I'm freaking out a bit here, because it means if I want to use the
> translator, I potentially have to check not only my own code but examine
> and recode any libraries I might download from the archive. I gave
> Diamond as an example, which I know contains code that depends on type
> code being called.
>
> Which is why it is not just a debugging issue -- it means that
> translated programs possibly need to use completely different ALGORITHMS
> that non-translated programs, and it also means you can not necessarily
> expect a translated program, even a bug-free one, to work as it does
> before translation. That is a major flaw, to say the least.
>
> Here's an example. In the Berkeley DB code I'm now working with, every
> database call returns an error code. Some errors are "expected", like
> KEY NOT FOUND. Others are unexpected, and the program needs to shut
> down at that point. But to avoid corruption, I want to close all the
> databases cleanly to make sure everything is committed to disk.
>
> So I make a type such as:
>
> type db_error(integer x)
> if x != 0 then -- if there is an error
> bdb_close_all() -- close all databases
> return 0 -- type check failure, causes abort
> else
> return 1
> end type
> db_error err
>
> Now everytime I do a db call, I do it like:
>
> err = bdb_open(db_name)
>
> Nice and elegant.
>
> Now, on error, all the db's are automatically shut down. Translate that
> program, and the error code is not even checked at all! Disaster! I'm
> going to have to change 1000's of lines of code now. (By the way, this
> is the same reason we need a crash_proc() function to set a procedure to
> be called on a crash -- with a syntax error I'm looking at possible
> database corruption because I don't get a chance to shut them down
> properly.)
>
> Or you might have an exception handling system with types that always
> return TRUE, but nevertheless set some internal exception variable so
> your program can deal with the error without crashing. If the type code
> is never called, disaster there too.
>
|
Not Categorized, Please Help
|
|
