error messages

0 views
Skip to first unread message

Serge D. Mechveliani

unread,
Feb 25, 2012, 9:09:20 AM2/25/12
to fricas...@googlegroups.com
Waldek wrote recently about the error messages in an user prorgam

> When I wanted to provide more information in error message I used
> construct like:
>
> bad?(val) => print(val::OutputForm)$OutputForm
> error "foo_routine: got bad val"

When a function is applied to several arguments of different types
forming such a message is still messy.
How to keep a prorgam highly readable with also having messages
informative and readable?
For example:

OF ==> OutputForm
NLOF ==> newline() :: OutputForm

f(xs : List String , n : Integer, b : Boolean) : List String ==

msg() : Void ==
oF := hconcat[ "f(xs, " ::OF, n ::OF, b ::OF, "), where"
NLOF, "xs =", NLOF, xs ::OF, " :" ::OF ]
print(oF)$OF

n < 0 => (msg(); error "negative n.")
n > 10 => (msg(); error "n > 10")
...

Is this natural?

Further, I tried to reduce the `::OF' repetition by
oF := toOFs ["f(xs, ", n, b, "), where" ...]
with providing
package ... Set1(T : SetCategory)
...
toOFs(xs : List T) : OF ==
hconcat (map(x +-> x :: OF, xs) $ListFunctions2(T, OF))

But the usage of toOFs involves more complication, because it needs to
package call with some complex union type.
Right?

There is another point:
In Haskell, I put to the curent scope all the useful provisions, like

msg() == ...
str : String := g(..)
...

and put them in any place where they look nicer. For example, this may be
the stuff used in the error messages.
At the run time, if the value of msg (or str) is not used in the result,
then they do not compute. Because the language is lazy.
In Spad, this may occur a performance trap, I thought of this now and
got frightened.

Regards,

------
Sergei
mec...@botik.ru

Reply all
Reply to author
Forward
0 new messages