When debugging, it would be valuable if I could say something like:

1. function fn(x) = assert(dim(x) == 1) 2.  let(result = 3.
   [for(i=[1:len(x)]) 4.      if(i!=len(x)-1) 5.        assert(x[i] > x[i-1],
   str("@i==",i,".  Was ", x[i], " > ", x[i-1], ".")) 6.        x[i]-x[i-1] 7.
   ]) 8.    assert(result[0] == 0) assert(len(x) == len(result)+1) result;
   Please note that this is quite contrived example, but it demonstrates a
   function's precondition, postcondition and an interior straight up
   assertion.  Also, I've placed line numbers prior to each line of code and
   we'll pretend that all lines shown here are in a file called x.scad.
   This function shows that it takes only a one dimensional array, where each
   element must be less than the one before it and the result must have a first
   element be equal to 0 and have one less element then the array passed in.
   The result itself is an array where the next element is subtracted from the
   current.
   If the assert's first parameter is equivalent to false, then it should the
   file and line where the assertion occurred, as well as the caller's line all
   the way up the stack.  Variables are substituted for the parameters with
   their values to help in the debugging process.  This would be great to be
   able to trace back where the problem came from.  It would also write out the
   1st parameter as a string as well as the result that it gave back. This is
   because false can be represented in many different ways and may be useful
   when debugging.  Something like:
2. x=1;21. y=fn(x);
   Would output:
   ASSERTION FAILURE  -> from file x.scad:21 while calling: fn(1)  -> in file
   x.scad:1  (dim(x) == 1) == false
   If an assert has a 2nd parameter, it should evaluate and output that as well
   as the programmer can drop a more explicit hint as to what the user of their
   function did wrong. So something like this:
3. fn([4,undef,3]);
   Would output:
   ASSERTION FAILURE  -> from x.scad:2 while calling: fn([4,undef,3])  -> in
   file x.scad:5  (x[i] < x[i+1]) == undef  @i==0.  Was 4 < undef.
   An assert can be placed anywhere prior to an expression and if false, then
   should stop the execution in its tracks.  An assert is not an expression, it
   doesn't return any value and must be bound to an expression.  That said,
   multiple asserts can be placed next to each other, so they all would be
   bound to the expression to the right of the rightmost assert.
   Alternatives would be to have specific pre and postcondition constraints as
   well as assertions, but I don't think that it would be that great of a gain.
   Also, instead of just using the 2nd parameter, we could just use the 2nd on
   and treat them as if they were parameters to the str(...) function which
   would remove the need for the call to str(...) which might reduce the
   typing, but may increase the noise as assert value and assert message can
   run together.  If done this way, one could still do it the other way and
   could be left up to the preference of the programmer of the .scad file.
   I think the usefulness to the programmer and user of any .scad library would
   benefit. What do you ppl think?
    
   A

--
View this message in context: http://forum.openscad.org/Would-be-nice-to-have-constraints-assertions-on-functions-modules-tp11237.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

BTW, when I said bound to an expression, I'm not really sure if that is how
you do it for let(...) but it would be the same idea as that.
 
A

--
View this message in context: http://forum.openscad.org/Would-be-nice-to-have-constraints-assertions-on-functions-modules-tp11237p11238.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

Sort of a shameless plug --- this patch is still floating around, but has not
made it into mainline.

http://forum.openscad.org/PATCH-Add-function-pre-and-post-conditions-td9493.html

Taahir