1. RE: fixed windows
gertie at visionsix.com wrote:
> So the mirc nicklist and channel window are just fixed (but changeable
> and
> detachable) child windows in the parent ! That explains how it is
> possible to
> move each channel out of the mirc application screen and out onto the
> desktop. Just think where Eu would be now if RobC had merged Eu and mirc
>
> functionality way back when i first suggested it. Eu would look like
> Bach/Bliss/OpenEu/mIRC now. And beat the pants off everything out there.
Kat, I've seen your remarks about mIRC before and I don't get it.
As far as I can see mIRC is an application that handles the
IRC protocol. It has a build in interpreter to handle scripting
inside mIRC so all kind of stuff can be automated.
mIRC is definitely NOT a multi-purpose programming environment.
Having said that, I think it is very much possible to implement
IRC functionality with Euphoria, and creating a library that can
understand mIRC commands and run them as a Eu program should be
possible also (although I think it's a serious undertaking).
One thing should be clear: the functionality of mIRC (like what
can be done with it's windows) has nothing to do with mIRC's
scripting language. I'm not sure in what programming language
mIRC has been developed, but it is definitely not written in it's
own scripting language 
So I really don't understand what you mean by "merging Eu and
mIRC" ?! They are two completely different things. It's like
asking to merge Visual Basic (a language) with OpenOffice (as
a scriptable application).
Hans Peter Willems
2. RE: fixed windows
- Posted by gertie at visionsix.com
Aug 05, 2003
On 5 Aug 2003, at 18:12, Peter Willems wrote:
>
>
> gertie at visionsix.com wrote:
>
> > So the mirc nicklist and channel window are just fixed (but changeable
> > and
> > detachable) child windows in the parent ! That explains how it is
> > possible to
> > move each channel out of the mirc application screen and out onto the
> > desktop. Just think where Eu would be now if RobC had merged Eu and mirc
> >
> > functionality way back when i first suggested it. Eu would look like
> > Bach/Bliss/OpenEu/mIRC now. And beat the pants off everything out there.
>
> Kat, I've seen your remarks about mIRC before and I don't get it.
>
> As far as I can see mIRC is an application that handles the
> IRC protocol. It has a build in interpreter to handle scripting
> inside mIRC so all kind of stuff can be automated.
>
> mIRC is definitely NOT a multi-purpose programming environment.
Want a list of the language words and variables of mirc? Want a list of what
it can do that Eu can't?
> Having said that, I think it is very much possible to implement
> IRC functionality with Euphoria, and creating a library that can
> understand mIRC commands and run them as a Eu program should be
> possible also (although I think it's a serious undertaking).
Not terribly serious, other than the string execution mirc has. And being able
to override it's built-in commands. I wrote a 100% Eu bot, and you can find
the mirc-eu bot in the archives. The 100% Eu bot has no gui. The mirc-eu bot
has access to mirc's script engine and gui.
> One thing should be clear: the functionality of mIRC (like what
> can be done with it's windows) has nothing to do with mIRC's
> scripting language. I'm not sure in what programming language
> mIRC has been developed, but it is definitely not written in it's
> own scripting language
>
> So I really don't understand what you mean by "merging Eu and
> mIRC" ?! They are two completely different things. It's like
> asking to merge Visual Basic (a language) with OpenOffice (as
> a scriptable application).
In a word(s):
mirc:
1) executing strings
2) goto
3) threads (including threaded timers)
4) event handling
5) native socks support (you can http/telnet/pop3 with mirc too)
6) easy as heck gui support
7) no var instanciation required
8) no crash if a var has no contents in a boolean test
Bach:
9) classes
10) crash catching
11) gui support
12) block comments
13) slicing shorthands
14) better include paths
These 14 items are things BobC has said will not appear in Eu. The closest
app i have seen coded in Eu that might enable all the above is AGetz's
window server and Jiri's associated lists. And several string libs are required
in my opinion, string.e and strtok.e, and the file manipulation libs like
file.e,,
and for any windows gui, you must have win32lib. If RobC can't handle the
full developement of Eu, i refer you to my suggestion he hire Jiri, Cuny, and
Parnell (maybe paying them in futures, like stock).
Kat
3. RE: fixed windows
Hey Kat,
gertie at visionsix.com wrote:
<big snip>
> 1) executing strings
You might need it, I don't.
> 2) goto
Please no ! In my pov only hobby programmers need goto. That is
why many pro languages don't have it. There is nothing I can do
with goto that I can't already do without (but yes, you need to
do some "engineering" before starting to program).
> 3) threads (including threaded timers)
Agreed. Multi threading can help with several applications.
Nevertheless, the current tool we use in my company also don't
have multi-threading and still use it to develop for multi
nationals and to their satisfaction.
> 4) event handling
There is a full event-driven library in the archive.
> 5) native socks support (you can http/telnet/pop3 with mirc too)
I have no problem in it not being native. It's a library in most
other languages as well.
> 6) easy as heck gui support
Now here is where your comparison with mIRC goes completely wrong.
mIRC is a application with a userface that can be driven with it's
scripting language. That is com[pletely different from a language
that is USED to build that user interface (I already stated that
mIRC, including it's user interface, is not written in it's own
scripting language).
Let's be honest, there is no GUI developer in mIRC that generates
code that can then be executed without running mIRC's own FULL
user interface.
> 7) no var instanciation required
No comment on that.
> 8) no crash if a var has no contents in a boolean test
Ditto..
> Bach:
> 9) classes
I'm glad Euphoria is NOT object oriented in it's own design.
> 10) crash catching
Agreed. But that is not specific for mIRC OR Bach.
> 11) gui support
Don't know what Bach has over Eu in this regard.
> 12) block comments
We're discussing that in depth already, so you know my view on
that. Seems I'm not alone on this point either.
> 13) slicing shorthands
No idea what that's about 
> 14) better include paths
Clarify please ??
> These 14 items are things BobC has said will not appear in Eu. The
> closest
> app i have seen coded in Eu that might enable all the above is AGetz's
> window server and Jiri's associated lists. And several string libs are
> required
> in my opinion, string.e and strtok.e, and the file manipulation libs
> like file.e,,
> and for any windows gui, you must have win32lib.
That is your idea of how Eu should be developed, mine is different.
And other users might still have yet another pov. Don't forget
you are not the ONLY user.
> If RobC can't handle the full developement of Eu,
.... the way YOU think he should do it.... right ?
Kat, the bottom line is that I might (but shurely will) use Eu
for completely different tasks then you. And other people might
use it for yet completely different tasks. That is why Euphoria
is a GENERAL PURPOSE language while mIRC is a tool dedicated to
a very (VERY) specific application area.
Btw, Kat, have you aver heard of Erlang ? It's a language that
is developed by Ericson Telecom that seems to have everything
you desire in a language AND it is open source and completely
free. The proxy stuff you where asking for a while ago is easy
in Erlang as it has all that stuff build into the language.
You can get it at http://www.erlang.org
It's one of my choices for distributed tcp-based applications
and I'm going to make sure that my new IDE can handle Erlang as
well
Hans Peter Willems
4. RE: fixed windows
- Posted by gertie at visionsix.com
Aug 05, 2003
On 5 Aug 2003, at 14:06, gertie at visionsix.com wrote:
>
>
> On 5 Aug 2003, at 18:12, Peter Willems wrote:
>
> >
> > gertie at visionsix.com wrote:
> >
> > > So the mirc nicklist and channel window are just fixed (but changeable and
> > > detachable) child windows in the parent ! That explains how it is possible
> > > to move each channel out of the mirc application screen and out onto the
> > > desktop. Just think where Eu would be now if RobC had merged Eu and mirc
> > >
> > > functionality way back when i first suggested it. Eu would look like
> > > Bach/Bliss/OpenEu/mIRC now. And beat the pants off everything out there.
> >
> > Kat, I've seen your remarks about mIRC before and I don't get it.
> >
> > As far as I can see mIRC is an application that handles the
> > IRC protocol. It has a build in interpreter to handle scripting
> > inside mIRC so all kind of stuff can be automated.
> >
> > mIRC is definitely NOT a multi-purpose programming environment.
>
> Want a list of the language words and variables of mirc? Want a list of what
> it
> can do that Eu can't?
>
> > Having said that, I think it is very much possible to implement
> > IRC functionality with Euphoria, and creating a library that can
> > understand mIRC commands and run them as a Eu program should be
> > possible also (although I think it's a serious undertaking).
>
> Not terribly serious, other than the string execution mirc has. And being able
> to override it's built-in commands. I wrote a 100% Eu bot, and you can find
> the
> mirc-eu bot in the archives. The 100% Eu bot has no gui. The mirc-eu bot has
> access to mirc's script engine and gui.
>
>
> > One thing should be clear: the functionality of mIRC (like what
> > can be done with it's windows) has nothing to do with mIRC's
> > scripting language. I'm not sure in what programming language
> > mIRC has been developed, but it is definitely not written in it's
> > own scripting language
> >
> > So I really don't understand what you mean by "merging Eu and
> > mIRC" ?! They are two completely different things. It's like
> > asking to merge Visual Basic (a language) with OpenOffice (as
> > a scriptable application).
>
> In a word(s):
>
> mirc:
> 1) executing strings
> 2) goto
> 3) threads (including threaded timers)
> 4) event handling
> 5) native socks support (you can http/telnet/pop3 with mirc too)
> 6) easy as heck gui support
> 7) no var instanciation required
> 8) no crash if a var has no contents in a boolean test
>
> Bach:
> 9) classes
> 10) crash catching
> 11) gui support
> 12) block comments
> 13) slicing shorthands
> 14) better include paths
>
> These 14 items are things BobC has said will not appear in Eu. The closest app
> i
> have seen coded in Eu that might enable all the above is AGetz's window server
> and Jiri's associated lists. And several string libs are required in my
> opinion,
> string.e and strtok.e, and the file manipulation libs like file.e,, and for
> any
> windows gui, you must have win32lib. If RobC can't handle the full
> developement
> of Eu, i refer you to my suggestion he hire Jiri, Cuny, and Parnell (maybe
> paying them in futures, like stock).
I forgot, executing strings is rather like dynamic includes,, or re-including,
like Erlang. Yes, i know it's not the same, but either could be used as the
other if neither has restrictions in length or scope.
Kat
5. RE: fixed windows
- Posted by gertie at visionsix.com
Aug 05, 2003
On 5 Aug 2003, at 19:51, Peter Willems wrote:
>
>
> Hey Kat,
>
> gertie at visionsix.com wrote:
>
> <big snip>
>
> > 1) executing strings
>
> You might need it, I don't.
And you are saying since you don't need the option, i should be forced to do
without?
> > 2) goto
>
> Please no ! In my pov only hobby programmers need goto. That is
> why many pro languages don't have it. There is nothing I can do
> with goto that I can't already do without (but yes, you need to
> do some "engineering" before starting to program).
Yes, stop thinking of the program and it's flow, and engineer a workaround
that the programming language will allow.
> > 3) threads (including threaded timers)
>
> Agreed. Multi threading can help with several applications.
> Nevertheless, the current tool we use in my company also don't
> have multi-threading and still use it to develop for multi
> nationals and to their satisfaction.
So again, you don't need it, so i can't have it.
> > 4) event handling
>
> There is a full event-driven library in the archive.
Not quite what i wanted, i don't see it doing:
on error:*sequence lengths not equal*: { code here }
> > 5) native socks support (you can http/telnet/pop3 with mirc too)
>
> I have no problem in it not being native. It's a library in most
> other languages as well.
Sure, Eu has such libs also, and every one has drawbacks. You can do x in
one, but not in the other, whch can do y.
> > 6) easy as heck gui support
>
> Now here is where your comparison with mIRC goes completely wrong.
> mIRC is a application with a userface that can be driven with it's
> scripting language. That is com[pletely different from a language
> that is USED to build that user interface (I already stated that
> mIRC, including it's user interface, is not written in it's own
> scripting language).
And you think Eu is written in Euphoria?
> Let's be honest, there is no GUI developer in mIRC that generates
> code that can then be executed without running mIRC's own FULL
> user interface.
Wrong. You can generate child windows that have their own button in the
taskbar, move independantly of the main mirc window, etc.. Besides, i
WANT the full language available to me to run the code i write. The display,
in any font i can download, in any point size, in any color, at any point, with
full mouse support, is a plus.
> > 7) no var instanciation required
>
> No comment on that.
>
> > 8) no crash if a var has no contents in a boolean test
>
> Ditto..
By your previous tone, i suspect that means you are against them. So far,
you are against everything i suggest but threads. How unexpected.
> > Bach:
> > 9) classes
>
> I'm glad Euphoria is NOT object oriented in it's own design.
I don't actually like the way classes are in Bach, but it seems others do. I
want *full* variant records, with overriding.
> > 10) crash catching
>
> Agreed. But that is not specific for mIRC OR Bach.
It's possible to recover in mirc, to a point. For instance, i can type:
/msg cs addop nick 3
which is an error, and which i can script to correct before it finally errors
out.
> > 11) gui support
>
> Don't know what Bach has over Eu in this regard.
Size. Open source, for nix and winders.
> > 12) block comments
>
> We're discussing that in depth already, so you know my view on
> that. Seems I'm not alone on this point either.
>
> > 13) slicing shorthands
>
> No idea what that's about
I'm sure you won't like it, and will vote to keep it from me in Eu.
> > 14) better include paths
>
> Clarify please ??
Bach introduced looking in the application's own /include subdir, not just the
interpreter's /include subdir. And other places.
> > These 14 items are things BobC has said will not appear in Eu. The
> > closest
> > app i have seen coded in Eu that might enable all the above is AGetz's
> > window server and Jiri's associated lists. And several string libs are
> > required
> > in my opinion, string.e and strtok.e, and the file manipulation libs
> > like file.e,,
> > and for any windows gui, you must have win32lib.
>
> That is your idea of how Eu should be developed, mine is different.
> And other users might still have yet another pov. Don't forget
> you are not the ONLY user.
Golly, really? Are you the only one who matters then? If Robc includes goto,
you think throngs of mad programmers will descent on you next fullmoon and
force you to re-write all your code with goto?
> > If RobC can't handle the full developement of Eu,
>
> .... the way YOU think he should do it.... right ?
It's already apparent he is out of time, whether i say anything or not. I think
you are a great example of the pot calling the kettle black.
> Kat, the bottom line is that I might (but shurely will) use Eu
> for completely different tasks then you. And other people might
> use it for yet completely different tasks. That is why Euphoria
> is a GENERAL PURPOSE language while mIRC is a tool dedicated to
> a very (VERY) specific application area.
Mirc is hardly restricted to "a very (VERY) specific application area*. Just
because it has one screen format for irc does not mean it cannot just as
easily handle other tasks. What you are saying is like saying feet are for
walking with, and if you have no feet, you cannot move at all. Or feet should
not be used to play soccer with. Or hair should be worn the way you say,
and worn any other way is confusing.
Kat
6. RE: fixed windows
gertie at visionsix.com wrote:
<lots of previous stuff snipped>
> And you are saying since you don't need the option, i should be forced
> to do
> without?
> So again, you don't need it, so i can't have it.
> By your previous tone, i suspect that means you are against them. So
> far,
> you are against everything i suggest but threads. How unexpected.
> I'm sure you won't like it, and will vote to keep it from me in Eu.
> Golly, really? Are you the only one who matters then? If Robc includes
> goto,
> you think throngs of mad programmers will descent on you next fullmoon
> and
> force you to re-write all your code with goto?
Come on Kat, you behave like a little kid that doesn't get
her way of doing things. As I said in several posts before,
I don't mind if certain things would be implemented in Eu, as
long as it won't loose it's appeal to me. If it does, I'll simply
move on to another language. I've done that many times over the
last 22 years.
The point is that I DON'T diminish the actual quality of the
language as a usable development platform, just because there
are a few things not there yet. With all the languages that I
have used I was always waiting for something that I wanted
but it never stopped me from developing applications with them.
When I couldn't live any longer with certain shortcommings then
I moved to another platform. But I never said that the language
I left behind was no good at all, it was just not good for me.
> Yes, stop thinking of the program and it's flow, and engineer a
> workaround
> that the programming language will allow.
I'll repeat my point here: goto is not needed in a language
Maybe it helps to understand my pov when you know that I got
my programming education based on Pascal.
> And you think Eu is written in Euphoria?
I don't know with Eu, but many languages are indeed started
as a small sub-set interpreter and then further developed in
the actual language itself. The Python interpreter is largely
written in Python and most Java pre-compilers are indeed written
in..... yep, Java. This is actually where the term "bootstrapping"
comes from.
It's very well possible that Eu was developed in the same way.
> It's already apparent he is out of time, whether i say anything or not.
So how did he manage to release the last update then ?
> Mirc is hardly restricted to "a very (VERY) specific application area*.
> Just
> because it has one screen format for irc does not mean it cannot just as
>
> easily handle other tasks. What you are saying is like saying feet are
> for
> walking with, and if you have no feet, you cannot move at all. Or feet
> should
> not be used to play soccer with. Or hair should be worn the way you say,
>
> and worn any other way is confusing.
I really don't see my company developing enterprise solutions
with mIRC for our clients, but I can use Euphoria, Python,
Erlang, Modula, Pascal, Oberon, etc. fine for that.
These are all multi-purpose languages, mIRC is most certainly not.
Hans Peter Willems
8. RE: fixed windows
- Posted by gertie at visionsix.com
Aug 05, 2003
On 5 Aug 2003, at 21:44, Peter Willems wrote:
>
>
> gertie at visionsix.com wrote:
>
> <lots of previous stuff snipped>
>
> > And you are saying since you don't need the option, i should be forced
> > to do
> > without?
>
> > So again, you don't need it, so i can't have it.
>
> > By your previous tone, i suspect that means you are against them. So
> > far,
> > you are against everything i suggest but threads. How unexpected.
>
> > I'm sure you won't like it, and will vote to keep it from me in Eu.
You snipped telling me here that i am not the only one using Eu. As if i didn't
know that. The condescention and patronising bothered me more than
anything.
> > Golly, really? Are you the only one who matters then? If Robc includes
> > goto,
> > you think throngs of mad programmers will descent on you next fullmoon
> > and
> > force you to re-write all your code with goto?
>
> Come on Kat, you behave like a little kid that doesn't get
> her way of doing things.
And the way some people argue against an OPTION like goto in Eu is
bordering on pathological.
> As I said in several posts before,
> I don't mind if certain things would be implemented in Eu, as
> long as it won't loose it's appeal to me. If it does, I'll simply
> move on to another language. I've done that many times over the
> last 22 years.
Me too. Since 1979. Eu has the most promise to be the best (fast, easy to
learn and code in, most user options, and small footprint) language.
> > Yes, stop thinking of the program and it's flow, and engineer a
> > workaround
> > that the programming language will allow.
>
> I'll repeat my point here: goto is not needed in a language
> Maybe it helps to understand my pov when you know that I got
> my programming education based on Pascal.
Sure goto isn't needed. And sure i didn't mind stopping everything for an hour
the other nite to work out a while loop with new flag vars and some exit
statements, when a simple goto was all that was needed. I could have typed
hundreds of goto and got clear code, when now i have a cursed mess of exit
flags and loop controls. I wrote in Turbo Pascal for 6 yrs too.
> > And you think Eu is written in Euphoria?
>
> I don't know with Eu, but many languages are indeed started
> as a small sub-set interpreter and then further developed in
> the actual language itself. The Python interpreter is largely
> written in Python and most Java pre-compilers are indeed written
> in..... yep, Java. This is actually where the term "bootstrapping"
> comes from.
> It's very well possible that Eu was developed in the same way.
I doubt it. TP was bootstrapped this way. I have the source for TP5.
> > It's already apparent he is out of time, whether i say anything or not.
>
> So how did he manage to release the last update then ?
Late.
> > Mirc is hardly restricted to "a very (VERY) specific application area*.
> > Just
> > because it has one screen format for irc does not mean it cannot just as
> >
> > easily handle other tasks. What you are saying is like saying feet are
> > for
> > walking with, and if you have no feet, you cannot move at all. Or feet
> > should
> > not be used to play soccer with. Or hair should be worn the way you say,
> >
> > and worn any other way is confusing.
>
> I really don't see my company developing enterprise solutions
> with mIRC for our clients, but I can use Euphoria, Python,
> Erlang, Modula, Pascal, Oberon, etc. fine for that.
> These are all multi-purpose languages, mIRC is most certainly not.
Just because no one is using it for "enterprise" coding does not mean it
could not do the task. Jeeze, you are dissing it soley for haveing a built-in
irc
interface! Can you think outside the box at all? I remember when C was
called a dead language, when i was laughted at for wanting to use Python for
anything, yet now you say they are all "enterprise" languages. You know
what?,, i still say the moon orbits the earth, and i bet some on this list will
argue against that.
Kat
9. RE: fixed windows
gertie at visionsix.com wrote:
<snipped a lot of repeating stuff>
> Just because no one is using it for "enterprise" coding does not mean it
>
> could not do the task. Jeeze, you are dissing it soley for haveing a
> built-in irc
> interface!
I don't diss it because of it's built-in irc capabilities, I diss
it because it is seriously lacking in specific areas for enterprise
solution development. And even that is not diminishing the quality
of mIRC for what it's meant for..... but it was never meant to be
used to build enterprise solutions.
> Can you think outside the box at all? I remember when C was
> called a dead language, when i was laughted at for wanting to use Python
> for
> anything, yet now you say they are all "enterprise" languages.
They are because their feature set is aimed at writing such
applications. Is that so hard to grasp ?
There are specific languages for compiler construction, there are
specific languages for text-handling, there are specific languages
for CAD solutions, the list goes on..... non of these are usable
to write enterprise solutions as they are simply not meant for
that. And there are languages that ARE meant for enterprise
solutions. Maybe that Python wasn't there a few years ago, but
today it's scope for enterprise solutions is clear tmo.
> You know what?,, i still say the moon orbits the earth, and i bet some
> on this list will
> argue against that.
Probably.... but you can't win them all
Hans Peter Willems
10. RE: fixed windows
>Golly, really? Are you the only one who matters then? If Robc includes
>goto, you think throngs of mad programmers will descent on you next
>fullmoon and force you to re-write all your code with goto?
The problem with adding more features to the library is this: You may not
code it that way, and you may not want to deal with those extra features,
but a lot of programming is looking at other people's code in libraries, and
including them for your own program to use.
So while _you_ may not use the new features, you can still encounter them,
and have to work out exactly what the person was doing with their code. This
can be particularly difficult if the library has a heavy reliance on new
features.
=====================================================
my 0.02
.______<-------------------\__
/ _____<--------------------__|===
||_ <-------------------/
\__| Mr Trick
11. RE: fixed windows
> i still say the moon orbits the earth, and i bet some on
> this list will argue against that.
I don't know about that, but I am thinking about Uranus.
---
12. RE: fixed windows
- Posted by kbochert at copper.net
Aug 06, 2003
On 5 Aug 2003 at 14:06, gertie at visionsix.com wrote:
> > So I really don't understand what you mean by "merging Eu and
> > mIRC" ?! They are two completely different things. It's like
> > asking to merge Visual Basic (a language) with OpenOffice (as
> > a scriptable application).
>
> In a word(s):
>
> mirc:
> 1) executing strings
I have lately come to realize that this is not that hard in Bach.
Bach 2 has already laid the groundwork by changing the way source
is handled internally.
> 2) goto
This belongs in the group below as well.
for me, goto is essential in writing something like
thr interpreter. I have not once found a situation
in Bach where it would help.
> 3) threads (including threaded timers)
Bach 2 does have coroutines which allow cooperative
multitasking. Not quite the same thing, but its a start.
Another feature which I have lately realized is quite
doable is child processes:
child_exec("foo.exe -w")
would operate just like system_exec(), except that
the child process would have its stdio redirected
to the parent.
Is this old hat?
Is there a Eu library that does this?
> 4) event handling
You could write your program as an event loop that
calls a series of coroutines. One coroutine detects
events, another responds to them.
Still not pre-emptive but if you don't need realtime...
> 5) native socks support (you can http/telnet/pop3 with mirc too)
Bach will interface to TCP4U. Does this provide enuf?
> 6) easy as heck gui support
> 7) no var instanciation required
I have great difficulty with languages that allow this.
Having the data spelled out with declarations is
crucial to my understanding of that program.
> 8) no crash if a var has no contents in a boolean test
In Bach, variables that are part of a class are automatically
initialized, so a statement like:
if Cls.cnt = 0 then ...
will never crash
>
> Bach:
> 9) classes
Bach's classes are meant to provide a more powerful
procedural programming environment, not OO!
(I don't comprehend OO)
> 10) crash catching
> 11) gui support
I continue to be amazed at the short learning curve of IUP.
> 12) block comments
Seemed like a frill, but turned out to be very useful. Not only for
commenting out blocks, but also for documentation blocks.
> 13) slicing shorthands
When I started Bach, this was the first thing on my wish list.
Turns out to be less important than I thought.
> 14) better include paths
Changed a little in 2.0.
homedir, BACHLIB env var path, BACHDIR\user, BACHDIR\LIB
I was losing track of what was searched, so failure to find an
id displays all files which were tried.
>
> These 14 items are things BobC has said will not appear in Eu. The closest
> app i have seen coded in Eu that might enable all the above is AGetz's
> window server and Jiri's associated lists. And several string libs are
> required
> in my opinion, string.e and strtok.e, and the file manipulation libs like
> file.e,,
> and for any windows gui, you must have win32lib. If RobC can't handle the
> full developement of Eu, i refer you to my suggestion he hire Jiri, Cuny, and
> Parnell (maybe paying them in futures, like stock).
>
> Kat
>
> --^----------------------------------------------------------------
> This email was sent to: kbochert at copper.net
>
>
> TOPICA - Start your own email discussion group. FREE!
>
>
13. RE: fixed windows
> From: gertie at visionsix.com
> Subject: RE: fixed windows
>
>
>> <lots of previous stuff snipped>
[Even more snipping]
>
>> > Golly, really? Are you the only one who matters then? If Robc includes
>> > goto,
>> > you think throngs of mad programmers will descent on you next fullmoon
>> > and
>> > force you to re-write all your code with goto?
>
>>
>> Come on Kat, you behave like a little kid that doesn't get
>> her way of doing things.
>
>
> And the way some people argue against an OPTION like goto in Eu is
> bordering on pathological.
>
I also learnt programming in Pascal,and I fully share Derek's view that
goto means higher maintenance time and cost. You really end up with a
mess of flags to tell if you are coming at this spot in code from a oto
or from linear flow, and that's why I skipped goto in VB programming
fast and happy.
If speed is so critical that goto are needed, then these critical parts
of code are better written in C or ASM, so goto is pointless again.
But, since a multi-purpose language is used to write business-class
code as well as toy snippets by hobby programmers, why not include goto
in EU?
A possible answer: implementing goto means a lot of cleaning and flow
control code. This is my experience from implementing them in idEu, and
it means extra code being executed. If the source doesn't have goto
inside, the preprocessor still must do some extra work in case there is
one downstream. So, you may have to (slightly) pay for it even if you
don't use it. I don't share some people's harsh attitude against this,
but can understand it.
>
>> As I said in several posts before,
>> I don't mind if certain things would be implemented in Eu, as
>> long as it won't loose it's appeal to me. If it does, I'll simply
>> move on to another language. I've done that many times over the
>> last 22 years.
>
>
> Me too. Since 1979. Eu has the most promise to be the best (fast, easy to
> learn and code in, most user options, and small footprint) language.
>
Actually, apart from integration in Office apps, I don't see many
reasons to use VB rather than Eu (oh yes, the debugger). Yet the user
base for Eu is tiny compared to VB's. Guess why?
>
>> > Yes, stop thinking of the program and it's flow, and engineer a
>> > workaround
>> > that the programming language will allow.
>
>>
>> I'll repeat my point here: goto is not needed in a language
>> Maybe it helps to understand my pov when you know that I got
>> my programming education based on Pascal.
>
>
> Sure goto isn't needed. And sure i didn't mind stopping everything for an hour
>
> the other nite to work out a while loop with new flag vars and some exit
> statements, when a simple goto was all that was needed. I could have typed
> hundreds of goto and got clear code, when now i have a cursed mess of exit
> flags and loop controls. I wrote in Turbo Pascal for 6 yrs too.
>
Adding to my earlier statements about goto: what is sorely needed is
more flexible flow control, what I'd call structured or controlled goto.
For instance: exit one or more if blocks, exit one or more loops at a
time, possibly labelling them - this is a real bonus in maintenance-.
Scoped variables and nested routines would really help too. Wait for
next year...
>
>> > And you think Eu is written in Euphoria?
>
>>
>> I don't know with Eu, but many languages are indeed started
>> as a small sub-set interpreter and then further developed in
>> the actual language itself. The Python interpreter is largely
>> written in Python and most Java pre-compilers are indeed written
>> in..... yep, Java. This is actually where the term "bootstrapping"
>> comes from.
>> It's very well possible that Eu was developed in the same way.
>
>
> I doubt it. TP was bootstrapped this way. I have the source for TP5.
>
>
>> > It's already apparent he is out of time, whether i say anything or not.
>
>>
>> So how did he manage to release the last update then ?
>
>
> Late.
>
>
>> > Mirc is hardly restricted to "a very (VERY) specific application area*.
>> > Just
>> > because it has one screen format for irc does not mean it cannot just as
>> >
>> > easily handle other tasks. What you are saying is like saying feet are
>> > for
>> > walking with, and if you have no feet, you cannot move at all. Or feet
>> > should
>> > not be used to play soccer with. Or hair should be worn the way you say,
>> >
>> > and worn any other way is confusing.
>
>>
>> I really don't see my company developing enterprise solutions
>> with mIRC for our clients, but I can use Euphoria, Python,
>> Erlang, Modula, Pascal, Oberon, etc. fine for that.
>> These are all multi-purpose languages, mIRC is most certainly not.
>
>
> Just because no one is using it for "enterprise" coding does not mean it
> could not do the task. Jeeze, you are dissing it soley for haveing a built-in
> irc
> interface! Can you think outside the box at all? I remember when C was
> called a dead language, when i was laughted at for wanting to use Python for
> anything, yet now you say they are all "enterprise" languages. You know
> what?,, i still say the moon orbits the earth, and i bet some on this list
> will
> argue against that.
>
Matt recently remarked that the Eu user base seems mostly interested by
GUI building and hardly anything else. Since this is not your main use
for EU (/me not mine either), you don't get listened too much on this list.
<ad><h1>Join OE!</h1></ad>
> Kat
CChris
14. RE: fixed windows
Christian.CUVIER at agriculture.gouv.fr wrote:
> Actually, apart from integration in Office apps, I don't see many
> reasons to use VB rather than Eu (oh yes, the debugger). Yet the user
> base for Eu is tiny compared to VB's. Guess why?
Ermm........ marketing budget
> Adding to my earlier statements about goto: what is sorely needed is
> more flexible flow control, what I'd call structured or controlled goto.
>
> For instance: exit one or more if blocks, exit one or more loops at a
> time, possibly labelling them - this is a real bonus in maintenance-.
In WinDev there is a simple solution for this: return
When you have a procedure with deeply nested loops and
constructs, doing a return anywhere in that construct will
break you out of the construct and back to the point after
where the procedure was called.
> Matt recently remarked that the Eu user base seems mostly interested by
> GUI building and hardly anything else. Since this is not your main use
> for EU (/me not mine either), you don't get listened too much on this
> list.
I think that GUI building is important also, as we are living
in a world where desktop machines are running windowed user
environments. It is also the area where the supporting libraries
and such are still lacking. Mind you I don't say I want it
implemented inside Euphoria. As Eu is cross platform that would
bring a lot of dead overhead to the interpreter, and greatly
diminish the possible use because of differences between operating
systems.
Hans Peter Willems
15. RE: fixed windows
- Posted by kbochert at copper.net
Aug 06, 2003
On 6 Aug 2003 at 12:10, Christian.CUVIER at agriculture.gouv.fr wrote:
> > And the way some people argue against an OPTION like goto in Eu is
> > bordering on pathological.
> >
>
> I also learnt programming in Pascal,and I fully share Derek's view that
> goto means higher maintenance time and cost. You really end up with a
> mess of flags to tell if you are coming at this spot in code from a oto
> or from linear flow, and that's why I skipped goto in VB programming
> fast and happy.
Loops cause control to arrive at the end of the loop via any number of paths.
You end up by setting flags within the loop, so the following code can know
why the loop was exited.
> If speed is so critical that goto are needed, then these critical parts
> of code are better written in C or ASM, so goto is pointless again.
goto has nothing to do with speed. Its sole purpose is to express
control flow in a clearer way. When misused, it has great potential to
obfuscate code, but when well used it can clarify the designers intentions.
Many other features also have obfuscation potential (indeed there are
programmers who can misuse ANY feature).
I would much rather work on code that had an occaisional goto than
on code that was mis-indented.
> But, since a multi-purpose language is used to write business-class
> code as well as toy snippets by hobby programmers, why not include goto
> in EU?
> A possible answer: implementing goto means a lot of cleaning and flow
> control code. This is my experience from implementing them in idEu, and
> it means extra code being executed. If the source doesn't have goto
> inside, the preprocessor still must do some extra work in case there is
> one downstream. So, you may have to (slightly) pay for it even if you
> don't use it. I don't share some people's harsh attitude against this,
> but can understand it.
That can be a real problem. Thats why..
See below.
>
<snip>
> >
>
> Adding to my earlier statements about goto: what is sorely needed is
> more flexible flow control, what I'd call structured or controlled goto.
> For instance: exit one or more if blocks, exit one or more loops at a
> time, possibly labelling them - this is a real bonus in maintenance-.
> Scoped variables and nested routines would really help too. Wait for
> next year...
>
To quote from the Bach manual:
"Goto can only be used within a function or procedure, and it may
not jump out of that function or procedure. Jumping into a loop
is also prohibited"
>
> Matt recently remarked that the Eu user base seems mostly interested by
> GUI building and hardly anything else. Since this is not your main use
> for EU (/me not mine either), you don't get listened too much on this list.
> <ad><h1>Join OE!</h1></ad>
>
I have always felt that a big part of Eu's popularity was its
low-level ability -- run on dos, write console apps,
poke memory, etc.
Maybe not.
Regards
Karl Bochert
17. RE: fixed windows
Christian.CUVIER at agriculture.gouv.fr wrote:
<lots of snips>
> Actually, apart from integration in Office apps, I don't see many
> reasons to use VB rather than Eu (oh yes, the debugger). Yet the
> user base for Eu is tiny compared to VB's. Guess why?
In fact, you can't even use that (Office integration) as an argument any
more. It's really pretty simple to Automate Office apps using EuCOM
(see the archives).
> Matt recently remarked that the Eu user base seems mostly
> interested by GUI building and hardly anything else. Since this is
> not your main use for EU (/me not mine either), you don't get
> listened too much on this list.
> <ad><h1>Join OE!</h1></ad>
I think you must be referring to the post about the MicroEconomy. I
don't think I'd draw this conclusion. It's more that virtually every
app uses some sort of GUI, therefore, *everyone* needs them, and they
are very popular. It's just a lowest common denominator across most
programmers. OTOH, not everyone needs an elegant little library for the
Simplex Algorithm, but I just can't help myself but to download and vote
for cool things like this.
Matt Lewis
18. RE: fixed windows
kbochert at copper.net wrote:
> I have always felt that a big part of Eu's popularity was its
> low-level ability -- run on dos, write console apps, poke memory,
> etc. Maybe not.
I like the feeling that I can usually focus on an algorithm without
having to fight the language (at least more so than with other languages
I have tried). It largely has to do with the flexibility of the
datatypes, but also the clean, clear syntax.
Eu has enough low level abilities that I feel that I am able to do
anything I want to. Certainly some things are more difficult than they
would be with other languages, but I've had a lot of fun (not to mention
frustration) getting Eu to cooperate with COM, for example.
Matt Lewis
19. RE: fixed windows
- Posted by kbochert at copper.net
Aug 06, 2003
On 6 Aug 2003 at 11:27, Peter Willems wrote:
>
> > goto has nothing to do with speed. Its sole purpose is to express
> > control flow in a clearer way.
>
> How can you express control in a clearer way then without goto.
> I'm realy curious, maybe you can give an example.
>
Its very difficult to spell out actual code because it is quite rare
and tends to occur only in complex code.
As an example, a bytecode interpreter (EU's for instance), consists of
a while statement that contains a switch statement with maybe 200 cases.
Many of these are a page long (even when written with macros!) and
contain additional structures.
When, inside a for, inside a switch, inside a while, on page 36, I see
if ( x != 0 )
goto type_error;
I know immediately the programmers intentions.
It is as clear, concise and meaningful as 'get_cnt();'
would be.
The structured equvalent:
if ( x != 0 ) {
type_error = TRUE;
break;
}
Is more wordy, uses data-coupling (does anyone else
modify type_error?) and sprinkles error handling code
through-out the code. (Each nested loop checks the flag)
If I need to know what happens on type_error, it is
located in a single place.
Replace 50 'goto type_error's; and 'goto range_error;'s'
with the equivalent flags and structured code is a mess.
A compiler back end is very complex. It can be structured
to put the complexity in in-line code, or in macros, or in
objects, or in structures, but it remains hard to grasp.
The best solution always seems to be to handle some
of the detail with data structures, some with careful code
structure, some with macros, and some with a few
well-chosen goto's. (A C++ programmer would probably
add templates, classes etc. to that list).
I will admit that since adding goto to Bach, I have found not a
single case where I have wanted to use it. (But then I haven't
written a complex program with Bach, either)
> > When misused, it has great potential to
> > obfuscate code, but when well used it can clarify the designers
> > intentions.
>
> Again, I can't see how the designers intentions would be
> better clarified my means of using goto. In my little corner
> of the programming universe, the developers intentions are
> made visible by means of inline documentation... lot's of it
>
> And again, an example would be appreciated.
I have far too often seen complex code which is so well
clarified with sometimes incorrect comments, that only a few
lines of code remained on each page. This was just barely
acceptable when the code was correct, intolerable if it had
bugs. (Its also very! hard to erase a comment )
In-line comments can be invaluable, but they can also be a trap.
In-line comments that recapitulate the code are an abuse.
goto's can be easily abused, but in my experience,
incorrect comments and mis-indenting are far more serious
problems.
I think that Dijkstra has scared programmers enough that
they use goto verrry carefully.
Thats a lot of opinion, held for (I think) non-trivial reasons.
I care greatly about the clarity of code ( I rank it above
correctness! ) and my experience and taste tell me that goto
is useful in a few cases.
Karl Bochert
20. RE: fixed windows
Derek Parnell wrote:
>
>
> From: "Matt Lewis" <matthewwalkerlewis at yahoo.com>
> > I like the feeling that I can usually focus on an algorithm
> > without having to fight the language (at least more so than with
> > other languages I have tried). It largely has to do with the
> > flexibility of the datatypes, but also the clean, clear syntax.
>
> Wirth also developed Pascal because he felt that structured data
> was just as important as structure programming. He'd hate
> Euphoria's dynamically typed data structures. But I agree with you
> in that the fluid nature of Euphoria's datatypes makes so many
> coding problems just disappear. It would be nice if we could have
> both dynamically typed and statically typed data in the same
> language. There is a place for both.
I agree, and so, to a degree at least, does Rob (i.e., user-defined
types). It just doesn't go as far as many (most/all?) would like.
The two ideas I like are a more focused way to typecheck a variable and
structures (of Eu data, not memory mapped data). In fact, the second
would probably cover most cases where the first would be handy.
Matt Lewis
21. RE: fixed windows
kbochert at copper.net wrote:
<snipped a bit>
> Many of these are a page long (even when written with macros!) and
> contain additional structures.
> When, inside a for, inside a switch, inside a while, on page 36, I see
>
> if ( x != 0 )
> goto type_error;
> I know immediately the programmers intentions.
> It is as clear, concise and meaningful as 'get_cnt();'
> would be.
> The structured equvalent:
>
> if ( x != 0 ) {
> type_error = TRUE;
> break;
> }
How about this:
if ( x != 0 )
type_error()
break
As for readability it is the same as your first example.
The only difference is that the program will return to this
code so your break is processed here instead of where you
jumped to with the goto. And *that* is exavctly what I like:
I know from my version instantly that after executing the
type_error handler (or whatever) I will still return to this
specific place in the program's logic. That goes a long way
for maintainability. In your example with goto I'm forced to
check out the code that is actually handling the type_error
to see where it will lead me, while my concern was with the code
where type_error was called. Again, this also reflects largely
on how the program is modularized.
> If I need to know what happens on type_error, it is
> located in a single place.
Same with my example.
> Replace 50 'goto type_error's; and 'goto range_error;'s'
> with the equivalent flags and structured code is a mess.
... and not needed, even without a goto.
> A compiler back end is very complex. It can be structured
> to put the complexity in in-line code, or in macros, or in
> objects, or in structures, but it remains hard to grasp.
I'm doing a lot of (commercial) work on dynamically loaded
parsers. Such a parser does not implement a certain language,
but instead it can parse any language or structured file based
on a language description. This is even more complex then to have
the parser understand a fixed instruction set. So I do know a
little bit about this matter
> I will admit that since adding goto to Bach, I have found not a
> single case where I have wanted to use it. (But then I haven't
> written a complex program with Bach, either)
Just today I found that WinDev actually also has goto... after
working with that language in commercial development for several
years it shows how many times I have been wishing for goto...
... zero times
> I have far too often seen complex code which is so well
> clarified with sometimes incorrect comments, that only a few
> lines of code remained on each page. This was just barely
> acceptable when the code was correct, intolerable if it had
> bugs. (Its also very! hard to erase a comment )
I agree that sometimes people can get carried away with
commenting code. Documenting code with comments is as much
a skill as writing clean code.
> In-line comments can be invaluable, but they can also be a trap.
> In-line comments that recapitulate the code are an abuse.
So what do you think about inline comments that contain special
tags to load a document generator ?
In this case the inline documentation becomes the sole place
for documentation maintenance. I actually like that.
> goto's can be easily abused, but in my experience,
> incorrect comments and mis-indenting are far more serious
> problems.
As you say, *incorrect* comments are indeed.... incorrect.
But that is a bit stating the obvious.
> I think that Dijkstra has scared programmers enough that
> they use goto verrry carefully.
I'm curious how many people here on the list ever heard of him
Hans Peter Willems
