1. Essential feature: assertions
- Posted by George Henry <ghenryca at LYCOS.COM>
Jan 29, 2001
-
Last edited Jan 30, 2001
I'm in the mood to make some confident assertions.
(There has been quite a bit of talk about Euphoria's suitability for commercial
development.)
A programming language suitable for commercial development, or ANY serious
development, MUST have assertions.
Eiffel, for example (and it is an excellent, if not especially well-known,
example) goes the distance by providing the programmer with pre-conditions,
postconditions, and a couple of flavors of invariants.
Upon entering a routine or block of code, the preconditions are those conditions
which must be true for the code to perform its intended task. These are the
conditions that must be guaranteed to exist in order for the code to function
properly (free of error).
Upon exiting a routine (block), the postconditions are those conditions that the
code guarantees to be true to the calling or succeeding code. They essentially
define what the code is supposed to have accomplished, or the state in which it
leaves the system.
Invariants are conditions that should hold true throughout the execution of a
sequence of code, or a loop. Violation of the invariants indicates that the code
has produced an unintended side effect, a potential if not actual error. The most
familiar example is probably indexing outside the bounds of an array.
Having an assertion facility of this caliber virtually (almost) enables the
programmer to state IN EXECUTABLE CODE, that enables the program to thoroughly
check itself, what the conditions are for correct execution of the code. Woohoo,
that certainly gets us a long way toward writing "commercial-quality" code,
doesn't it? (The non-use of such facilities is one of the reasons Micro$oft's
code, to pick on a company that certainly has NO EXCUSE, is chock-full of
errors.)
Now before everyone (especially Rob?) gets unduly anxious, I am not suggesting
that Euphoria provide precondition, invariant, and postcondition checking -
although it would be fantastic if it did. Right now I would be happy with a
simple assert() facility, such as any ANSI C compiler (or anything close to one)
provides.
When I peruse the Euphoria docs, I find that the list of routines jumps form
arctan to atom without a pause. Where is assert? And I am not aware of an assert
keyword, or any sort of facility that comes close to it, other than
if not myCondition then
? "myCondition failed"
abort(1)
end if
- and there just has to be a better solution than that.
In C, if I recall correctly, assert is a macro that expands into both the
expression you write, and the text of the code, so that if the assertion were
something meaningful for Euphoria, such as
assert(id_vitalProc >= 0)
call_proc(id_vitalProc, vitalArgs)
the code that gets called could display a message something like "assertion
failed: 'id_vitalProc >= 0'".
Euphoria can and should implement assertions in a more elegant way than C. All
that's needed is an "assert" *keyword*, and the syntax "assert <expression>". So
one would write:
assert id_vitalProc >= 0
just as one can currently write
return id_vitalProc >= 0
One of my first thoughts was along the lines of executing a string at runtime,
with the syntax
assert("id_vitalProc >= 0")
The problem with this is that the expression needs to be evaluated in the
context of the current scope. In the various mutations of my example,
id_vitalProc would most likely NOT be a global variable visible inside some
assert() procedure. And it certainly should not have to be.
Anyway, assertions could save me and everyone else lots of grief, lots of stupid
needless program crashes and logic errors, and produce ultimately much more
error-free (or to put it another way, less error-prone, less error-infested)
code, if they were a part of the language.
(That code you think is error-free, isn't - especially if it wasn't developed
using assertions.)
George
Get your small business started at Lycos Small Business at
http://www.lycos.com/business/mail.html
____________________________________________________________
T O P I C A -- Learn More. Surf Less.
Newsletters, Tips and Discussions on Topics You Choose.
http://www.topica.com/partner/tag01
2. Re: Essential feature: assertions
- Posted by Derek Parnell <ddparnell at bigpond.com>
Jan 29, 2001
-
Last edited Jan 30, 2001
----- Original Message -----
From: "George Henry" <ghenryca at LYCOS.COM>
To: "Euphoria" <EUforum at topica.com>
Sent: Tuesday, January 30, 2001 5:07 PM
Subject: Essential feature: assertions
[snip]
> Euphoria can and should implement assertions in a more elegant way than C.
All that's needed is an "assert" *keyword*, and the syntax "assert
<expression>". So one would write:
>
> assert id_vitalProc >= 0
>
I like this idea too. Plus something like ...
with assert -- Evaluate any assert statements
without assert -- Ignore any assert statements
these would enable assert processing to occur during testing/debugging and
also to be skipped ("without assert") when running code where performance is
critical or if installed in production. Though I personnally would want
assertions to execute even in production environments.
------
Derek Parnell
Melbourne, Australia
(Vote [1] The Cheshire Cat for Internet Mascot)
____________________________________________________________
T O P I C A -- Learn More. Surf Less.
Newsletters, Tips and Discussions on Topics You Choose.
http://www.topica.com/partner/tag01
3. Re: Essential feature: assertions
- Posted by Aidan Bindoff <abindoff at ONE.NET.AU>
Jan 29, 2001
-
Last edited Jan 30, 2001
Excuse me for being slow off the mark, but is the only difference between
"assertions" and "type" the method of returning the error?
Regards,
Aidan
____________________________________________________________
T O P I C A -- Learn More. Surf Less.
Newsletters, Tips and Discussions on Topics You Choose.
http://www.topica.com/partner/tag01
4. Re: Essential feature: assertions
- Posted by George Henry <ghenryca at LYCOS.COM>
Jan 29, 2001
-
Last edited Jan 30, 2001
Derek,
I agree 100%. This is the way to do it. Eiffel (since I used it as an example)
lets you turn off all that extensive checking, once the code is debugged to your
satisfaction. For performance.
George
--
On Mon, 29 Jan 2001 22:40:51
Derek Parnell wrote:
>----- Original Message -----
>From: "George Henry" <ghenryca at LYCOS.COM>
>To: "Euphoria" <EUforum at topica.com>
>Sent: Tuesday, January 30, 2001 5:07 PM
>Subject: Essential feature: assertions
>
>
>[snip]
>
>> Euphoria can and should implement assertions in a more elegant way than C.
>All that's needed is an "assert" *keyword*, and the syntax "assert
><expression>". So one would write:
>>
>> assert id_vitalProc >= 0
>>
>
>I like this idea too. Plus something like ...
>
> with assert -- Evaluate any assert statements
> without assert -- Ignore any assert statements
>
>these would enable assert processing to occur during testing/debugging and
>also to be skipped ("without assert") when running code where performance is
>critical or if installed in production. Though I personnally would want
>assertions to execute even in production environments.
>
>------
>Derek Parnell
>Melbourne, Australia
>(Vote [1] The Cheshire Cat for Internet Mascot)
>
>
>
>____________________________________________________________
>T O P I C A -- Learn More. Surf Less.
>Newsletters, Tips and Discussions on Topics You Choose.
>http://www.topica.com/partner/tag01
>
>
Get your small business started at Lycos Small Business at
http://www.lycos.com/business/mail.html
____________________________________________________________
T O P I C A -- Learn More. Surf Less.
Newsletters, Tips and Discussions on Topics You Choose.
http://www.topica.com/partner/tag01
5. Re: Essential feature: assertions
- Posted by George Henry <ghenryca at LYCOS.COM>
Jan 29, 2001
-
Last edited Jan 30, 2001
Assertions are more general. You can assert any condition.
George
--
On Mon, 29 Jan 2001 22:52:17
Aidan Bindoff wrote:
>Excuse me for being slow off the mark, but is the only difference between
>"assertions" and "type" the method of returning the error?
>
>
>Regards,
>Aidan
>
>____________________________________________________________
>T O P I C A -- Learn More. Surf Less.
>Newsletters, Tips and Discussions on Topics You Choose.
>http://www.topica.com/partner/tag01
>
>
Get your small business started at Lycos Small Business at
http://www.lycos.com/business/mail.html
____________________________________________________________
T O P I C A -- Learn More. Surf Less.
Newsletters, Tips and Discussions on Topics You Choose.
http://www.topica.com/partner/tag01
6. Re: Essential feature: assertions
- Posted by David Cuny <dcuny at LANSET.COM>
Jan 29, 2001
-
Last edited Jan 30, 2001
George Henry wrote:
> <assorted flamebait about b&d features>
>
> Right now I would be happy with a simple assert()
> facility, such as any ANSI C compiler (or anything
> close to one) provides.
I think this would probably be a good thing to add. The addition of Derek's
with/without assert would be a requirement.
I've used asserts in Euphoria code before:
global procedure assert( integer test, sequence msg )
if not test then
-- print message
puts( 1, msg & "\n" )
-- force traceback
? 1/0
end if
end procedure
In lieu of a "with/without assert" option, I just did a global replace of
"assert("
with
"-- assert("
There are obviously potential problems with asserts - for example, the test
may have unexepected side effects. Sometimes just changing the length of the
code or number of statments can have odd side effects. I still recall
struggling with Euphoria, trying to figure out why the interpreted version
of the code behaved differently than the bound version.
All things considered, it's probably more useful than not.
-- David Cuny
____________________________________________________________
T O P I C A -- Learn More. Surf Less.
Newsletters, Tips and Discussions on Topics You Choose.
http://www.topica.com/partner/tag01
7. Re: Essential feature: assertions
- Posted by Martin Hunt <simulat at intergate.ca>
Jan 29, 2001
-
Last edited Jan 30, 2001
Sounds pretty complicated to me - sort of like writing your code twice -
once for the code, and then once for the assertion.
It's not stuff that I want in a language that I use. It would absolutely
make my life much harder.
It is very bizarre (IMHO) that people are putting so much pressure on Robert
to make Euphoria into some kind of C++ or VB substitute. If you want the
resources of those languages, why not go and pay !0 times more and buy them
and leave Euphoria for those of us who need a simple, elegant and compact
interpreted language?
It is even more bizarre that people get so unfriendly about it. RDS provides
an excellent product at an excellent price. I've never made a purchase of
any sort where the vendor provides so much support. When was the last time
you were able to ask a question directly to the programmer when you had a
problem in VB? Yet last year we had Everett calling Robert immoral or worse,
and this year we have the lovely MTS feeling that anything goes in the
attempt to make RDS jump to _their_ tune. What I'm seeing is people who
don't have anything to offer themselves demanding that RDS do their work for
them. For free. Yuk.
One of the services that RDS has provided free of charge is this mailing
list. Yet when Robert wants to change it, to solve some obvious problems,
and to make things a bit easier on himself - all he gets is a crescendo of
whining.
Many people have left the list - the whiners are saying it's because RDS
isn't doing enough. In fact, the whiners have made the list into something
that's not much fun and not very useful - so why would anyone stay?
And in case anyone asks - this post isn't a whine - it's a grumble.
Bye
Martin
____________________________________________________________
T O P I C A -- Learn More. Surf Less.
Newsletters, Tips and Discussions on Topics You Choose.
http://www.topica.com/partner/tag01
8. Re: Essential feature: assertions
On Mon, 29 Jan 2001 23:46:24 David Cuny wrote:
>George Henry wrote:
>
>> <assorted flamebait about b&d features>
Flamebait, probably. B&D features? Whazzat?
>There are obviously potential problems with asserts - for example, the test
>may have unexepected side effects.
Yes, it's a good idea not to do tests that may have side-effects, such as
calling a function, etc. But how can a simple test, such as "myVariable = value"
have an unexpected side effect?
In general, yes adding code for whatever reason - even to ensure the correctness
of existing code or diagnose a problem - opens up the possiblity for further
errors. But hopefully in the process one takes at least two steps forward for
every backward step introduced, so that the ultimate result is more correct code.
> Sometimes just changing the length of the
>code or number of statments can have odd side effects.
I have seen that happen in C. But the "odd side effects" were always the result
of some *other* error. For example, a logic error that wasn't causing an actual
error suddenly did because some code was added. Adding correct code to correct
code does not cause odd side effects.
> I still recall
>struggling with Euphoria, trying to figure out why the interpreted version
>of the code behaved differently than the bound version.
Specifically, for instance? Just curious.
Thanks for your input and support for the basic idea, David.
George
Get your small business started at Lycos Small Business at
http://www.lycos.com/business/mail.html
____________________________________________________________
T O P I C A -- Learn More. Surf Less.
Newsletters, Tips and Discussions on Topics You Choose.
http://www.topica.com/partner/tag01
9. Re: Essential feature: assertions
On Mon, 29 Jan 2001 23:52:45 Martin Hunt wrote:
>Sounds pretty complicated to me - sort of like writing your code twice -
>once for the code, and then once for the assertion.
>
>It's not stuff that I want in a language that I use. It would absolutely
>make my life much harder.
Uh, Martin, it's not a feature you would be forced or obligated in any way to
use. Just encouraged to use, in order to make your code more correct,
bullet-proof, however you want to say it. This is one of those computer science
things that has been proven in theory AND practice.
Eiffel has proven to be the most successful OO language for large projects
(dozens of programmers, millions of lines of code) precisely because of its
extensive and well-thought-out assertion facilities. There is a unifying
principle, called "design by contract," behind all of that. It's something every
programmer who uses any language would do well to read up on (even if you never
intend to use Eiffel), because it improves your thinking and your approach to the
whole software development process.
So anyway, if you don't like assertions or have a use for them, just ignore the
facility, pretend it doesn't exist, and go on coding the way you have been doing.
It's no skin off my nose, unless I am tempted to use your software, in which case
"written with extensive use of assertions" would make me more confident that it
will work as advertised most of the time.
>It is very bizarre (IMHO) that people are putting so much pressure on Robert
>to make Euphoria into some kind of C++ or VB substitute. If you want the
>resources of those languages, why not go and pay !0 times more and buy them
>and leave Euphoria for those of us who need a simple, elegant and compact
>interpreted language?
There is nothing I want less than "some kind of C++ or VB substitute." I am
against featurism and unnecessarily complex tools. I appreciate the cleanness and
simplicity of Euphoria. That and sequence are the reasons I am using it. (Also
the *free* public domain version and low cost of registering.)
There are two ways to "improve a language." One is to learn to use it better
without any changes. I admit to being a largely ignorant newbie, but I'm working
to change that. The second way is to add a few well-chosen features. I think Rob
has done an excellent job with the language as it stands. However, there are some
useful features that just might be worth the trouble to add.
Features are divided (fuzzily) into two types: Those you should use, and those
you can use if you want to (and in certain circumstances would make life easier
for you). [There is actually a third type - features you should avoid at all
costs, to the point of shunning languages that require you to use them. 
] The
fuzziness usually depends on the context. I think assertions should be used in
developing commercial software, or even non-commercial software intended for
widespread use by others. (Things like IDEs and GUI libraries come to mind, or
any general-purpose libraries that people are likely to view as essential parts
of their toolkits.) For hacking, prototyping, or personal-use software, one
should feel free to use assertions as much or as little as they like.
>It is even more bizarre that people get so unfriendly about it. RDS provides
>an excellent product at an excellent price. I've never made a purchase of
>any sort where the vendor provides so much support. When was the last time
>you were able to ask a question directly to the programmer when you had a
>problem in VB? Yet last year we had Everett calling Robert immoral or worse,
>and this year we have the lovely MTS feeling that anything goes in the
>attempt to make RDS jump to _their_ tune. What I'm seeing is people who
>don't have anything to offer themselves demanding that RDS do their work for
>them. For free. Yuk.
How about I implement my own language - that borrows heavily from Euphoria,
since as I said it incorporates some very useful ideas, nicely implemented at
that. Then I will get a chance to "walk in Rob's shoes," so to speak. (Just an
idea. Don't hold your breath waiting for me to do it.)
I don't want RDS to do my work for me. I have used lots of languages in the past
where, as you say, I had absolutely no input regarding what features might be
available. Here, we are all in effect part of the "ANSI standard committee,"
though Rob has final say, but at least he listens and responds to requests that
have some merit, even if many of us disagree with his decisions. Having the
opportunity to make suggestions of potentially useful features (useful to
EVERYONE, not just myself), I for one intend to make full use of that
opportunity.
I could grumble back at all the people who keep silent about possibly improving
Euphoria. Surely you have some potentially useful ideas? Is so, you are doing
yourselves, RDS, and the entire Euphoria users' community a disservice by keeping
them to yourselves.
I think Rob will agree that there are opportunites to improve the language. In
general, he seems to appreciate suggestions. Whether to make enhancements for
free or to charge for them is his choice.
>One of the services that RDS has provided free of charge is this mailing
>list. Yet when Robert wants to change it, to solve some obvious problems,
>and to make things a bit easier on himself - all he gets is a crescendo of
>whining.
I have gotten rather tired of that, myself.
>Many people have left the list - the whiners are saying it's because RDS
>isn't doing enough. In fact, the whiners have made the list into something
>that's not much fun and not very useful - so why would anyone stay?
>
>And in case anyone asks - this post isn't a whine - it's a grumble.
(Intelligent) grumbling is a lot more palatable than whining.
George
Get your small business started at Lycos Small Business at
http://www.lycos.com/business/mail.html
____________________________________________________________
T O P I C A -- Learn More. Surf Less.
Newsletters, Tips and Discussions on Topics You Choose.
http://www.topica.com/partner/tag01
10. Re: Essential feature: assertions
- Posted by JJProg at CYBERBURY.NET
Jan 30, 2001
Could you not do:
type assert(atom x)
return x
end type
assert myAssert
integer rtn
rtn = routine_id("")
myAssert = (rtn >= 0) -- it fails here, and Euphoria will tell you the
line number etc. if you have the full version or if it's under 300 lines
Jeff Fielding
----- Original Message -----
From: "George Henry" <ghenryca at LYCOS.COM>
To: <EUforum at topica.com>
Sent: Tuesday, January 30, 2001 2:23 AM
Subject: Re: Essential feature: assertions
> Assertions are more general. You can assert any condition.
>
> George
> --
>
> On Mon, 29 Jan 2001 22:52:17
> Aidan Bindoff wrote:
> >Excuse me for being slow off the mark, but is the only difference between
> >"assertions" and "type" the method of returning the error?
> >
> >
> >Regards,
> >Aidan
> >
> >____________________________________________________________
> >T O P I C A -- Learn More. Surf Less.
> >Newsletters, Tips and Discussions on Topics You Choose.
> >http://www.topica.com/partner/tag01
> >
> >
>
>
> Get your small business started at Lycos Small Business at
http://www.lycos.com/business/mail.html
>
> ____________________________________________________________
> T O P I C A -- Learn More. Surf Less.
> Newsletters, Tips and Discussions on Topics You Choose.
> http://www.topica.com/partner/tag01
>
>
____________________________________________________________
T O P I C A -- Learn More. Surf Less.
Newsletters, Tips and Discussions on Topics You Choose.
http://www.topica.com/partner/tag01
11. Re: Essential feature: assertions
Hmm.
Jeff, you clever fellow. Now, Rob PLEASE document this for future generations of
Eu coders. (ANOTHER reason to buy the full version!)
I still like the idea of a more direct and readable syntax ("syntactic sugar"
for exactly what you have shown here, perhaps). But this would certainly take
care of the basic functionality.
George
--
On Tue, 30 Jan 2001 13:41:36
JJProg wrote:
>Could you not do:
>
>type assert(atom x)
> return x
>end type
>
>assert myAssert
>integer rtn
>rtn = routine_id("")
>myAssert = (rtn >= 0) -- it fails here, and Euphoria will tell you the
>line number etc. if you have the full version or if it's under 300 lines
>
>Jeff Fielding
>
>----- Original Message -----
>From: "George Henry" <ghenryca at LYCOS.COM>
>To: <EUforum at topica.com>
>Sent: Tuesday, January 30, 2001 2:23 AM
>Subject: Re: Essential feature: assertions
>
>
>> Assertions are more general. You can assert any condition.
>>
>> George
>> --
>>
>> On Mon, 29 Jan 2001 22:52:17
>> Aidan Bindoff wrote:
>> >Excuse me for being slow off the mark, but is the only difference between
>> >"assertions" and "type" the method of returning the error?
>> >
>> >
>> >Regards,
>> >Aidan
>> >
>> >____________________________________________________________
>> >T O P I C A -- Learn More. Surf Less.
>> >Newsletters, Tips and Discussions on Topics You Choose.
>> >http://www.topica.com/partner/tag01
>> >
>> >
>>
>>
>> Get your small business started at Lycos Small Business at
>http://www.lycos.com/business/mail.html
>>
>> ____________________________________________________________
>> T O P I C A -- Learn More. Surf Less.
>> Newsletters, Tips and Discussions on Topics You Choose.
>> http://www.topica.com/partner/tag01
>>
>>
>
>
>____________________________________________________________
>T O P I C A -- Learn More. Surf Less.
>Newsletters, Tips and Discussions on Topics You Choose.
>http://www.topica.com/partner/tag01
>
>
Get your small business started at Lycos Small Business at
http://www.lycos.com/business/mail.html
____________________________________________________________
T O P I C A -- Learn More. Surf Less.
Newsletters, Tips and Discussions on Topics You Choose.
http://www.topica.com/partner/tag01
12. Re: Essential feature: assertions
- Posted by David Cuny <dcuny at LANSET.COM>
Jan 30, 2001
-
Last edited Jan 31, 2001
George Henry wrote:
> Flamebait, probably. B&D features? Whazzat?
>From the Jargon File:
bondage-and-discipline language n
A language (such as Pascal, Ada, APL, or Prolog) that, though ostensibly
general-purpose, is designed so as to enforce an author's theory of `right
programming' even though said theory is demonstrably inadequate for systems
hacking or even vanilla general-purpose programming. Often abbreviated
`B&D'; thus, one may speak of things "having the B&D nature". See Pascal;
oppose languages of choice.
-- David Cuny
____________________________________________________________
T O P I C A -- Learn More. Surf Less.
Newsletters, Tips and Discussions on Topics You Choose.
http://www.topica.com/partner/tag01
