1. Type checking
- Posted by petelomax at blueyonder.co.uk Aug 10, 2002
- 608 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
- 563 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
- 580 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
- 554 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
