1. Type checking
- Posted by petelomax at blueyonder.co.uk Aug 10, 2002
- 503 views
{{{ I had something like
integer a,b,c sequence x,y,z
& stupidly put ",text" at the end of the first line not 2nd.
The line text{} blew up when it ran, but I was surprised it didn't blow up when the interpreter first loaded it.
How much overhead would it cause to add simple checks during load? Do bind, shroud, or euphoria to C perform such checks?
Pete
2. Re: Type checking
- Posted by Robert Craig <rds at RapidEuphoria.com> Aug 10, 2002
- 465 views
Pete Lomax writes: > I had something like > > integer a,b,c > sequence x,y,z > > & stupidly put ",text" at the end of the first line not 2nd. > > The line text={} blew up when it ran, but I was surprised it didn't > blow up when the interpreter first loaded it. > > How much overhead would it cause to add simple checks during load? > Do bind, shroud, or euphoria to C perform such checks? Bind and shroud know almost nothing about the type of data you are using. They do very little error checking of any kind. The interpreter and translator share the same "front-end". That front-end concentrates on syntax and variable-not-declared sorts of errors at "compile-time". I could add lots of extra special-case compile-time error checking in the front-end, for instance catching your text={} statement, but not catching more general statements. There would be value in catching errors earlier, and in some cases the offending code might be in a statement that is rarely, if ever executed, so you'd be happy to be told about the problem. I've been tempted to add more error checks like this, on an ad-hoc basis, but the fact that these checks are semi-redundant with equivalent run-time checks, has made me feel it's not worth the trouble. If I start doing it now, it could break existing programs. e.g. some useful library has a bug in a statement that's only executed in a rare error-condition, but the novice Euphoria user gets a compile-time error and gives up. Just giving a warning would seem rather timid, given that the statement can't execute at all. Regards, Rob Craig Rapid Deployment Software http://www.RapidEuphoria.com
3. Re: Type checking
- Posted by jbrown105 at speedymail.org Aug 15, 2002
- 482 views
On 0, petelomax at blueyonder.co.uk wrote: > > I had something like > > integer a,b,c > sequence x,y,z > > & stupidly put ",text" at the end of the first line not 2nd. > > The line text={} blew up when it ran, but I was surprised it didn't > blow up when the interpreter first loaded it. > > How much overhead would it cause to add simple checks during load? > Do bind, shroud, or euphoria to C perform such checks? > > Pete > I dont know how much overhead it would make, for a small program you probably wouldnt notice it though. bind and shroud will do only syntax checking for the most part, they wont check this. As for Eu2C, I am not quite sure, but being a run time error it probably is not checked. jbrown -- http://fastmail.fm - You've just been FastMailed!
4. Re: Type checking
- Posted by petelomax at blueyonder.co.uk Aug 30, 2002
- 464 views
On Sat, 10 Aug 2002 21:25:35 -0400, Robert Craig <rds at RapidEuphoria.com> wrote: Apologies for delayed response; been off-line for nearly three weeks. (Hi, again everyone!) >Pete Lomax writes: >> I had something like >> >> integer a,b,c >> sequence x,y,z >> >> & stupidly put ",text" at the end of the first line not 2nd. >> >> The line text{} blew up when it ran, but I was surprised it didn't >> blow up when the interpreter first loaded it. >> >> How much overhead would it cause to add simple checks during load? >> Do bind, shroud, or euphoria to C perform such checks? >Bind and shroud know almost nothing about the type of data >you are using. They do very little error checking of any kind. >The interpreter and translator share the same "front-end". I guessed as much.. >That front-end concentrates on syntax and >variable-not-declared sorts of errors at "compile-time". >I could add lots of extra special-case compile-time error checking >in the front-end, for instance catching your text{} statement, >but not catching more general statements. True, hadn't really thought that thru - you'd need AI techniques to determine the type a function returns, eg integer i=funcX(blah) when funcX(..) can somecases return sequence, othertimes integer, etc. >There would be value in catching errors earlier, and in some >cases the offending code might be in a statement that is >rarely, if ever executed, so you'd be happy to be told about the problem. >I've been tempted to add more error checks like this, on an ad-hoc basis, >but the fact that these checks are semi-redundant with equivalent run-time >checks, has made me feel it's not worth the trouble. The more I think about it, the more I agree >If I start doing it now, it could break existing programs. e.g. some >useful library has a bug in a statement that's only executed in a >rare error-condition, but the novice Euphoria user gets a >compile-time error and gives up. Just giving a warning >would seem rather timid, given that the statement can't execute at all. Ditto An industrial-strength syntax/semantics checking program sounds dandy, especially to soothe the nerves prior to release, but testing the code in the first place should be a higher priority! Pete