1. RE: Danger! Type-checking & the translator
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
Forgive me for being slow, but wasn't that the intent? It appeared to
me that Andy was using Z as a flag to tell when the type was checked.
Phil the Confused
>
> :) 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??
>
>
2. RE: Danger! Type-checking & the translator
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.
3. RE: Danger! Type-checking & the translator
>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...
***********************************************************************
***********************************************************************
4. RE: Danger! Type-checking & the translator
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.
>
Yeah, that makes me real nervous. As I said, that means I have to check
not only all my own code but all libraries I want to use. Is there a
special reason it is unfeasible to have translated programs do type
checking (if desired)?
Something should either be part of the language or not. Whatever you
think of my algorithmic choices, they should at least work consistently,
regardless of what "most people" may or may not be doing.
> 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...
>
>
No problem with coding around this stuff, but the code isn't as clean.
(And my name ain't Pete.)
-- Andy
5. RE: Danger! Type-checking & the translator
> 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...
6. RE: Danger! Type-checking & the translator
Robert Craig wrote:
> 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.
>
Very good.
When you say "report will be issued" that means crash, right?
In other words, if I have a type call that is left in, and it returns 0
(False), I can count on it to abort at that point, correct? Of course,
I can just put in an abort(), but just to be clear.
7. 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.
>
8. RE: Danger! Type-checking & the translator
- Posted by rforno at tutopia.com
Jan 28, 2003
I am not using types nor even the translator right now, but obviously I also
agree.
Regards.
----- Original Message -----
From: Derek Parnell <ddparnell at bigpond.com>
Subject: 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
>
>
>
> TOPICA - Start your own email discussion group. FREE!
>
