OpenEuphoria

Re: Request for 2.5

• Posted by Pete Lomax <petelomax at blueyonder.co.uk> Aug 20, 2003
• 504 views

On Tue, 19 Aug 2003 15:24:28 -0400, Robert Craig
<rds at RapidEuphoria.com> wrote:

>Pete Lomax wrote:
>> When you shroud a file, in particular a library, nested global
>> functions and procedures are no longer global, only the top level
>> global routines remain global. This is good.
>>=20
>> However, the same does not happen for global variables and constants.
>>
>> I appreciate why, and that changing this behaviour would cause all
>> manner of upsets on existing sources. I suggest a new keyword is
>> introduced, eg package, which behaves exactly as global on unshrouded
>> source, but the shrouder removes it.
>
>It seems to me the top level variables and constants
>should also remain global. If this is not happening for you,
>then it could be a bug in the binder/shrouder.
Sorry, I wasn't clear enough. I also said variables <and constants>,
when actually it is just variables. It keeps all the global variables
still global, both toplevel (correct) _and nested_ (wrong).
>Not many people have created shrouded library code. Almost everyone =
creates
>complete bound or shrouded programs, so you may be treading
>on some rarely-used parts of the binder/shrouder.
Spot on. I can work round this by shroud -clear, edit the file
removing a few "global"s and re-shroud. No biggie.
>If you have a small example you can send me, I'll look at it.
There's a couple below.
>Otherwise I'll investigate this general issue some time before
>the next release.
Yes, this is a request for 2.5

Here's a more detailed explanation:

One small glitch occurs when you shroud a program which includes
misc.e without using any routines from it. It retains

integer pretty_end_col,pretty_chars,pretty_start_col,pretty_level,
pretty_file,pretty_ascii,pretty_indent,pretty_ascii_min,
pretty_ascii_max
sequence pretty_fp_format,pretty_int_format,pretty_line

when ideally, it should not. (So what, ... but a bug is a bug)

Now, (this is an example showing correct behaviour), if you include
ddl.e and have say:
atom iwinspool,iEnumPrinters
iwinspool=3Dopen_dll("winspool.drv")
iEnumPrinters=3Ddefine_c_func(iwinspool,"EnumPrintersA",
{C_INT,C_INT,C_INT,C_INT,C_INT,C_INT,C_INT},C_INT)

it shroud -clear's to:

constant C_INT=3D#01000004
constant M_DEFINE_C=3D51
function open_dll(sequence file_name)
function define_c_proc(object L,object routine_name,
<etc>

Notice the global keyword has (correctly) been removed.

If however you include database.e, you get:

global integer my_dir=20
global integer db_fatal_id

There is no need for that, and of course it is going to cause
namespace qualifier errors for anyone using the library.

Now that I've realised this is only variables, not constants, I no
longer think that changing this will break anything.

Regards,
Pete
PS the database.e is just an example, I've actually done some wrapping
to make sure it won't load two copies in memory, btw.