OpenEuphoria

Re: What's new in 2.5?

• Posted by Derek Parnell <ddparnell at bigpond.com> Sep 08, 2004
• 464 views

Christian Cuvier wrote:
> 
> >>- 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.


Oh okay, I get you now. You would like to define an identifier in a file
such that when that file is included, only the including file and the
included file could see the identifier.

I can see how this would be useful for breaking up an otherwise
monolithic library (eg. win32lib).  It would mean that if
someone included "win32lib.ew" they wouldn't see those special 
identifiers that were defined inside the files that win32lib itself
includes. Very nice.

> 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.

Yes there are... 

- In the file to be included declare the identifier with 'export' rather
than 'global'. eg.

  export sequence w32KnownControls

> 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. 
> > 

[snip]

> 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.

"major"? Are you sure of that?

> As an answer to the "this will hide bugs" issue, 

I said "source of bugs" not "this will hide bugs". But anyway, go on ..

>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 :).

This seems to assume that the coder is not so concerned with what exactly
is wrong, just that something is wrong. Something like ...

   ifx s[i+3] then
      Abort("Something is wrong with the line above")
   else
       a = s[i+3]
   end if
 
> 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.

It does? Is this below a bug or not?

   
   sequence y y = "derek"
   ifx not(y = "frank") then
       ProcA(y)
   end if 
   
In your scheme, ProcA would always be called regardless of what value 'y'
holds.


-- 
Derek Parnell
Melbourne, Australia