OpenEuphoria

Re: Changes in the ESL papers

• Posted by Gordon Webster <gwalias-bb at yahoo.com> Jul 22, 2005
• 684 views

Way to go Juergen!

For math.e, I would suggest that the rounding down function (i.e. the
rounding down equivalent of 'ceil') be called 'floor'.

How about 'sum_sequence' and 'product_sequence' for the 2 math sequence
functions?

Are we going to make each module/function self-documenting - maybe I
missed it but I never saw an answer to this question (with the caveat
that we work with the official RDS Eu syntax, since it would be (IMHO)
a mistake to support other syntax-variant Eu flavors)

Consistent error handling is tricky, since 0 or -1 might be valid
return values for some functions. Rather than standardizing error handling
pe se (since different error contexts may call for different handling),
we could define a standard library error type as a sequence with an
distinctive flag as its first element. The subsequent elements of the
sequence could then be anything the coder required for the particular
error handling they had in mind - error messages, routine ids where the
crash occurred, routine ids to go to after a crash, diagnostics etc. etc.

The advantage of this would be to provide both a standardized way of
telling an error had occurred by testing the returned object (is it a 
sequence and is its first element the error flag?) and providing a 
flexible storage element for the coder to use for whatever eror handling 
he/she has in mind. It could work like this ...

constant STANDARD_LIBRARY_ERROR = ".standard.library.error." -- or whatever

global function is_error(object s)
-- start-eudocs
-- function to test returned values for error status
-- end-eudocs
    if not sequence(s) then
        return false
    else
        if not length(s) > 0 then
            return false
        end if
    end if
    if equal(s[1],STANDARD_LIBRARY_ERROR) then
        return true
    else
        return false
    end if
end function

Now my functions can return something like this in the case of an error...

function demo_function(integer num)
  ...
  <some code here>
  ...
  if not integer(result) then
    return {STANDARD_LIBRARY_ERROR,"Result not an integer","demo_function"}
  end if
  ...
end function

So the way of flagging errors and storing the error handling parameters is
standardized, but the error handling is still flexible enough for any
occasion and doesn't impose an error handling ideology on all users under
all circumstances.

Comments?

Best

Gordon