Re: What's new in 2.5?
>>- local include (make an identifier visible to the including file only)
>
>
> This is already in the language. Any non-global identifier declared
> in an include file, and not inside a routine, is visible to the
> routines in that include file and nowhere else.
>
>
Ok, let me restate it. What is missing is a way for the including file, and no
one else but the included file,
to see globals in the included file, so as not to pollute the "universal"
namespace, generating name clashes.
There are several approaches to solve this:
-define a "nonlocal" (or whatever) keyword to qualify variables that are to be
seen from the current file and any directly including file only;
-define "scopes" as namespaces with no communication with the 'default)
namespace. Currently "include ... as" creates two identifiers (myid and
name:myid).
-define an "import ... as" statement so as the imported file's globals are
visible from the importing file onl.
-and probably more.
At least, all these can't break any existing code. I'd be satisfied with any
of the above.
>
>
>>> - Something I had not mentioned before: assume i+3 falls of the valid
>>> indexes
>>> of sequence s. The current behaviour is that
>>>
>>> if s[i+3]<3 then...
>>>
>>> crashes as the bound check fails. But no logical condition holds true when
>>> some of its args doesn't exist. As a result, it would be much simpler to
>>> code
>>> if any such test quietly returned false.
>>>
>>> Thus, we'd have, whenever x doesn't exist: x<y = x=y = x>y = 0. Not a
>>> problem,
>>> as x doesn't exist...
>
>
> A guaranteed source of bugs, for sure.
>
> One could however use a function to check index validity before using.
> Like ...
>
> if valid(s,i+3) and s[i+3]<3 then..
>
> if valid(s,{b,c}) then
> a = s[b..c]
> end if
>
> where 'valid' is defined as ...
>
> function valid(sequence s, object x)
> if integer(x) then
> return x >= 1 and x <= length(s)
> end if
> if length(x) = 0 then
> return 1
> end if
> if x[1] >= 1 and x[1] <= length(s) and valid(s, x[2..$]) then
> return 1
> else
> return 0
> end if
> end function
>
> -- Derek Parnell Melbourne, Australia
Oh sure, and that's what one has to do. That's a major source of errors
designing the function or just forgetting the preliminary test, plus the
coding overhead.
As an answer to the "this will hide bugs" issue, there might be the addition
of a new keyword, say "ifx". "(els)ifx" is to behave just like "if", except
that it returns false when some conditional expression fails to evaluate.
This way, the of statement is not modified,, andthe benefits of useless data
validation may be bypassed. I say "useless" since the coder has to supply a
check that the interpreter will carry out anyway. Unless it cleverly optimizes
away, of course :).
Further, any undefined index real bug will show up anyway, most likelly in the
same conditional block, when attempting to read or write from a nonexistant
element, which must remain an error condition in a nonconditional statement.
This challenges the very idea that the proposed change will hide bugs.
CChris
|
Not Categorized, Please Help
|
|
