Re: Changes in the ESL papers
- Posted by Gordon Webster <gwalias-bb at yahoo.com> Jul 22, 2005
- 564 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