1. Weighing in on everything
Warning: Long post ahead. Watch your head.
I guess it's about time I weighed in on a few of the recent topics, being one of
the
oldtimers here (Euphorian since 1.4).
The IRC conference:
A wonderful idea Jeremy. I apologize for not being able to join; but ironically
I
have less time for meetings on the weekends than I do during the week. Perhaps
next time, though, a bit more advance notice could be given. I actually didn't
even see the notice until several hours after the meeting had ended. I did
enjoy
reading the log, though.
Namespaces versus prefixes:
Back before namespaces became a part of the language, I had proposed using
prefixes
as a way to create libraries that didn't interfere with common programs or other
common libraries / includes. You'll notice that many of my contributions still
use
prefixes. As has been well stated, there are advantages to both methods of
library
creation. Using a "reserved" prefix makes it close to impossible that any
library
will cause a naming conflict with any other. Rob has always be quite adamant
that
Euphoria remain as minimal as possible. In my opinion, forcing a library to use
a namespace is the worst possible solution; a compromise in which everyone
loses.
Since the main relevance is the new standard includes, the first rule should be
to avoid using any built-in keyword or function in the include file. After
that,
leave the names as short and logical as possible. A conflict will only occur
for
programs that include the new version of the file in error. Since most programs
with dependencies include those files as part of the package (and shame on them
if they don't), a program will still run fine unless the user overwrites the old
include with the new one. As for prefixes, they're great for user
contributions,
but they have no place in a standard include. If an included function is likely
to cause a naming conflict, include a note in the documentation to that effect.
In
fact, in the release notes for version 4.0, make it quite clear that the
enhancements
to the language are going to require a greater use of namespaces and include an
example of how they work.
Namespaces for built-in functions:
Reserve the namespace "internal" in the core for the rare instance they need a
namespace qualifier. I don't see that breaking or interfering with anything.
Including the same file twice under different namespaces:
This was a cool feature (er, bug?) that was removed much to the dismay of the
greater community. I never saw the harm, and never used it; but the potentials
that were being discussed were pretty clever. Since we're updating namespaces,
let's bring this one back.
Colon vs. period for namespaces:
Rob chose the colon because the period already had a number of uses. Since the
coding to allow periods has already been done, I agree that the change should
be made. I suggest one caveat, however: make sure the use of period as a
namespace operator does not introduce any unintended consequences. In other
words,
the change should be tested thoroughly by running about a hundred programs from
the
archives through the modified interpreter. If nothing breaks, submit the
change.
The use of period will make it easier for newcomers to Euphoria from other
languages
to make the transition. I understand Rob's original logic, but I think it no
longer applies. For a language that bills itself as easy to learn and easy to
use,
tripping over punctuation is a real let-down. As was originally suggested,
though,
the colon should be kept as a deprecated part of the language for at least
another
version.
Slicing:
I'm going to step on some toes with this one. Do not, never, at no time,
absolutely
not, allow foo[3..9] when foo only has 3 elements to return anything other than
an
error. I can't tell you how many nasty logic bugs I've caught from this exact
error.
With the use of shortcircuiting, I can tell my program exactly how long I expect
the
sequence to be. If the sequence isn't that length, there is a condition that
needs
to be handled. Allowing the program to merrily continue will create errors
later on
that will be far more difficult to detect, since the error condition will be
farther
removed from the error cause. We have a shortcut for "end of sequence", and
that's what
should be used in these situtations. As for vertical slicing, I see no need to
add
another operator. The form seq[1..10][3..4] is easy to understand, currently
throws
an error, and would be a valuable addition to the language.
Head and tail:
This is a much more elegant solution than changing the way slicing works. The
call
to head or tail makes it explicit that you don't mind if fewer values are
returned.
It mimics the way the same programs work in *nix, making their use obvious. I
also
prefer head and tail to left and right, because I only think of sequences as
horizontal when they are one-dimensional. Also, left reminds me of left_trim,
as
in remove white space characters only from the beginning of the sequence.
Function slicing:
? value("6.5")[2]
On the one hand, there's no way to check if the returned value actually has the
correct number of elements. If not, for reasons stated above, the program
should crash.
That makes the use of function slicing dangerous. However, in a tightly
controlled
program, where the returned value is KNOWN to ALWAYS be a sequence of x
elements, and
the contents of those elements will not cause a logic error later if they are
not
what is expected, this would be a very handy tool. But this is not something
that can
be coded in an include. It must be part of the core, and I haven't yet looked
into it
to figure how much effort it would be to do it.
File extensions:
This is more a matter of convention and OS / Desktop environment settings than
anything
else. I can tell Windows to always use C:\euphoria\bin\exw to run programs with
any
of the extensions ex/exw/exu/e/ew/eu, and it will be happy to comply. Same
thing with
KDE or Gnome. We don't need to introduce any new extensions to meet a need that
doesn't
exist. I've always understood .ex to be runnable on any platform, not DOS only
unless
the documentation for the program states otherwise (like for DOS graphics
modes).
Dropping support for DOS:
Even though MS isn't supporting DOS anymore, there are a lot of open source and
commercial
versions to fill the gap. Unless it can be demonstrated that DOS support is
putting too
much of a strain on advancement of the language, there is no good reason to drop
DOS
support. Besides, having used Euphoria since before there was even Windows
support, it
would be like seeing an old friend vanish without even a chance to say goodbye
:p.
Version number:
I really don't see a whole lot of programs breaking by adding a bunch of new
includes to
the standard distribution. Only those programs that were sloppy enough not to
distribute their dependencies along with the main file will break, and they
would
break anyway if the original author released a new version, standard or
otherwise. I
don't think this warrants a major version number; but I'm not opposed to those
that want
it. In support, the major version change may be very good for public relations,
if
enough people push it in enough forums. I'm abstaining my vote on this one.
Interim release:
Release the existing changes as 3.2 and the new standard includes as 3.3 or 4.0
then.
The interim release should have a full minor number since a few new functions
were added.
That's all for now. If you want to include eunet as a standard, I have no
objections :).
I'll have the bug fix for accept() released this week. Other libraries I would
love to
see that don't exist yet: a PDF reader/writer, atan2() in math.e, SQL Server
support on
Linux, Parrot/DotNet/Mono compilers.
Michael Sabal
2. Re: Weighing in on everything
Michael J. Sabal wrote:
> Including the same file twice under different namespaces:
> This was a cool feature (er, bug?) that was removed much to the dismay of the
> greater community. I never saw the harm, and never used it; but the
> potentials
> that were being discussed were pretty clever. Since we're updating
> namespaces,
> let's bring this one back.
That was a useful 'feature'.
Let's also fix namespacing so it actually helps the programmer create modular
code, or at least doesn't actively discourage it.
Let's consider support for real objects, like most modern programming languages.
Let's not get bogged down in discussing preferences of punctuation, nor
how many programmers can dance on the head of a '.'
That's why I left years ago, in disgust. Hopefully, things will actually get
done this time.
3. Re: Weighing in on everything
irv mullins wrote:
>
> Let's not get bogged down in discussing preferences of punctuation, nor
> how many programmers can dance on the head of a '.'
>
> That's why I left years ago, in disgust. Hopefully, things will actually get
> done this time.
Irv,
Things are getting done and I will not let simple debates get in the way. You
can take a peek at the release notes thus far, and it's far from "done".
http://jeremy.cowgar.com/euphoria/relnotes.htm
Again, please note, the URL above is just some place that I put generated HTML
for the benefit of those to see what's going on. It's not a permanent URL and it
will be removed at some point in the future.
--
Jeremy Cowgar
http://jeremy.cowgar.com
4. Re: Weighing in on everything
irv mullins wrote:
>
> Michael J. Sabal wrote:
>
> > Including the same file twice under different namespaces:
> > This was a cool feature (er, bug?) that was removed much to the dismay of
> > the
> > greater community. I never saw the harm, and never used it; but the
> > potentials
> > that were being discussed were pretty clever. Since we're updating
> > namespaces,
> > let's bring this one back.
>
> That was a useful 'feature'.
>
> Let's also fix namespacing so it actually helps the programmer create modular
>
> code, or at least doesn't actively discourage it.
>
> Let's consider support for real objects, like most modern programming
> languages.
>
> Let's not get bogged down in discussing preferences of punctuation, nor
> how many programmers can dance on the head of a '.'
>
> That's why I left years ago, in disgust. Hopefully, things will actually get
> done this time.
Hi IRV:
I agree with you, instead of wasting time on all the nonsense.
Why aren't things like structures, good working namespaces,
other useful features being built into the interpretor.
Bernie
My files in archive:
WMOTOR, XMOTOR, W32ENGIN, MIXEDLIB, EU_ENGIN, WIN32ERU, WIN32API
Can be downloaded here:
http://www.rapideuphoria.com/cgi-bin/asearch.exu?dos=on&win=on&lnx=on&gen=on&keywords=bernie+ryan
5. Re: Weighing in on everything
Bernie Ryan wrote:
>
> I agree with you, instead of wasting time on all the nonsense.
> Why aren't things like structures, good working namespaces,
> other useful features being built into the interpretor.
I am not sure if this is directed to me, i.e. why am I wasting time on adding
functions vs. making changes to the interpreter.
I'll answer directly as if it were directed toward me, because I am listed as a
developer for Euphoria on the SF page.
Every developer has a different skill set. My skill set is not in the backend or
interpreter. I do not know how to make those changes. What I do know how to do is
expand the library. I saw the need, see that other Euphoria users want this, I
can do it, so I asked Rob, he thought it was a good idea and he gave his
blessings to it, so I started.
I do not know how to make namespaces better. I do not know how to make
structures better. I don't. I'm sorry that my skill set is lacking in your
expectations. Maybe in due time as I read more of the source those things will
come into my skill set.
Now, I will add also that Euphoria is now open source. If you want to contribute
these changes to Euphoria, it's open. That is how Euphoria will survive is by
it's users maintaining it. Each user has a different skill set. If you want to
see something change in Euphoria, discuss it and if majority is in agreement then
do it. If you are not willing to step in and do it, then please, do not complain
to me or about me because I am not working on what you want to have done. I am
working on what I know how to do and what a large portion of Euphoria users want.
--
Jeremy Cowgar
http://jeremy.cowgar.com
6. Re: Weighing in on everything
Bernie Ryan wrote:
>
> I agree with you, instead of wasting time on all the nonsense.
> Why aren't things like structures, good working namespaces,
> other useful features being built into the interpretor.
Good, working namespaces are now in there. The current debate is about the
syntax, but not the functionality, except for the default namespace thing,
but that's just a little nice to have thing, that may or may not be a good
idea. I don't think we've explored that enough.
No one can agree on what euphoria structures should be.
Matt
7. Re: Weighing in on everything
Matt Lewis wrote:
> No one can agree on what euphoria structures should be.
>
> Matt
Euphoria with structures is not Euphoria anymore.
If I were looking for a proglang that has structure but behaves like Eu,
I would have chosen Lua.
8. Re: Weighing in on everything
Matt Lewis wrote:
> Good, working namespaces are now in there. The current debate is about the
> syntax, but not the functionality, except for the default namespace thing,
> but that's just a little nice to have thing, that may or may not be a good
> idea. I don't think we've explored that enough.
Make that 'pretty good' - if you're referring to the svn version, not stock
eu. At least now globals are visible thruout the include chain.
What's needed now is some way for an include file to make and pass on
'copies' of included variables. To give an example:
Windows controls have lots of things in common:
height, width, text color, background color, border, title/text, etc...
Windows has lots of controls - windows, buttons, labels... most of which
use all the "things in common" listed above.
However, you can't get by with ONE height or ONE width for all buttons and
windows in your program. That's what you get now if you try to include the
"things in common" file in both your window.e and button.e files.
Sure, it sort of smells like objects, so some will be against it, but
it certainly would help the rest of us if window:height and button:height
were separate items without having to repeat the "things in common" code
over and over again.
Such a thing is possible - it was done by accident a few years ago.
Despite protests, Rob 'fixed' that. Probably he was worried about unexpected
consequences, I can understand that. Perhaps it's time to give that another
look,
to see if there really are any disastrous side effects.
If people are worried about this, why not just another keyword - import -
perhaps, which works like include but creates copies instead of bringing
in the original? If people don't use "import", they won't have anything to
worry about.
9. Re: Weighing in on everything
yuku wrote:
>
> Matt Lewis wrote:
> > No one can agree on what euphoria structures should be.
> >
> > Matt
>
> Euphoria with structures is not Euphoria anymore.
I disagree. It's still Euphoria, but maybe now it's "Euphoria Plus" or
"Euphoria Turbo" or "Maximum Euphoria."
> If I were looking for a proglang that has structure but behaves like Eu,
> I would have chosen Lua.
I doubt it, because Lua is 8x slower than Euphoria. Or is Euphoria 8x faster?
http://www.rapideuphoria.com/bench.txt
10. Re: Weighing in on everything
yuku wrote:
>
> Matt Lewis wrote:
> > No one can agree on what euphoria structures should be.
> >
> > Matt
>
> Euphoria with structures is not Euphoria anymore.
> If I were looking for a proglang that has structure but behaves like Eu,
> I would have chosen Lua.
Euphoria already has structures. They are called sequences. Only difference
is Euphoria structures are awkward to work with because they don't have named
members, and are overly sensitive to data errors because of the lack of
type-checking.
11. Re: Weighing in on everything
irv mullins wrote:
>
> Matt Lewis wrote:
>
> > Good, working namespaces are now in there. The current debate is about the
> > syntax, but not the functionality, except for the default namespace thing,
> > but that's just a little nice to have thing, that may or may not be a good
> > idea. I don't think we've explored that enough.
>
> Make that 'pretty good' - if you're referring to the svn version, not stock
>
> eu. At least now globals are visible thruout the include chain.
> What's needed now is some way for an include file to make and pass on
> 'copies' of included variables. To give an example:
>
> Windows controls have lots of things in common:
> height, width, text color, background color, border, title/text, etc...
>
> Windows has lots of controls - windows, buttons, labels... most of which
> use all the "things in common" listed above.
>
> However, you can't get by with ONE height or ONE width for all buttons and
> windows in your program. That's what you get now if you try to include the
> "things in common" file in both your window.e and button.e files.
>
> Sure, it sort of smells like objects, so some will be against it, but
> it certainly would help the rest of us if window:height and button:height
> were separate items without having to repeat the "things in common" code
> over and over again.
I'm confused when you say ONE height or ONE width. What are these? Are
they just global integers or something?
Or are they elements of a sequence that holds all of the data? It's
certainly possible to have a hierarchy of UDTs that use super-UDTs to
maintain common data elements.
To borrow from OOP, are the 'copies' instances, or classes? If instances,
then I have to really object. For instance, how would you dynamically
create new objects?
> Such a thing is possible - it was done by accident a few years ago.
> Despite protests, Rob 'fixed' that. Probably he was worried about
> unexpected consequences, I can understand that. Perhaps it's time
> to give that another look, to see if there really are any disastrous
> side effects.
>
> If people are worried about this, why not just another keyword - import -
> perhaps, which works like include but creates copies instead of bringing
> in the original? If people don't use "import", they won't have anything to
> worry about.
I think I need to understand what you mean by copies to be able to respond
to this.
Matt
12. Re: Weighing in on everything
> On 27 Apr 2008 at 9:18, yuku wrote (maybe snipped):
> posted by: yuku <yuku at ?kitek.?om>
>
> Matt Lewis wrote:
> > No one can agree on what euphoria structures should be.
> >
> > Matt
>
> Euphoria with structures is not Euphoria anymore.
> If I were looking for a proglang that has structure but behaves like
> Eu, I would have chosen Lua.
>
I've been there, three or four years ago. Lua is a great language,
fully embeddable, and it could -- probably -- set to work with
Euphoria. There are several examples like RubyLua, Lua4Delphi, C/C++
(of course), etc. Unfortunately, this is far off my poor skills. I
don't need any of that either. ;)
Best,
Euler
--
_
_| euler f german
_| sete lagoas, mg, brazil
_| efgerman{AT}gmail{DOT}com
_| -----------------------------
_| Reply preferably to the list,
_| or to the address above. Thx!
13. Re: Weighing in on everything
- Posted by Bernie Ryan <xotron at b?uefr?g.com>
Apr 27, 2008
-
Last edited Apr 28, 2008
Euler German wrote:
>
> > On 27 Apr 2008 at 9:18, yuku wrote (maybe snipped):
>
> > posted by: yuku <yuku at ?kitek.?om>
> >
> > Matt Lewis wrote:
> > > No one can agree on what euphoria structures should be.
> > >
> > > Matt
> >
> > Euphoria with structures is not Euphoria anymore.
> > If I were looking for a proglang that has structure but behaves like
> > Eu, I would have chosen Lua.
> >
>
> I've been there, three or four years ago. Lua is a great language,
> fully embeddable, and it could -- probably -- set to work with
> Euphoria. There are several examples like RubyLua, Lua4Delphi, C/C++
> (of course), etc. Unfortunately, this is far off my poor skills. I
> don't need any of that either. ;)
>
Euler:
Its already been wrapped by Jeremy Peterson in the archive.
http://www.rapideuphoria.com/cgi-bin/asearch.exu?dos=on&win=on&lnx=on&gen=on&keywords=Lua
Bernie
My files in archive:
WMOTOR, XMOTOR, W32ENGIN, MIXEDLIB, EU_ENGIN, WIN32ERU, WIN32API
Can be downloaded here:
http://www.rapideuphoria.com/cgi-bin/asearch.exu?dos=on&win=on&lnx=on&gen=on&keywords=bernie+ryan
14. Re: Weighing in on everything
- Posted by CChris <christian.cuvier at agriculture.?ouv.?r>
Apr 27, 2008
-
Last edited Apr 28, 2008
Matt Lewis wrote:
>
> Bernie Ryan wrote:
> >
> > I agree with you, instead of wasting time on all the nonsense.
> > Why aren't things like structures, good working namespaces,
> > other useful features being built into the interpretor.
>
> Good, working namespaces are now in there. The current debate is about the
> syntax, but not the functionality, except for the default namespace thing,
> but that's just a little nice to have thing, that may or may not be a good
> idea. I don't think we've explored that enough.
>
> No one can agree on what euphoria structures should be.
>
> Matt
Sorry to disagree, Matt.
1/ If a library uses several files, and a symbol is being used by several of
those files, it will be seen by an application using the lib, and possibly
interfere with it. In the changes you submitted, this condition sometimes causes
a warning, but that will drowned in the noise, as most current warnings are
pointless (short circuiting, locavl symbol not used, etc).
There is no way to tell that a symbol is intended for restricted access from
outside its definition file.
2/ The current global resolution rules make any library routine difficult to
override. You can override it once, and twice for a builtin, and then you have to
mess around with namespaces, assuming this will always work. Try out with print()
and sprint(). And the prototypes must match, so extending a routine is downright
impossible, or quite clumsier than in most other languages. And accessing the
underlying routine from the override requires another awkward call_func() and an
extra symbol to hold a routine_id.
3/ Inclusion of a parent file by a file provides a shaky basis for inheritance,
which is a time proved way of having vleaner, easier to maintain code. The latest
changes didn't rule it out, but this generates a warning as if it were a
discouraged coding practice. This doesn't hurt much admittedly, but is quite
worrisome to me.
So, even though the namespace system will be improved, I can't really say it's
good.
For those interested, check for posts by CChris, Matt or Derek with the
"package", namespace" or "global" keywords.
CChris
15. Re: Weighing in on everything
- Posted by Matt Lewis <matthewwalkerlewis at gm?il.com>
Apr 27, 2008
-
Last edited Apr 28, 2008
CChris wrote:
>
> Matt Lewis wrote:
> >
> > Good, working namespaces are now in there. The current debate is about the
> > syntax, but not the functionality, except for the default namespace thing,
> > but that's just a little nice to have thing, that may or may not be a good
> > idea. I don't think we've explored that enough.
> >
>
> Sorry to disagree, Matt.
>
> 1/ If a library uses several files, and a symbol is being used by several
> of those files, it will be seen by an application using the lib, and
> possibly interfere with it. In the changes you submitted, this condition
> sometimes causes a warning, but that will drowned in the noise, as most
> current warnings are pointless (short circuiting, locavl symbol not used,
> etc). There is no way to tell that a symbol is intended for restricted
> access from outside its definition file.
I agree that the namespace implementation doesn't go this far, and that
this is (at a high level, at least) where we need to go. I still stand
by my characterization, though, because they at least make it possible
to get working code without modifying 3rd party code.
Ignoring the warning reflects more upon the programmer than the tool, IMHO.
Warnings show something that the programmer should consider, because they
are things that are easy to miss, and that can cause problems. I think
there has been some talk of suppressing warnings, which would alleviate
this a bit. But the warnings for not including a file are a Good Thing.
> 2/ The current global resolution rules make any library routine difficult
> to override. You can override it once, and twice for a builtin, and then
> you have to mess around with namespaces, assuming this will always work.
> Try out with print() and sprint(). And the prototypes must match, so
> extending a routine is downright impossible, or quite clumsier than in
> most other languages. And accessing the underlying routine from the
> override requires another awkward call_func() and an extra symbol to hold
> a routine_id.
I guess so. Can you give me an example of where you'd [like to] do this?
If your package solution fixed this particular issue, I don't recall the
details.
> 3/ Inclusion of a parent file by a file provides a shaky basis for
> inheritance, which is a time proved way of having vleaner, easier to
> maintain code. The latest changes didn't rule it out, but this generates
> a warning as if it were a discouraged coding practice. This doesn't hurt
> much admittedly, but is quite worrisome to me.
I'm having trouble understanding this point. Could you expand on what you
mean by inheritance? Are you talking in an OO sense?
> So, even though the namespace system will be improved, I can't really say
> it's good.
Then we can agree to disagree. Again, I'm not arguing that they can't be
made better.
Matt
16. Re: Weighing in on everything
- Posted by "Euler German" <eulerg at gmail.com>
Apr 27, 2008
-
Last edited Apr 28, 2008
> On 27 Apr 2008 at 13:01, Bernie Ryan wrote (maybe snipped):
> posted by: Bernie Ryan <xotron at b?uefr?g.com>
>
> Euler German wrote:
> >
> > > On 27 Apr 2008 at 9:18, yuku wrote (maybe snipped):
> >
> > > posted by: yuku <yuku at ?kitek.?om>
> > >
> > > Matt Lewis wrote:
> > > > No one can agree on what euphoria structures should be.
> > > >
> > > > Matt
> > >
> > > Euphoria with structures is not Euphoria anymore.
> > > If I were looking for a proglang that has structure but behaves
> > > like Eu, I would have chosen Lua.
> > >
> >
> > I've been there, three or four years ago. Lua is a great language,
> > fully embeddable, and it could -- probably -- set to work with
> > Euphoria. There are several examples like RubyLua, Lua4Delphi, C/C++
> > (of course), etc. Unfortunately, this is far off my poor skills. I
> > don't need any of that either. ;)
> >
>
> Euler:
>
> Its already been wrapped by Jeremy Peterson in the archive.
>
> http://www.rapideuphoria.com/cgi-bin/asearch.exu?dos=on&win=on&lnx=on&
> gen=on&keywords=Lua
>
> Bernie
>
> My files in archive:
> WMOTOR, XMOTOR, W32ENGIN, MIXEDLIB, EU_ENGIN, WIN32ERU, WIN32API
>
> Can be downloaded here:
> http://www.rapideuphoria.com/cgi-bin/asearch.exu?dos=on&win=on&lnx=on&
> gen=on&keywords=be rnie+ryan
>
Thanks for the heads-up, Bernie. I should have look for "Lua" in the
archives. My bad. I'm getting lousy, and lazy every day...
Best,
Euler
--
_
_| euler f german
_| sete lagoas, mg, brazil
_| efgerman{AT}gmail{DOT}com
_| -----------------------------
_| Reply preferably to the list,
_| or to the address above. Thx!
17. Re: Weighing in on everything
Matt Lewis wrote:
>
> CChris wrote:
> >
> > Matt Lewis wrote:
> > >
> > > Good, working namespaces are now in there. The current debate is about
> > > the
> > > syntax, but not the functionality, except for the default namespace thing,
> > > but that's just a little nice to have thing, that may or may not be a good
> > > idea. I don't think we've explored that enough.
> > >
> >
> > Sorry to disagree, Matt.
> >
> > 1/ If a library uses several files, and a symbol is being used by several
> > of those files, it will be seen by an application using the lib, and
> > possibly interfere with it. In the changes you submitted, this condition
> > sometimes causes a warning, but that will drowned in the noise, as most
> > current warnings are pointless (short circuiting, locavl symbol not used,
> > etc). There is no way to tell that a symbol is intended for restricted
> > access from outside its definition file.
>
> I agree that the namespace implementation doesn't go this far, and that
> this is (at a high level, at least) where we need to go. I still stand
> by my characterization, though, because they at least make it possible
> to get working code without modifying 3rd party code.
>
> Ignoring the warning reflects more upon the programmer than the tool, IMHO.
> Warnings show something that the programmer should consider, because they
> are things that are easy to miss, and that can cause problems. I think
> there has been some talk of suppressing warnings, which would alleviate
> this a bit. But the warnings for not including a file are a Good Thing.
>
> > 2/ The current global resolution rules make any library routine difficult
> > to override. You can override it once, and twice for a builtin, and then
> > you have to mess around with namespaces, assuming this will always work.
> > Try out with print() and sprint(). And the prototypes must match, so
> > extending a routine is downright impossible, or quite clumsier than in
> > most other languages. And accessing the underlying routine from the
> > override requires another awkward call_func() and an extra symbol to hold
> > a routine_id.
>
> I guess so. Can you give me an example of where you'd [like to] do this?
> If your package solution fixed this particular issue, I don't recall the
> details.
>
I think http://oedoc.free.fr/Fichiers/ESL/complex.zip is a good nest of
examples, specially in the print/format section..
If a symbol is put inside a package so as to be kept off limits, so redefining
it becomes at all possible without artificially imposing a namespace on the user
of say a library.
> > 3/ Inclusion of a parent file by a file provides a shaky basis for
> > inheritance, which is a time proved way of having vleaner, easier to
> > maintain code. The latest changes didn't rule it out, but this generates
> > a warning as if it were a discouraged coding practice. This doesn't hurt
> > much admittedly, but is quite worrisome to me.
>
> I'm having trouble understanding this point. Could you expand on what you
> mean by inheritance? Are you talking in an OO sense?
>
An include file that relies on its parent's feature is exactly as useful and
legitimate as a class/object type that derives from an ancestor. It simply relies
on a context.
> > So, even though the namespace system will be improved, I can't really say
> > it's good.
>
> Then we can agree to disagree. Again, I'm not arguing that they can't be
> made better.
>
> Matt
CChris
18. Re: Weighing in on everything
CChris wrote:
>
> Matt Lewis wrote:
> >
> > CChris wrote:
> >
> > > 2/ The current global resolution rules make any library routine
> > > difficult to override. You can override it once, and twice for a
> > > builtin, and then you have to mess around with namespaces, assuming
> > > this will always work. Try out with print() and sprint(). And the
> > > prototypes must match, so extending a routine is downright impossible,
> > > or quite clumsier than in most other languages. And accessing the
> > > underlying routine from the override requires another awkward
> > > call_func() and an extra symbol to hold a routine_id.
> >
> > I guess so. Can you give me an example of where you'd [like to] do this?
> > If your package solution fixed this particular issue, I don't recall the
> > details.
>
> I think http://oedoc.free.fr/Fichiers/ESL/complex.zip
> is a good nest of examples, specially in the print/format section..
>
> If a symbol is put inside a package so as to be kept off limits, so
> redefining it becomes at all possible without artificially imposing a
> namespace on the user of say a library.
Ok, thanks for the example. Yes. I think we agree (again, at least in
principle, if not in preferred implementation).
> > > 3/ Inclusion of a parent file by a file provides a shaky basis for
> > > inheritance, which is a time proved way of having vleaner, easier to
> > > maintain code. The latest changes didn't rule it out, but this generates
> > > a warning as if it were a discouraged coding practice. This doesn't hurt
> > > much admittedly, but is quite worrisome to me.
> >
> > I'm having trouble understanding this point. Could you expand on what you
> > mean by inheritance? Are you talking in an OO sense?
> >
>
> An include file that relies on its parent's feature is exactly as useful
> and legitimate as a class/object type that derives from an ancestor. It
> simply relies on a context.
Yes, I agree with this statement. I'm just having trouble fitting it in
with "Inclusion of a parent file by a file provides a shaky basis for
inheritance." I guess you're saying you'd prefer a different way to
indicate that the file relies on its parent.
I have two basic responses. First, we already have a method for indicating
that you need something in another file: include. An implicit dependency
is, to me, something that deserves a warning. Relying on other files to
include you is wrong. For one thing, it's difficult to maintain.
The situation may occur where the file is meant to be used in different
circumstances. Euphoria has this, where it is initialized differently if
it's the interpreter, translator or a bound or shrouded mode of operation.
The file that relies on 'parent symbols' has some getters and setters,
which other parts of the code can call to initialize the data. There
is no implicit dependency, and it's quite easy to figure out how and
where these initializations happen.
Matt
19. Re: Weighing in on everything
Matt Lewis wrote:
>
> CChris wrote:
> >
> > Matt Lewis wrote:
> > >
> > > CChris wrote:
> > >
> > > > 2/ The current global resolution rules make any library routine
> > > > difficult to override. You can override it once, and twice for a
> > > > builtin, and then you have to mess around with namespaces, assuming
> > > > this will always work. Try out with print() and sprint(). And the
> > > > prototypes must match, so extending a routine is downright impossible,
> > > > or quite clumsier than in most other languages. And accessing the
> > > > underlying routine from the override requires another awkward
> > > > call_func() and an extra symbol to hold a routine_id.
> > >
> > > I guess so. Can you give me an example of where you'd [like to] do this?
> > > If your package solution fixed this particular issue, I don't recall the
> > > details.
> >
> > I think <a
> > href="http://oedoc.free.fr/Fichiers/ESL/complex.zip">http://oedoc.free.fr/Fichiers/ESL/complex.zip</a>
> > is a good nest of examples, specially in the print/format section..
> >
> > If a symbol is put inside a package so as to be kept off limits, so
> > redefining it becomes at all possible without artificially imposing a
> > namespace on the user of say a library.
>
> Ok, thanks for the example. Yes. I think we agree (again, at least in
> principle, if not in preferred implementation).
>
> > > > 3/ Inclusion of a parent file by a file provides a shaky basis for
> > > > inheritance, which is a time proved way of having vleaner, easier to
> > > > maintain code. The latest changes didn't rule it out, but this generates
> > > > a warning as if it were a discouraged coding practice. This doesn't hurt
> > > > much admittedly, but is quite worrisome to me.
> > >
> > > I'm having trouble understanding this point. Could you expand on what you
> > > mean by inheritance? Are you talking in an OO sense?
> > >
> >
> > An include file that relies on its parent's feature is exactly as useful
> > and legitimate as a class/object type that derives from an ancestor. It
> > simply relies on a context.
>
> Yes, I agree with this statement. I'm just having trouble fitting it in
> with "Inclusion of a parent file by a file provides a shaky basis for
> inheritance." I guess you're saying you'd prefer a different way to
> indicate that the file relies on its parent.
>
The point is that there are different reasons why a file has to rely on its
parent.
Inclusion may be used to aggregate several pieces of a program. Judith's IDE is
the biggest example perhaps. The parts, ie included files, are not inheriting
anything, and they are hardly meant to be reusable, since the amount of
communication between branches and headquarters is large enough to defeat any
attempt at genericity. Such files are usually marked aspieces of a program using
comments. No need for back inclusion or warning here, its kludgy but harmless.
In other cases, inclusion is a device to enable access to common data and
methods, oops routines. There, an included file is intended to be included by
possibly several, different parent files. This is not exactly inheritance, since
the parent needs to know about its derived classes, oops files, but that's the
closest we can get so far. Such a file relies on another to include it. The
practice can be seen s enhancing reusability, and should be encouraged. Yet, back
inclusion forces to modify the included file (unless you wisely turn warnings
off).
So, back inclusion appears as added typing for either zero or slightly negative
outcome. It does not add any functionalit that I know of.
CChris
> I have two basic responses. First, we already have a method for indicating
> that you need something in another file: include. An implicit dependency
> is, to me, something that deserves a warning. Relying on other files to
> include you is wrong. For one thing, it's difficult to maintain.
>
> The situation may occur where the file is meant to be used in different
> circumstances. Euphoria has this, where it is initialized differently if
> it's the interpreter, translator or a bound or shrouded mode of operation.
> The file that relies on 'parent symbols' has some getters and setters,
> which other parts of the code can call to initialize the data. There
> is no implicit dependency, and it's quite easy to figure out how and
> where these initializations happen.
>
> Matt
20. Re: Weighing in on everything
CChris wrote:
>
> Matt Lewis wrote:
> >
> > Yes, I agree with this statement. I'm just having trouble fitting it in
> > with "Inclusion of a parent file by a file provides a shaky basis for
> > inheritance." I guess you're saying you'd prefer a different way to
> > indicate that the file relies on its parent.
> >
>
> The point is that there are different reasons why a file has to rely on its
> parent.
> Inclusion may be used to aggregate several pieces of a program. Judith's
> IDE is the biggest example perhaps. The parts, ie included files, are not
> inheriting anything, and they are hardly meant to be reusable, since the
> amount of communication between branches and headquarters is large
> enough to defeat any attempt at genericity. Such files are usually marked
> aspieces of a program using comments. No need for back inclusion or warning
> here, its kludgy but harmless.
In a large project, I would argue that adding those extra includes promotes
easier maintenance. Consider that "Judith's" IDE did not start off as her
project. Nor is she the only one who hacks on the code.
> In other cases, inclusion is a device to enable access to common data and
> methods, oops routines. There, an included file is intended to be included
> by possibly several, different parent files. This is not exactly
> inheritance, since the parent needs to know about its derived classes,
> oops files, but that's the closest we can get so far. Such a file relies
> on another to include it. The practice can be seen as enhancing reusability,
> and should be encouraged. Yet, back inclusion forces to modify the included
> file (unless you wisely turn warnings off).
I agree that 'back inclusion' (a nice term, BTW) is not always the correct
pattern to use. Take a look at mode.e from the euphoria source for an
example of an alternative. Previously, the constants initialized through
mode were put in the .ex files (int.ex, eu.ex, etc) and were utilized
throughout. Now they are initialized from these files, and the actual
constants declared in global.e (which pretty much everyone already
included).
> So, back inclusion appears as added typing for either zero or slightly
> negative outcome. It does not add any functionality that I know of.
I don't see how there's any negative here. One thing it does is protects
the file when using third party code. Suppose that a user of your library
combines it with another library that defines a global of the same name.
Now your library will break if the other library is included first.
We talked about walking back up that chain, but therein madness lies, I
think. The metric would likely get very complex, and certainly confusing
to developers, who wonder why otherwise functioning libraries break for
strange reasons.
I remain baffled as to why you think it's a good idea to use symbols in
files that you don't include. Maybe it's just me.
How do others feel about this?
Matt
21. Re: Weighing in on everything
Matt Lewis wrote:
>
> I remain baffled as to why you think it's a good idea to use symbols in
> files that you don't include. Maybe it's just me.
>
> How do others feel about this?
>
This is what your talking about right?
-- filea.e
global constant ABC = 10
-- fileb.e
include filea.e
global constant DEF = 20
-- myprog.e
include fileb.e
> DEF --- good
? ABC --- right here is "back inclusion?"
I don't like that idea of back inclusion. I think it has the potential to cause
a lot of unnecessary errors. I think if I want access to ABC, I should include
filea.e.
--
Jeremy Cowgar
http://jeremy.cowgar.com
22. Re: Weighing in on everything
Jeremy Cowgar wrote:
>
> I think if I want access to ABC, I should include filea.e.
I agree.
23. Re: Weighing in on everything
Matt Lewis wrote:
>
> CChris wrote:
> >
> > Matt Lewis wrote:
> > >
> > > Yes, I agree with this statement. I'm just having trouble fitting it in
> > > with "Inclusion of a parent file by a file provides a shaky basis for
> > > inheritance." I guess you're saying you'd prefer a different way to
> > > indicate that the file relies on its parent.
> > >
> >
> > The point is that there are different reasons why a file has to rely on its
> > parent.
> > Inclusion may be used to aggregate several pieces of a program. Judith's
> > IDE is the biggest example perhaps. The parts, ie included files, are not
> > inheriting anything, and they are hardly meant to be reusable, since the
> > amount of communication between branches and headquarters is large
> > enough to defeat any attempt at genericity. Such files are usually marked
> > aspieces of a program using comments. No need for back inclusion or warning
> > here, its kludgy but harmless.
>
> In a large project, I would argue that adding those extra includes promotes
> easier maintenance. Consider that "Judith's" IDE did not start off as her
> project. Nor is she the only one who hacks on the code.
>
My point here is that comments have specific functions, which there is no reason
to duplicate in active code. To say that those include statements are there
mainly "to promote easier maintenance" means exactly duplicating what proper
commenting in a large project should be used for. Specially when several people
coded at different times, as you oint out.
> > In other cases, inclusion is a device to enable access to common data and
> > methods, oops routines. There, an included file is intended to be included
> > by possibly several, different parent files. This is not exactly
> > inheritance, since the parent needs to know about its derived classes,
> > oops files, but that's the closest we can get so far. Such a file relies
> > on another to include it. The practice can be seen as enhancing reusability,
> > and should be encouraged. Yet, back inclusion forces to modify the included
> > file (unless you wisely turn warnings off).
>
> I agree that 'back inclusion' (a nice term, BTW) is not always the correct
> pattern to use. Take a look at mode.e from the euphoria source for an
> example of an alternative. Previously, the constants initialized through
> mode were put in the .ex files (int.ex, eu.ex, etc) and were utilized
> throughout. Now they are initialized from these files, and the actual
> constants declared in global.e (which pretty much everyone already
> included).
This woks for top level code, typically what's being used in initialisation. It
doesn't work as good for routines that may be called from anywhere in scope.
>
> > So, back inclusion appears as added typing for either zero or slightly
> > negative outcome. It does not add any functionality that I know of.
>
> I don't see how there's any negative here.
file1.e relies on a certain context to be usefully included. fileA.e and fileB.e
both provide such a context. Now,you'll have to change the statements in file1.e
according to whether filA.e, fileB.e or both include it. That's a clear negative.
> One thing it does is protects
> the file when using third party code. Suppose that a user of your library
> combines it with another library that defines a global of the same name.
> Now your library will break if the other library is included first.
>
This would be a side benefit of proper packaging, without the warnings or
negatives.
> We talked about walking back up that chain, but therein madness lies, I
> think. The metric would likely get very complex, and certainly confusing
> to developers, who wonder why otherwise functioning libraries break for
> strange reasons.
You lost me there.
CChris
>
> I remain baffled as to why you think it's a good idea to use symbols in
> files that you don't include. Maybe it's just me.
>
> How do others feel about this?
>
> Matt
24. Re: Weighing in on everything
Jeremy Cowgar wrote:
>
> Matt Lewis wrote:
> >
> > I remain baffled as to why you think it's a good idea to use symbols in
> > files that you don't include. Maybe it's just me.
> >
> > How do others feel about this?
> >
>
> This is what your talking about right?
No:
-- app.ex
global constant BAR = 1
include foo.e
-- foo.e
include app.ex
? BAR
The "include app.ex" is the "back inclusion." I contend that this is a
direct, simple and obvious way to indicate that foo.e intends to use
app.ex symbols. foo.e contains all of the context required to determine
where the symbols it uses come from, even if you encounter foo.e on its
own, you'll know that there's something missing.
But this isn't completely fool proof. Suppose we have:
-- app.ex
include bar.e
global constant BAR = 1
include foo.e
-- foo.e as f
include app.ex
? f:BAR
-- bar.e
global constant BAR = 2
Notice that we can still manage this, but we need to use a namespace in
foo.e. The resolution logic uses a symbol in the file with the declared
namespace in preference to one that's included by the file. In any case
this is likely all one project's code. A better way to do this might be:
-- app.ex
include bar.e
global constant BAR = 1
include foo.e
set_BAR( BAR )
foo()
-- foo.e as f
integer BAR
global procedure set_BAR( integer bar )
BAR = bar
end procedure
global procedure foo()
? BAR
end procedure
-- bar.e
global constant BAR = 2
Now, app.ex is using foo.e in what I'd describe as a more normal fashion.
Of course, another route would have been to stick the BAR constant
declaration in a separate file altogether, and let anyone interested
in using it just include that file.
> I don't like that idea of back inclusion. I think it has the potential to
> cause a lot of unnecessary errors. I think if I want access to ABC, I
> should include filea.e.
Here's why you want to allow this. Consider a large library like win32lib.
There are lots of files, and as a user, you may very well need to be able
to call some of those (think about the structure support). All you should
need to know is that you have to include win32lib.ew, and you can access
all of the goodness therein. If the developer decides to refactor, it
shouldn't matter to you, so long as those things you need to use are still
available.
However, currently, there is no way to stop the propagation of symbols from
win32lib support files that are meant to be internal to the library, though
not the file in which they reside. CChris, PeteL and I had some lengthy,
though inconclusive discussions a while back.
To boil them down simply, we each had a different implementation in mind,
and I'd characterize mine as the most minimalist, with Pete's next, and
then CChris'.
This is the next place that the namespace/symbol resolution of euphoria
needs to go.
Matt
25. Re: Weighing in on everything
CChris wrote:
>
> Matt Lewis wrote:
> >
> > In a large project, I would argue that adding those extra includes
> > promotes easier maintenance. Consider that "Judith's" IDE did not
> > start off as her project. Nor is she the only one who hacks on the
> > code.
> >
>
> My point here is that comments have specific functions, which there is no
> reason to duplicate in active code. To say that those include statements
> are there mainly "to promote easier maintenance" means exactly duplicating
> what proper commenting in a large project should be used for. Specially
> when several people coded at different times, as you point out.
I guess, but this is not too different from saying that commenting what
variables do is as good as using descriptive names. And good luck getting
those comments in the code. :)
> > I agree that 'back inclusion' (a nice term, BTW) is not always the
> > correct pattern to use. Take a look at mode.e from the euphoria source
> > for an example of an alternative. Previously, the constants initialized
> > through mode were put in the .ex files (int.ex, eu.ex, etc) and were
> > utilized throughout. Now they are initialized from these files, and the
> > actual constants declared in global.e (which pretty much everyone already
> > included).
>
> This woks for top level code, typically what's being used in initialisation.
> It doesn't work as good for routines that may be called from anywhere in
> scope.
I think this is an indication that you have poorly laid out your code.
Again, those globals should probably be moved to another file, where both
the top level and included file can include it.
> >
> > > So, back inclusion appears as added typing for either zero or slightly
> > > negative outcome. It does not add any functionality that I know of.
> >
> > I don't see how there's any negative here.
>
> file1.e relies on a certain context to be usefully included. fileA.e and
> fileB.e both provide such a context. Now,you'll have to change the
> statements in file1.e according to whether filA.e, fileB.e or both include
> it. That's a clear negative.
I'd reply the same as above. You've poorly modularized your code, and
should re-think it. Again, it's still possible to do this, but the
interpreter will warn you that you're doing something that can easily
go awry.
> > One thing it does is protects the file when using third party code.
> > Suppose that a user of your library combines it with another library
> > that defines a global of the same name. Now your library will break
> > if the other library is included first.
>
> This would be a side benefit of proper packaging, without the warnings or
> negatives.
Not always true. You assume that the intent was not to expose both of these
symbols. You're shipping code with a time bomb.
> > We talked about walking back up that chain, but therein madness lies, I
> > think. The metric would likely get very complex, and certainly confusing
> > to developers, who wonder why otherwise functioning libraries break for
> > strange reasons.
>
> You lost me there.
This relates to overriding globals and namespaces, and if there are multiple
matching symbols at some level of inclusion below the namespaced file,
should we attempt to measure how far down each is, and then use the higher
in preference to the lower. This idea was dumped pretty quickly.
Matt
26. Re: Weighing in on everything
- Posted by CChris <christian.cuvier at ag?iculture.?ouv.fr>
Apr 28, 2008
-
Last edited Apr 29, 2008
Matt Lewis wrote:
>
> CChris wrote:
> >
> > Matt Lewis wrote:
<snipped, as obviously we have different sort of coding in mind>
>
> > > We talked about walking back up that chain, but therein madness lies, I
> > > think. The metric would likely get very complex, and certainly confusing
> > > to developers, who wonder why otherwise functioning libraries break for
> > > strange reasons.
> >
> > You lost me there.
>
> This relates to overriding globals and namespaces, and if there are multiple
> matching symbols at some level of inclusion below the namespaced file,
> should we attempt to measure how far down each is, and then use the higher
> in preference to the lower. This idea was dumped pretty quickly.
>
Oh, ok.
The depth of a symbol up or down the tree shouldn't matter, because the shapes
of the third party libs are not under the app coder's control. However, I can see
quite a few cases where it would make sense to add symbols that come upstream, ie
in the parent file or higher.
CChris
> Matt
