OpenEuphoria

2. Re: private include files

• Posted by "Kat" <gertie at visionsix.com> Oct 12, 2004
• 440 views

On 11 Oct 2004, at 21:39, Derek Parnell wrote:

> 
> 
> posted by: Derek Parnell <ddparnell at bigpond.com>
> 
> Has anybody got any thoughts about extending the 'include' system so
> that anything included can only been 'seen' by the file that included it.
> 
> For example, if we have ...
> 
>    private include abc.e
> 
> then only the file that has that line can see the 'globals' that are
> defined inside "abc.e". So if another file wants to see them they also
> have to explictly include "abc.e".  Further more, if "abc.e" has
> already been included without the private qualifier, that will no cause
> any conflicts.
> 
> This is just a quick spur-of-the-moment thought, so it probably has
> got issues with it.
> 
> It would certainly help me with many of the projects I'm working on.

It's in Bach. I believe RobC said "no way". I voted for it, but you know me, i'd
vote for anything to make writing up a program easier!

Kat

4. Re: private include files

• Posted by Greg Haberek <ghaberek at gmail.com> Oct 12, 2004
• 419 views

Or maybe a slightly different approach: inline files. Upon reaching
keyword 'inline' the Interpreter continues to parse that file as if it
were in the local file, yet keeping track of separate line numbers,
etc..

inline myfile.e    -- file is inserted inline at this position

~Greg


On Tue, 12 Oct 2004 14:48:43 +1000, Patrick Barnes <mrtrick at gmail.com> wrote:
> 
> On Mon, 11 Oct 2004 21:39:56 -0700, Derek Parnell
> <guest at rapideuphoria.com> wrote:
> > posted by: Derek Parnell <ddparnell at bigpond.com>
> > Has anybody got any thoughts about extending the 'include' system so
> > that anything included can only been 'seen' by the file that included it.
> 
> It's been brought up before... but nothing has happened of it.
> Are there any technical problems with implementing it, Rob? That is to
> say, the visibility...
> 
> >    private include abc.e
> >
> > then only the file that has that line can see the 'globals' that are
> > defined inside "abc.e". So if another file wants to see them they also
> > have to explictly include "abc.e".
> 
> Indeed, that is perfect (or maybe 'include private').
> If Euphoria did not have to be backwards compatible, I would say
> 1-level inclusion like this  should be the default behaviour. (with an
> 'include global' or something)
> 
> The 'private include' would make namespacing problems so much easier, too...
> 
> > This is just a quick spur-of-the-moment thought, so it probably has
> > got issues with it.
> Not that I can see... certainly no logical problems to it. As long as
> it's not too difficult to implement, Rob, DO IT! 
> 
> > It would certainly help me with many of the projects I'm working on.
> And mine, too...
> 
> --
> MrTrick
> 
> 
> 
> 
>

6. Re: private include files

• Posted by "Juergen Luethje" <j.lue at gmx.de> Oct 12, 2004
• 455 views

Greg Haberek wrote [quoting order rearranged]:

> On Tue, 12 Oct 2004 14:48:43 +1000, Patrick Barnes <mrtrick at gmail.com>
> wrote:
>>
>> On Mon, 11 Oct 2004 21:39:56 -0700, Derek Parnell wrote:
>
>>> Has anybody got any thoughts about extending the 'include' system so
>>> that anything included can only been 'seen' by the file that included it.
>>
>> It's been brought up before... but nothing has happened of it.
>> Are there any technical problems with implementing it, Rob? That is to
>> say, the visibility...
>>
>>>    private include abc.e

<snip>

> Or maybe a slightly different approach: inline files. Upon reaching
> keyword 'inline' the Interpreter continues to parse that file as if it
> were in the local file, yet keeping track of separate line numbers,
> etc..
>
> inline myfile.e    -- file is inserted inline at this position

This has the disadvantage, that the local variables in the inlined file
are not local to that file any more, after it has been inlined. So
inlining IMHO might cause some (more or less unexpected) naming
conflicts.

BTW: You can do this inlining already, using Tommy's Kanarie Template
     System as preprocessor for Euphoria.

Regards,
   Juergen

-- 
A: Because it considerably reduces the readability of the text.
Q: Why?
A: Top posting.
Q: What is annoying in e-mail and news?

8. Re: private include files

• Posted by Matt Lewis <matthewwalkerlewis at yahoo.com> Oct 12, 2004
• 426 views

Derek Parnell wrote:
> 
> Has anybody got any thoughts about extending the 'include' system so
> that anything included can only been 'seen' by the file that included it.
> 
> For example, if we have ...
> 
>    private include abc.e
> 
> then only the file that has that line can see the 'globals' that are
> defined inside "abc.e". So if another file wants to see them they also
> have to explictly include "abc.e".  Further more, if "abc.e" has
> already been included without the private qualifier, that will no cause
> any conflicts.
> 
> This is just a quick spur-of-the-moment thought, so it probably has
> got issues with it.
> 
> It would certainly help me with many of the projects I'm working on.

This actually sounds like it should be really easy to implement on top
of the namespace improvements that Rob is adding for 2.5--see my 
modified interpreter.  It only tries to resolve conflicts, but considers
also indirectly included files.  I would think that adding something like
'include private' should allow Rob to flag the file, and just alter the
namespace search tree.

The only real benefit I see from this is not having included files in 
libraries polluting the user's namespaces, which could definitely be 
important for when two libraries have conflicting names in lower level
includes.

Matt Lewis

10. Re: private include files

• Posted by Patrick Barnes <mrtrick at gmail.com> Oct 13, 2004
• 434 views

On Tue, 12 Oct 2004 19:03:03 -0700, Hayden McKay
<guest at rapideuphoria.com> wrote:
> 
> posted by: Hayden McKay <hmck1 at dodo.com.au>
> 
> I dont think that it is really all that nessaccary to have global includes
> 
> I like how you can make each include file run completely independant of
> other include files handled by the program. Each include file has its own
> set of decleared variables and routines. A global include would make all
> the functions/procedures, variables etc.. available to all the includes
> handled by the program, this would defeat the purpouse of a private include

'global include' is not what you're describing it as. Global include
is the default behaviour in Euphoria now... If you include a file into
your library, then another library that includes your library will
automatically have visibility of the global routines in the first
file. When the end programmer includes the second library, they have
visibility of the global routines, constants and variables in library
2, library 1, and the original included file.

This is responsible for most of the namespace problems in Euphoria.

Almost all of the time, the programmer only needs access to the things
in the library that is included, NOT those in subsequent files.

The only exception I can think of, is when a library needs to be
broken up into.--- nope, all of the user-visible parts should be in
the base library....

The only exception I can think of then, is when a set of constants
needs to be shared ---- that's a bit hazy even, shouldn't the
programmer include them directly if needed?

The thing is, that when there are exceptions, then 'global include'
can be explicitly used... and I can't see it being used much.

-- 
MrTrick

12. Re: private include files

• Posted by "Juergen Luethje" <j.lue at gmx.de> Oct 13, 2004
• 429 views

CoJaBo wrote:

> I would have posted this reply much erlier, but the
> cracker who posted that senseless junk (ALL YOUR
> BASE ARE BELONG TO US) seems to be crashing my router...
> (See bBelow)
>
> Patrick Barnes wrote:
>>
>> On Mon, 11 Oct 2004 21:39:56 -0700, Derek Parnell
>> <guest at rapideuphoria.com> wrote:
>>> posted by: Derek Parnell <ddparnell at bigpond.com>
>>> Has anybody got any thoughts about extending the 'include' system so
>>> that anything included can only been 'seen' by the file that included it.
>>
>> It's been brought up before... but nothing has happened of it.
>> Are there any technical problems with implementing it, Rob? That is to
>> say, the visibility...
>>
>>>    private include abc.e
>>>
>>> then only the file that has that line can see the 'globals' that are
>>> defined inside "abc.e". So if another file wants to see them they also
>>> have to explictly include "abc.e".
>>
>> Indeed, that is perfect (or maybe 'include private').
> I think "private include" would look much nicer,
> and be less confusing.

It will be confusing anyway, because there is no "private procedure", or
"private object". E.g. Hayden McKey is already confused, _before_ this
feature is actually implemented.

>> If Euphoria did not have to be backwards compatible, I would say
>> 1-level inclusion like this  should be the default behaviour. (with an
>> 'include global' or something)
> I am definately against that being the default, since
> it would cause many of my programs to fail.
> In fact, I am still using 3 different versions
> of Win32Lib due to compatability problems...
> What a headache that is!

On Windows, there are good search-and-replace programs.
I don't know Linux, but what I read about it now and then, it sounds as
if there are tools for any situation on Linux anyway. 
Please keep in mind: Such a change of the language will be "forever",
and it should be _very_ clean! Half an hour of work for an "old user"
is little cost for a very clean language.

We already have
-        function/procedure foo()
- global function/procedure foo()

-        object bar
- global object bar

So it should be
-        include myfile.e
- global include myfile.e

IMHO it is almost impossible to overestimate the meaning of simplicity,
readability, and consistency of a programming language!

Additionally, as I wrote in another post, it reads in refman_2.htm,
2.4.2 Scope (Euphoria 2.4): "Euphoria encourages you to restrict the
scope of symbols."
This is important, and in this context it only can mean, that 'private
include' should be the default behaviour.

<snip>

Regards,
   Juergen

-- 
We don't know where to GOTO if we don't know where we've COME FROM.
http://www.fortran.com/fortran/come_from.html

14. Re: private include files

• Posted by "Juergen Luethje" <j.lue at gmx.de> Oct 13, 2004
• 416 views

Chris Bensler wrote:

<big snip>

> Euphoria's foremost characteristic is elegance. Consider that first.
> Elegance doesn't just mean pretty and simple. It also means stable and
> homogenous. Local includes does not fit well in Euphoria's existing
> structure. The very reason WHY euphoria is simple, is because it's
> design is based on very few concepts, which are used well.

Well spoken.

> When I think of elegance I think of ballroom dancing. There are no
> sudden movements, everything flows and the dancers are symbiotic (they
> act as one).

Nice picture.

> Euphoria's elegance is the reason most of us are using Euphoria.

I also think so.

> I personally, would argue against any solution geared at circumventing
> issues with backwards compatability. Deal with the compatability, and we
> will have a much more desirable and effective Euphoria.

I'm just a little lazy ATM, so instead of writing something myself, I'll
put some quotes from my clipboard here, that shall underline, why all
this is so important.


"I absolutely fail to see how we can keep our growing programs firmly
within our intellectual grip when by its sheer baroqueness the
programming language -- our basic tool, mind you! -- already escapes our
intellectual control."
[E. W. Dijkstra (1987), The Humble Programmer (talking about PL/I)]

"We must recognize the strong and undeniable influence that our language
exerts on our way of thinking, and in fact defines and delimits the
abstract space in which we can formulate -- give form to -- our thoughts."
[N.Wirth, 1974]

"A language that doesn't affect the way you think about programming, is
not worth knowing."
[A.J. Perlis (1982), Epigrams on Programming, No. 19]

"An unreliable programming language generating unreliable programs
constitutes a far greater risk to our environment and to our society
than unsafe cars, toxic pesticides, or accidents at nuclear power
stations."
[C.A.R. Hoare (1987), The Emperor's Old Clothes]

"Programmers are always surrounded by complexity; we cannot avoid it.
Our applications are complex because we are ambitios to use our
computers in ever more sophisticated ways. Programming is complex
because of the large number of conflcting objectives for each of our
programming projects. If our basic tool, the language in which we design
and code our programs, is also complicated, the language itself becomes
part of the problem rather than part of its solution."
[C.A.R. Hoare (1987), The Emperor's Old Clothes]

Regards,
   Juergen

16. Re: private include files

• Posted by Pete Lomax <petelomax at blueyonder.co.uk> Oct 14, 2004
• 422 views

On Wed, 13 Oct 2004 12:41:30 +0000, Chris Bensler <bensler at nt.net>
wrote:

>The scope that is missing is group scope. NOT private scope.
>Euphoria lacks the ability to include a file across a regulated domain 
>of files.
Agreed
>What is being proposed for 'global include' would change global from 
>program scope to group scope. There would be no universal program scope. 
I certainly missed that. Can you quote me the lines I misunderstood?

Meanwhile, I'll just try replacing one word with another (x3):
>>Pete Lomax wrote(slightly edited):
>> A group procedure or object is visible inside sub-includes,
>> similar to global variable handling, but is removed from the
>> symbol table at the end of the file that defined it, which is more
>> like local variable handling.
>> 
>> When a file is "group included", these group variables do NOT 
>> disappear, but remain visible until the end of the including file. 

<snip>
>Besides, as juergen pointed out. Local includes does not follow the 
>character of Euphoria. In contrast, global include compliments 
>Euphoria's existing scope system. It's not just a hack to make it work. 
>It's a real solution.
The problem with global is that it is all or nothing, well all or just
the one file. I have no idea how you think global include will permit
a group scope.

>People need to stop trying to defeat the backwards compatability issue, 
>and accept that Eu must change to be better.
When I dig my heels in, it is because I cannot see the benefit. I will
happily (unhealthily so, in fact) edit all the programs I use with no
complaints, if I understand the benefit. What I won't do is support
incompatibility to create the illusion of progress. (btdt)

>Euphoria's foremost characteristic is elegance. Consider that first.
>Elegance doesn't just mean pretty and simple. It also means stable and 
>homogenous.
Well said. That is first and foremost in my mind, all the time.
In another thread there is a request for vertical slicing, which
sounds good, but saying there is no need to assign to a vertical slice
is an imbalance which worries me.

>Local includes does not fit well in Euphoria's existing structure.
What is the difference between local and group?

>The very reason WHY euphoria is simple, is because it's 
>design is based on very few concepts, which are used well.
Eu gives a great /illusion/ of simplicity, agreed; I will back Rob
when/if he points out that a "simple" change is not.

>I personally, would argue against any solution geared at circumventing 
>issues with backwards compatability. Deal with the compatability, and we 
>will have a much more desirable and effective Euphoria.
You are quite right. Even a small gain can be worth breaking many
things, providing the fixes required are well documented, and it is at
least part of a larger plan.

For example, under the proposals as I understand them, what is the fix
required for this?

include win32lib.ew
	pretty_print(1,sort(lower("cBa")),{})

Not difficult, but it must be properly documented, and justified.

Regards,
Pete

18. Re: private include files

• Posted by OtterDad <otter at full-moon.com> Oct 14, 2004
• 444 views

<Soapbox begins>
I, for one, applaud Rob's, Derek's and all other coders who insist on 
backwards-compatible code changes. I write commercial applications for 
a very large company. Some code that I wrote years ago is still in use 
today. It gets very frustrating to go back into older code and make a 
minor change only to find out that an update to library xyz now makes 
me debug what was perfectly good code yesterday. I got so frustrated 
that whenever I deploy a program I also catalog every single included 
file along with the program source. This turns a 4k program file into 
a 2 Meg archive. At least this way I know I have the exact copy of all 
code needed to make it work in the future.
<Soapbox ends>

Yours, OtterDad

Don't sweat it -- it's not real life. It's only ones and zeroes. Gene Spafford