1. indexes
i noticed a problem today. euphoria treats indexes above 31 bits as
signed. this is a problem since i'm working on a new VM that emulates
32-bit addressing, and some addresses may exceed 0x7fffffff(i found this
out because in my VM the ROM is loaded into 0xffefffff, so it can't read
even the first instruction there). i hope you'll do something about this
in 2.3. i hope you only didn't fix this because you never gave a thought
to it, and not because it's impossible...
2. Re: indexes
sephiroth _ writes:
> i noticed a problem today. euphoria treats
> indexes above 31 bits as signed.
Thanks. The error handling code uses a C "convert to long",
rather than a "convert to unsigned long".
I can't believe you are going to have a sequence
with more than 2 billion elements. It would require
8Gb of memory/swap space!
By the way, nothing has been decided yet about
namespaces, so feel free to post suggestions
for another couple of days.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
3. Re: indexes
Rob wrote:
> By the way, nothing has been decided yet about
> namespaces, so feel free to post suggestions
> for another couple of days.
Ok, just one more, simple, sort of 'monolithic' scheme:
Keep 'globals' in their current form, for backward compatibility.
Extend, optionally, the include statement as previously suggested:
include <filename> as <name>
Allow *any* local declarations in so included files to be accessible
using the standard 'dot' notation.
Any 'include as' statements in an included file are, of course,
'inherited' by the calling file, regardless of the level of nesting.
It would also be highly desirable, if not necessary, to
1. allow re-definition of not just the built-in routines, but
also of all previous declarations, possibly even constants (I
know, Rob, you will never agree...) with mere warning.
2. flag as an error use of the same include file with a different
'as name'.
3. flag as an error duplicate use of the same 'as name' for
different include files.
Just a short example:
-- filea.e -----------------------------------------------------------
global constant
TRUE = 1,
FALSE = 0
function funa(...)
...
end function
...
-- fileb.e -----------------------------------------------------------
include filea.e as a
constant pi = 3.1416
integer r
function funb(...)
...
end function
...
-- file.ex -----------------------------------------------------------
include fileb.e as b
integer flag, x, y, z
flag = TRUE -- global from filea.e through include in fileb.e
x = a.funa(...) -- again through include in fileb.e
y = b.funb(...) -- direct inclusion
b.r = 5
z = 2 * b.pi * b.r -- pretty rough, eh? ;)
-- or the last three lines using the 'using' clause:
using b
y = funb(...)
r = 5
z = 2 * pi * r
end using
jiri
4. Re: indexes
Hi, Derek,
>> Allow *any* local declarations in so included files to be
>> accessible using the standard 'dot' notation.
> Are you saying that not only global symbols, but local ones as well,
> can be accessed from outside the include file? Why is that?
First of all, Derek, this is *not* my preferred solution (see my
previous suggestion, a combination of 'global' and 'export' keywords,
'global' with the current syntax for both legacy code and important or
'system-wide' declarations, and new 'export' to be used with the dot
notation), just an alternative. I thought, you as the developer and
maintainer of a relatively large library, win32lib, would be quite
interested in the 'monolithic' concept. It would allow you to break up
the monster into more conveniently sized chunks *without* labelling
just about everything global.
> I thought the idea of having local symbols was so that the author
> can explictly hide implementation details from users of a library.
> The implmentation details being in local routines, constants and
> variables. This is pretty well agreed in computer science circles to
> be a "good thing".
To be quite honest, I do not give a damn about what 'is pretty well
agreed in computer science circles to be a "good thing"'. I have been
a scientist for more than 35 years now, and in my humble opinion,
scientists rank only very close second behind managers in promotions
of all sorts of dubious, impractical solutions to the real world
problems. But I am diverging...
There is nothing inherently good, or bad, for that matter, with
information hiding, that became suddenly so popular and important with
emergence of OO designs. In case of OO, at least, it can be almost
justified for reasons of safety.
> The idea being that the author of a library should be free to change
> the internals of a library provided that the published interface
> remains the same. If the author cannot be sure that changing an
> internal object will not break somebody else's code, it makes things
> a bit hard for everybody.
I think, the key words in the preceding paragraph are 'the published
interface'. In other words, proper documentation is really the
decisive factor. Beyond that, if as a user you rely on 'undocumented
features, you better know what you are doing ;).
>> Any 'include as' statements in an included file are, of course,
>> 'inherited' by the calling file, regardless of the level of
>> nesting.
> Why is this a good thing? I'm not sure of the "of course" aspect. I
> might be missing the impact of this.
Simplicity and consistency. Currently, I understand, only the first
inclusion of the same file is effected, all subsequent ones are simply
ignored. But you are probably right...
>> 2. flag as an error use of the same include file with a
>> different 'as name'.
>
> Why is this a good idea? I can imagine situations that would be the
> equivalent of ...
>
> include graphics.e as rds
> include graphics.e as doslib
Again, you are probably right, especially since we cannot be
absolutely sure what is included and how in shrouded files. And, as
long as differently qualified labels are just aliases referring the
same entities, it should be ok anyway.
>> 3. flag as an error duplicate use of the same 'as name' for
>> different include files.
>
> Why is this a good idea? I can imagine situations that would be the
> equivalent of ...
>
> include graphics.e as rds
> include get.e as rds
> include file.e as rds
It would not be such a good idea, if not *all* symbols of included
files were accessible from outside. But if they are, as in my second
proposal, which by the way I like much less today than I did
yesterday, then the potential for all sorts of name collisions is just
too great.
jiri
5. Re: indexes
On Wednesday 27 June 2001 03:15, Derek Parnell wrote:
> > Jiri:
> > 1. allow re-definition of not just the built-in routines, but
> > also of all previous declarations, possibly even constants (I
> > know, Rob, you will never agree...) with mere warning.
>
> Now this sounds like a great idea. Why should RDS be the only dispenser of
> wisdom. For example, I can imagine somebody inventing a better abort()
> routine and I just might like to use that - without - modifing any of my
> existing code or included library files.
Strangely enough, Euphoria handles just such a thing with no problem:
Warning: Built-in abort() redefined
Press Enter...
Change that from a built-in command to one in an include, however:
test.exu:3
attempt to redefine wait_key
function wait_key()
^
Regards,
Irv
