OpenEuphoria

1. export & public

• Posted by kinz Dec 03, 2008
• 1361 views

Dear EU users,

We have now two new key words which are useful, but words themselves are not clear enought and require some broad explanations.

I'd like to see just "up" instead of "export"

up procedure foo() 
    ... 
end procedure 
 
up constant FOO=0 

Same about "public" - just "and_up".

and_up function fOO() 
     ... 
end function 
 
and_up include foo.e 

There is nothing to do with "export" and "public" in programming at all, I think.

There is just one level or more *up* in scope.

In Russian mode of bilingual EU 2.5 there is no my favourite "global" at all, for example.

Instead used Russian word "vezde" which means "anywhere" in English, not "global".

What do you think, guys?

Regards, Igor Kachan kinz@peterlink.ru

3. Re: export & public

• Posted by jeremy (admin) Dec 03, 2008
• 1358 views

I agree with Matt on this one.

Jeremy

5. Re: export & public

• Posted by ChrisB (moderator) Dec 03, 2008
• 1349 views
• Last edited Dec 04, 2008

Hi

I would like to further the discussion on this one.

Having given this some considerable thought, I can't help thinking that the new, modernised, include system is somewhat inelegant. Look at the problems that have been had with Langwar (admittedly the current problem is not an include problem, but one of memory management).

The current idea seems to be to include whatever files you want to include, within the files that you include (this is why its inelegant - its moved away from the beautiful simplicity of eu3). This has been explained in various ways (by means of foo, bar.e etc, many times, and yet when it comes to implement it (in Langwar for instance), it just seems to fall over.

Derek's comment, that I was not supposed (or recommended) to include std.e will I suspect become one that will come back to haunt him time and again, as beginners, and lazy programmers (myself included), who simply want the job done quickly, without having to hunt through the st include library to find the function (and dependencies) that they want, will just include std.e

The old eu include system, while it had its faults, was quick, and simple to use, and any namespace problems could be resolved by changing the name of the function, or by using namespace qualifiers. (specifically, put the includes for the entire program in the head of the main program, and then allow allow functions etc, in the main program, and the includes, find the functions etc called below them)

To have to specify the scope of functions, procedures etc within include files, and then to have to specify that the include is public, and it is allowed to access it, and then to make sure add include directives to any sub includes is wrong (IMHO), and certainly a step away from the original goals of euphoria to be a simple to write programming language.

If you come back and say, that's not how it is, lets explain it to you again, then this just goes to illustrate my point. I certainly do not hope to attain the heady heights of computer programming attained by Derek and Matt, but I am no newby with either programming or euphoria, and I suspect that if I am having problems, then many other people will be too.

My request is therefore this - continue with forward referencing of functions and procedures and the language keyword list, but remove the include directives, public and export, and allow multiple level includes includes again, or add another directive that allows the 'sloppy' include method.

Derek asked me if I had downloaded the SVN version - in this instance I think it important that I do not, but I will continue to download, and rigorously punish any alpha release that comes along, as I will have no preconceived notion of what I should and should not be doing, that the devs will have acquired through there day to day involvement with the language.

I would like to stress that the developers have done a great job to get eu 4 to where it is, most of the programs I test run with little or no mods, and some work arounds, (DOS programs too) but that include system is going to be a nightmare. The programs that include files are generally only include level deep, and are the 3.1 includes.

Hope I haven't put too many noses out of joint. And of course, the whole development cycle may have gone too far to backtrack, but if this is the case, then I suspect that there will be drop off of current users, or at least a reluctance to leave 3.x behind, despite the advantage that 4 offers.

Chris

7. Re: export & public

• Posted by mattlewis (admin) Dec 03, 2008
• 1648 views
• Last edited Dec 04, 2008

I don't think that it falls over at all. It's true that 4.0 (including the standard library) is not fully backwards compatible with 3.1, and it does take a bit of work to migrate code like langwar. First, I'd say that we didn't break things lightly, but that we did look to see where things could really be improved, and where breaking some backwards compatibility was beneficial.

More on why I think the changes to the include system were beneficial below...

That's certainly one way to do things. It does increase the odds of namespace conflicts, requiring additional work to deconflict those issues. The new standard library is a lot bigger than the old one, and there are conflicts between different files in the standard library, and with some built-ins, such as find().

One of the key advantages of the new scoping and include system is that it's easier to insulate code in one file from interfering with others. It's probably true that your own code in a file is unlikely to conflict in a single application, but this also applies to 3rd party libraries.

Here is a contrived example. Suppose that for some reason, you had a project that used both win32lib and arwen. I haven't looked at arwen closely, but I would be surprised if there weren't some namespace conflicts with win32lib (and if I'm wrong, then imagine that they are two other libraries that you are usingmaybe you need to connect to two different types of database). In 3.1, it was very possible to have two 3rd party libraries conflict with each other. Due to the global scoping of euphoria, the only way to resolve such a problem (remember, the namespace error is occurring within the libraries, not in any code that you wrote!) was to edit one or both of the libraries.

The new way of doing things really isn't much more difficult. It's true that you'll need to put the include statements in each file. But in addition to the benefit of not having 3rd party conflicts, you have the additional benefit of more self documenting code, in that it's clearer what dependencies for a particular file are. It also reduces the potential for namespace conflicts, so code is more likely to 'just work' without having to qualify symbols.

I think that a problem is that the intention of the system hasn't been explained and demonstrated. During development, we noted that we needed to explain and educate a wider audience to understand how the new things worked and to explain the benefits and the drawbacks. That hasn't really happened, though now that we've actually released a version to the public, we need to get moving on that (and here is one instance ).

The "public include" mechanism is really meant for library developers. First, one assumption behind 4.0 was that the global scope was too open, and invites problems - many of which become apparent mainly in large projects, and especially those that use multiple 3rd party libraries.

While some libraries work well as single files, there are others, such as win32lib, that are easier to maintain and work with if they are multiple files. However, it is often desirable to present a clean interface to consumers of the library. Not all win32lib routines called by a win32lib app actually reside in the Win32Lib.ew file. With global scope, this isn't a problem in exposing functionality to the consumer, though now we can have lots of namespace issues.

Initially (in 4.0 development), we had just the public scope in addition to global. So we could expose a symbol from a file, and also allow the scope of the symbol to propagate through a "public include" statement. This would allow the developer to put API routines anywhere in his multi-file library. But in this system, there is no way to limit the scope of a symbol to only be used within the files of win32lib.

Enter the export scope. This declares symbols that cannot be propagated through additional include statements. So a library author could have internal library implementation that would remain hidden to the consumer of his library, but could be visible to multiple files within his library.

So that's a quick history of how the current scopes came to be, and some basic rationale for their existence.

I guess I don't understand what you're illustrating here. There are some new concepts, and I agree that we need to communicate better about this. Undoubtedly, the documentation could be improved, and there's probably FAQ or wiki content that could/should be created. For the typical user, however, I think that it's still pretty easy.

If you're just using other people's code (including the standard library) then usually all you need to do is to put a regular old include statement in your file, and then use the code. If you're designing libraries for other people to use, then there are some additional things you need to think about, because 4.0 offers some more powerful tools in the way of scoping the contents of your library.

The 'sloppy' include method still works. Well, it still works so long as you are using global symbols. After due consideration on the development list, and in the same process that gave us the scopes that we now have, the decision was made to reduce the reliance on global, mainly for the reasons I gave above, but I'm sure there were others.

In short, the cost is that you type some additional include statements. The benefit is that you will eliminate namespace conflicts between 3rd party libraries, and also reduce the frequency of namespace conflicts and the requirement to qualify references in your own code.

That's fine. I think Derek's point was that he'd made some fixes in response to your report, and wanted you to test them out to see if they fixed the issues. You're absolutely correct that it's important to get outside reviews and testing. We've knocked down an awful lot of bugs, but there are lots of little corners out there that we probably haven't touched. It's worth noting that we have written lots of unit tests for euphoria 4.0, and continue to add them as issues come up. It's helped us a lot, and will continue to help us.

I think that once you get a little more familiar with it, it won't be so bad. We've even got some tools to help migrate to the new standard library. They're in the source directory (dis.ex), and unfortunately not well (or at all!) documented, which needs to be remedied. There is actually an option to have dis.ex generate a graph showing you how all of your include files are related (NB: you'll need to install GraphViz to get the graphs).

I think that there will definitely be a reluctance, as there is with every major version of any piece of software. But I think that once people get comfortable with the additions, they'll be very happy with [most] of what euphoria 4.0 has become.

And this has been much more civil than the developer list often becomes.

Matt

9. Re: export & public

• Posted by ne1uno Dec 04, 2008
• 1351 views

source/std.ex

exwc source/std.ex someprog.ex 

output is on the console, and will create ex.err you can view or open in a text editor. this can fail if for ex you are beginning to convert an eu3 program and still have include misc.e or a known eu4 keword like loop used as a variable. you would want to start by fixing any includes you know will need to change and avoid mixing v3. and v4 includes. although it may work if you are lucky.

unfortunately, source dir was excluded from the first alpha distribution. grab the source dir from svn and create rev.e if you want to try dis or std before the next eu4 alpha or beta.

analize.ex

win: 
exwc eu4\bin\analize.ex someprog.ex 
nix: 
exu eu4/bin/analize.ex someprog.ex 

analize can also catalog 3rd party libs by including their include path in an euinc.conf or -i ..\..\path on the commandline

if you have many files and directories on your euinc path this can take some time and memory on a slower computer. you will probably want to limit the paths accordingly.

-TEST

used as a commandline option,

exwc -TEST someprog.ex 

11. Re: export & public

• Posted by kinz Dec 04, 2008
• 1332 views

Bernie wrote:

Igor: I think that your problem is that there is no Russian word for 'public' another word for public might be the Russian word for 'open'.

Hi Bernie,

No, we have this word in many variants and they all sound almost just as English - "publika" - public, people; "publichnyj" - for public; "publikovat'" - to make visible for public, etc.

For "open" there is different word - "otkrytyj", so I do not have any problem with understanding what really means "public".

But in EU 4.0, this word is not suitable, I think.

If I'll update the bilingual EU 2.5 to 4.0, its "public" become "and_up" to be absolutely clear in specific Euphoria context.

Same about "export". Translated to Russian, it will be the Russian equivalent to "up".

Regards, Igor Kachan kinz@peterlink.ru

13. Re: export & public

• Posted by mattlewis (admin) Dec 04, 2008
• 1354 views

I've made this into a wiki page:

http://openeuphoria.org/wiki/euwiki.cgi?dis.ex

Matt

15. Re: export & public

• Posted by DerekParnell (admin) Dec 04, 2008
• 1294 views

I am only replying so that my silence is not interpreted as anything, other than my disinterest in trying to have yet another fruitless dialog with Mr Kachan.

This is a programming language and not English. It is based upon the English language and reserves the right to adapt existing words to express concepts that are not covered by existing English words. Even in English, it is common for a given word to have different meanings depending on the context that the word is found in. You might like to broaden your mind to encompass the idea that sees the Euphoria language as a new context for English words.

With this in mind, a "public" symbol has been re-used to to express the concept that a symbol is "available to anyone (the public), so long as they explicitly choose to include it". As an analogy, a playground might be declared as public, but it does not mean that you can use it until you actually go there.

The idea of a "public" include is a type of shorthand insomuch as the public symbols in the file being included are deemed to have been declared as public in the file using the "public include". There is no obvious word to use from English to express this idea. An analogy might be that you have a ticket to go from London to Melbourne, but on route you need to change planes at Dubai - You don't have a ticket for Dubai but the one you have allows access to any number of way-stops on the main route. In a similar idea, a public symbol is normally only a "ticket" to the next stop, but a "public include" enables that "ticket" to be used as a transit ticket to a third destination. This is normally only used by library authors who are writing a large library consisting of many files instead on one large monolithic file. The "public" symbols are there for people to access the library's API even though they might have been declared in sub-library files. THat sort of implementation detail is not relevant to the application author.

Consider the Win32lib. It consists of many files. Each of these files can declare public symbols which are intented to be used by the application coder. However, because a public symbol is only made available to files directly including it, these sub-library declarations would actually be invisible to the application. To assist library writers, we developed the idea of a "public" include. Its job to make available public symbols in sub-library files to the application coder - AS IF they were declared "public" in the main library file.

The term "export" is being used to express the concept that a symbol might be needed within a multi-file library but is not really a part of the API. This is a way to allow library authors to develop a multi-file library that contains symbols that are designed to only be used internally within the library's own files. These "export" symbols behave like "public" ones in that they are exposed to the file that includes them, but a "public include" does not propagate them any further along the include chain. Again, there is not a simple English word to cover this concept. (On a personal note, I voted against the word "export" and wanted to use the word "library" because these are library-internal symbols, but I was out voted - such is life.)

I must say that the terms "up" and "and_up" are very poor choices. There is no "up" as a direction of propagation. That concept depends on the model one uses to describe the relationships between files in a Euphoria application. It might apply to an inverted tree model, but it is not an absolute term that applies to all models. However, if your Russian speakers will get benefit then of course use these approximations.

This is not a discussion; just my thoughts on the subject.

17. Re: export & public

• Posted by kinz Dec 04, 2008
• 1298 views

...

Key word "up" means "one level UP to user of the library".

Key word "and_up" means "one or more levels UP to user of the library".

Just try to explain your "export" and "public" to EU new comer, and you will come to these short formulas above (but after reading pages and pages of docs and discussions).

Thanks to all. The question seems to be settled.

Regards, Igor Kachan kinz@peterlink.ru

19. Re: export & public

• Posted by jeremy (admin) Dec 04, 2008
• 1325 views

Um, "up" and "and_up" are two very, very confusing words to me and I've explored many programming languages. "export" and "public" are very common programming words and are very easily explained to anyone, a Eu newbie or veteran. export = make the item visible to it's parent (i.e. the opposite of import) and only to it's parent, no matter what it's parent thinks should be done with it. public = make it available to it's parent and allow it's parent to do with it whatever it thinks is necessary, after all it is usable to the general public.

I guess I would be open to a different word for public and or export but we thought long and hard before making that choice. up and and_up are not better choices. If we come up with better choices, I would be up for more conversation on the subject.

Jeremy

21. Re: export & public

• Posted by mattlewis (admin) Dec 04, 2008
• 1341 views

They are similar. Both allow symbols to be exposed to a file that includes the file in which they are declared. public symbols can possibly be seen by the files that included the file, etc, assuming public include is used to include the files. Here is a simple example:

export constant A_EXPORT = 0 
public constant A_PUBLIC = 0 
       constant A_LOCAL  = 0 

public include libA.e 
  -- these are legal: 
? A_EXPORT 
? A_PUBLIC 
  -- this is not: 
? A_LOCAL 

include libA.e 
  -- these are legal: 
? A_EXPORT 
? A_PUBLIC 
  -- this is not: 
? A_LOCAL 

public include libB.e 
  -- this is legal: 
? A_PUBLIC 
  -- these are not: 
? A_EXPORT 
? A_LOCAL 

include libD.e 
  -- this is legal: 
? A_PUBLIC 
  -- these are not: 
? A_EXPORT 
? A_LOCAL 

include libC.e 
  -- these are not legal 
? A_PUBLIC 
? A_EXPORT 
? A_LOCAL 

I've just shown several different files that have varying visibility of the symbols in libA.e. Of course, only libA.e can use symbols declared as local (i.e., no modifiers), just like 3.1. And we can see that all the files that directly include libA.e can use A_EXPORT and A_PUBLIC. None of the files that did not directly include libA.e can use A_EXPORT.

The key difference shows up between libE.e and libF.e. Notice that libE.e can still use A_PUBLIC, while libF.e cannot. This is because:

libE.e includes libD.e public includes libB.e public includes libA.e
libF.e includes libC.e includes libA.e

Basically, the public include directive passes along any public symbols it can see in any other files. It may have been able to see them because it directly included the file, or because of other public include directives in files it included (as the example above shows).

Mattt

23. Re: export & public

• Posted by euphoric (admin) Dec 04, 2008
• 1324 views

Well, I see that ChrisB's issues were already addressed, and with more clarity than I gave. Next time I'll read the entire thread before speaking up. However, I think my experience in converting to Eu4 is still enlightening.

25. Re: export & public

• Posted by kinz Dec 04, 2008
• 1347 views

Jeremy, sorry, but there is one question more: who or what is that "parent" in EU programming?

I just see one dictionary:

http://www.merriam-webster.com/dictionary/parent

Yet another dictionary:

http://en.wikipedia.org/wiki/Parent

Then docs of our old good EU:

http://www.rapideuphoria.com/cgi-bin/guru.exu?refDoc=on&libDoc=on&otherDoc=on&keywords=parent

There is just nothing about any object, similar to new my problem just with your new the "parent" word.

Or you want me to learn many programming languages just to understand "export", "public" and now "parent" in 4.0?

Good news - before programming in EU 4.0, learn please the jargon, i.e. traditional Mumbo-Jumbo, from C, C# etc .....

There are main file (users program) and library files in EU.

What is that "parent", as you say. Library or main file?

My new main file is almost empty now, is it a "parent"?

No, I think.

Ok, I've just included win32lib.

Is my main almost empty file "parent" for win32lib?

Oh, no-no, oh, sorry-sorry, Big Dave is Parent of win32lib...

And so on with that "parent".

Sorry Jeremy, I hope we all and you do have some sence of humor

But:

--lib.e 
up procedure first() -- will work in upper file  
 ... 
end procedure 

will work in my main file, if I write:

--main.ex -- young (new) program 
include lib.e -- old good lib, what is a "parent" ? 
first() 

Do you see, your "parent" just seems to be from that series of those Mumbo-Jumbo words of conventional languages?

Same as "public" and "export" (the opposite of "import")

I'll use Russian "vyshe" and "i_vyshe" i.e. "up" and "and_up" in bilingual version.

I do know who is father and who is son.

Regards, Igor Kachan kinz@peterlink.ru

27. Re: export & public

• Posted by Algorythm Dec 04, 2008
• 1335 views

Ghm

In my h. opinion, the "public" word is usually used in programmin' langs, and it is normal to use it instead "global". But I have one big question why use "export" word? As I can see, the "export" means nearly the same that "public" means, but the exported routines is abled to use in file when them was declared and the file, which includes that file when them was decalred (did u understand? ).

But why it is neccessary? Why use the "export" instead the "public"?

Well, Igor, your "i_vishe" is not so clear for me... "vezde_vishe" is more informative, isn't it?

All I have written is my HO.

Thank you all, Algorythm algorythm at yandex.ru

29. Re: export & public

• Posted by mattlewis (admin) Dec 04, 2008
• 1345 views

This post explains the reason for both public and export:

http://openeuphoria.org/EUforum/index.cgi?module=forum&action=message&id=103042#103042

Matt

31. Re: export & public

• Posted by DanM Dec 05, 2008
• 1321 views

Might either of the words "private" or "restrict" better communicate the intention of the word "export"?

Export means "to send an item out from", without implying any innate restriction as to where the item might end up at, which seems to not be what is intended by using it in V4.0

"private" and "restrict" both seem to fairly clearly indicate that a symbol referenced by them is only available for use by the file that included the file containing the symbol.

Dan

33. Re: export & public

• Posted by DanM Dec 05, 2008
• 1289 views

Do I have this right:

"export" is a kind of alternative for "global", in that it allows an "export"ed symbol to be SEEN by the including file, but with the advantage that it can ONLY be seen by the including file?

Whereas "public" is a DIFFERENT alternative for "global", in that if a file says "public include foo", then any of the "public" symbols that were in foo now CAN be seen by ANY FILE that included the file that said "public include foo"?

If that's right, then it would seem that "private" could reasonably be used instead of "export", because any "private" symbol would be only privately available to the immediately including file,

and "restrict" could be used instead of "public", so that a "restrict"ed symbol would normally be only seen by the immediately including file, but with "unrestrict include foo" meaning that any of the ""restrict"ed symbols that were in foo now CAN be seen by ANY FILE that included the file that said "unrestrict include foo"?

So "private" would be one step up from local symbols, and "restrict" (or "restricted"?) would be potentially one-half step above "private", in scope.

Perhaps that might also satisfy translation of keywords from English to other languages?

Dan

35. Re: export & public

• Posted by euphoric (admin) Dec 05, 2008
• 1279 views

They'd have to be really really close friends for me to let them see my privates.

Wait, what are we talking about?

37. Re: export & public

• Posted by jeremy (admin) Dec 05, 2008
• 1332 views

Everywhere I have seen the word private, it means specifically, outside the immediate scope, no one can access this item. The scope being a class or a file. The idea of a private journal is a good analogy for every day objects, but is counter intuitive compared to all programming languages I've ever used.

Jeremy

39. Re: export & public

• Posted by DanM Dec 05, 2008
• 1253 views

Ok, if it goes against the grain for normal usage in other programming languages, never mind; I also noticed that my suggestion of "unrestricted" might seem to suggest COMPLETELY unrestricted, which isn't what's desired in this situation, so nevermind for it too.

Dan

41. Re: export & public

• Posted by bernie Dec 05, 2008
• 1274 views

Jeremy:
How about not_shared, shared, fully_shared ?

PS. When is win98 alpha comming out ?

43. Re: export & public

• Posted by jimcbrown (admin) Dec 05, 2008
• 1241 views

The alpha is based on Shawn's eubins. His windows eubins are designed to work on 98 if I have understood Shawn correctly. (I haven't actually tested them on 98, however.)