Assert{ 2.0 } - a new kind of assertion

ruby-talk
1

Phlip <phlip2005@gmail.com> writes:

I have invented a new concept of developer test assertions. This
post is a preview of its features, before I release it for
Ruby. Porting it to other languages is left as an exercise for the
reader.

  assert{ 2.0 }

I don't like the simple assertions - assert_equal, assert_match,
assert_not_nil, etc, in my developer tests. They only exist for one
reason - to print out their values when they fail. And then they
don't even reflect their variable names, either.

So I wrote an assertion to replace them. Put whatever you want into
it; it prints out your expression, and all its values.

     You mean like you can easily do in Common Lisp:

http://www.gigamonkeys.com/book/practical-building-a-unit-test-framework.html

It's nice to see people making the effort to bring these primitive
languages into the brave new world of the late 1950s and early 1960s.
:wink:

Ha, ha, only serious,

Patrick

···

------------------------------------------------------------------------
S P Engineering, Inc. | Large scale, mission-critical, distributed OO
                       > systems design and implementation.
          pjm@spe.com | (C++, Java, Common Lisp, Jini, middleware, SOA)

2

I always wondered why dynamically typed languages do not make brackets
dynamic... To enjoy that at full one could invent assertions asserting that
the numbers of left and right brackets are same... Or what about asserting
statements:

if assert I said, "if"! then assert I really mean "then"! or else! ...

you get the idea... (:-))

···

On Wed, 30 Jan 2008 06:50:57 -0800, Phlip wrote:

I'll stick with the language where every parenthesis pair is optional, thanks.

--
Regards,
Dmitry A. Kazakov

3

Phlip <phlip2005@gmail.com> writes:

     You mean like you can easily do in Common Lisp:

Already pointed out on another forum.

Ha, ha, only serious,

I'll stick with the language where every parenthesis pair is
optional, thanks.

     Parentheses? What parentheses? :wink:

     In practice parentheses are the anti-fnords -- fairly quickly you
start to _not_ see them. They do make macros (real macros, not those
C-family search-and-replace abominations) straightforward, though.
Definitely worth the effort.

     Nice Ruby hack, by the way.

Regards,

Patrick

···

------------------------------------------------------------------------
S P Engineering, Inc. | Large scale, mission-critical, distributed OO
                       > systems design and implementation.
          pjm@spe.com | (C++, Java, Common Lisp, Jini, middleware, SOA)

4

In article <m2ir1ba39l.fsf@spe.com>, pjm@spe.com says...

[ improved asserts for Ruby ]

     You mean like you can easily do in Common Lisp:

Practical: Building a Unit Test Framework

It's nice to see people making the effort to bring these primitive
languages into the brave new world of the late 1950s and early 1960s.
:wink:

Your code depends heavily on macros, which didn't exist in Lisp until
1963. Even so, the early macro facilities were fairly ugly, and I'm
pretty sure would not have handled code even vaguely similar to yours.

The first macro facilities that resemble what you use were introduced in
the dialects of Lisp invented for the MIT Lisp Machine project in
roughly the mid-1970's.

That, however, was only when the language provided the facilities to
implement your code -- I don't know of anybody having written such a
thing until considerably later. Strangely, C had actually implemented a
relatively complete assert facility around the time it became possible
to do so in Lisp.

···

--
    Later,
    Jerry.

The universe is a figment of its own imagination.

5

In article <ld2pf13xazee.5fvq1opyhe5z.dlg@40tude.net>, mailbox@dmitry-
kazakov.de says...

[ ... ]

if assert I said, "if"! then assert I really mean "then"! or else! ...

Fortran did it first:

if if .eq. 1 then then = 2 else else = 3

is perfectly legitimate, since key words aren't reserved. Nicely enough,
there's no reason you can't embed a space character into a variable name
either, so something like:

do 10 i = 1.10

is perfectly legal too. Change it to:

do 10 i = 1,10

and it's a loop -- but with the decimal point instead of a comma, it's a
simple assignment of the value 1.10 to a variable (that didn't have to
be declared either) named 'do 10 i'!

Not to be outdone, the designers of PL/I decided that:

x = y = 0;

should be legitimate and allowable -- but after executing it, x
absolutely would NOT equal y!

···

--
    Later,
    Jerry.

The universe is a figment of its own imagination.

6

In article <47a154ae$0$4950$4c368faf@roadrunner.com>, phlip2005
@gmail.com says...

Jerry Coffin wrote:

> Strangely, C had actually implemented a relatively complete assert
> facility around the time it became possible to do so in Lisp.

Even the oldest C could do stringerization, with a trick:

#define assert(foo) if(!(foo)) fprintf(STDERR, "\
foo
\ failed");

I don't think the _very_ oldest C could handle this. If you ever feel
like looking, Dennis Ritchie has a museum on his web site that includes
some early C compilers. These include some versions so old some of the
_very_ basic parts of the language were still in flux (e.g. on that
doesn't support 'struct' at all). OTOH, but the mid-70's, things had
settled down quite a bit -- in particular, memory was no longer quite so
constrained, so he could implement a more complete language without
simply overflowing the memory available on the (only) Unix machine at
the time.

Someone check my syntax, but that would reflect 'whatever' if you failed
assert(whatever). However, this could not _reliably_ reflect argument
values. Even C++, with <iostream>, cannot reliably reflect both arguments
and values, for an assertion that's healthy to type.

True -- I didn't mean to imply that its original assert was identical or
equivalent to what you've written; quite the contrary, C (and C++) have
make any sort of reflection quite difficult at best. OTOH, what they
provided 30 years ago (or so) still seems to be better than what Ruby
does by default...

So C++ made up for this by letting me put a breakpoint into the
assertion, so it would break directly into the calling code. I could TDD
in the debugger quite effectively like that.

What my assertion gives for a Ruby project, without a debugger, is all
the "watch points" that a debugger would have provided:

assert_{ reflect_string(statement) == statement } --> false -
should pass
    statement --> "lambda{|*a| p( a ) }"
    reflect_string(statement) --> "lambda{|*a| p(a) }".

Yes, Lisp probably did, too, that before I was born!

Without knowing how old you are, that's harder to guess. Then again,
even if I did know your exact age, it could be hard to answer. Most
languages draw a clear line between the compiler/interpreter/whatever
and your code. Lisp doesn't; it allows you to play directly with the
implementation quite easily, and it's generally considered quite
reasonable for ordinary code to use things that would be completely
hidden and inaccessible in most other languages. As such, it's usually
difficult to say anything like "nobody did X before day Y", with respect
to Lisp.

···

--
    Later,
    Jerry.

The universe is a figment of its own imagination.