1. Homosequences - Start Again
Hi all
I wrote this (several times), but didn't send it.
“I've almost posted a few times lately, but pulled back because I think the
contributors should run the show. My own load of f/t non-programming job and p/t
accelerated Masters in CS make it hard to use my favourite language, and
impossible to contribute to the effort. Most of my Euphoria work is direct
programming for research and ad hoc purposes, but as a committed user, I'm
worried about where OpenEu is going. In particular, I think development is being
consistently discussed at too low a level. “Enhancements” seem to be limited to a
neat little function here, a little sugar there, which in 2 -3 years time will
look like a wounded body with band-aids all over it.
Take the latest discussion on arrays/lists, etc, and assume for the sake of
argument that a programming language is a user-computer interface that seeks to
map cognitive concepts to code as seamlessly as possible. Entities that contain
uniform data are common cognitive models, so we would like an easy way to declare
them. Entities with fixed, non-uniform data are also common real world
conceptions. String objects are also common. While we love the flexibility of
Euphorian sequences, often (as good programmers) we would like to constrain the
data within a sequence. At the moment, the method of doing that is to write a
series of quasi-boolean expressions within a type block, rather than to declare
the encapsulated data explicitly. I'd rather see our champions argue about this:-
Can Euphoria do better at mapping real-world concepts of data objects to code?
Than this:-
Should it be sequence of integer, or seq_of_ints, or list or array or .. who
cares?
If the solution were considered at a higher-level, it would be the sort of
enhancement that elevates the language to another plane – not just sugar. Note
that I'm not talking about OO. I'm talking about the way that everyone on this
list thinks about real-world objects, whether they admit it, or realise it, or
not. Rob observed that users don't often use the type construct. If you look at
all programmers, not just Euphorians, they use the type construct constantly,
although under other names and guises. So could it be that Euphorians don't use
it because its syntax doesn't reflect the way they think about the problem space?
Another completely different example. When a proposed new function is
discussed, the discussion starts with an implementation, someone else comes up
with a different implementation with different parameters and/or return values,
someone else starts talking at the machine-level about how fast it will be if you
run it in a million-fold loop, and someone else says it's all crap, etc, and each
person seems to have a proprietary interest in his own implementation or idea.
When a new function is proposed, the implementation shouldn't be relevant until
after it's decided to include it in the langauge. All that's required at the
decision stage is the function signature. Once that's agreed, everyone can engage
in friendly competition to decide how to implement it (with plagiarism
encouraged). I'm not saying this will avoid argument, but at least the argument
will be about the right things.”
I was going to go on with more examples, but since writing the above, the
discussion on homogeneous sequences, which are just a trivial subset of the
overall problem, has gone berserk. If the discussion were at a higher level, a
much broader range of solutions would be considered. Just as an example, a
declarative approach within type blocks reflects more how people think about
entities, and solves lots more problems than what's currently being discussed.
Each of the following declarative constructs does little more than translate
boolean expressions into simpler declarations:-
type integer_list( sequence x )
integer x[]
end type
type integer_matrix( sequence x )
sequence x[]
integer x[][]
end type
type customer( sequence x )
integer x[1] -- customer ID
sequence x[2] –- name
sequence x[3] –- address
sequence x[4] –- DOB
end type
OR
type customer( sequence x )
integer x[1]
sequence x[2..4]
end type
Aliasing can be accomodated in such type blocks without adding a single word to
the language.
type customer( sequence x )
integer x[1] .id –- I've assumed dot access, but it could also be
shorthand for a subscript constant
sequence x[2] .name –- but the alias is more sensitive – x[address][name]
should fail
sequence x[3] .address
end type
Once you accept a declarative shorthand for boolean expressions, the following
is equally intuitive:-
type ten_ints( sequence x )
length(x) = 10 – insert any boolean expression you want
end type
Since type blocks are just a series of boolean expressions, why not ASSUME that
in a declarative syntax? None of these examples offend core Euphorian principles.
You'd have to look twice to realise that they're illegal.
I put them forward primarily as an example of the broader approach I'm
advocating. If our champions approach the problems at a higher level, I think the
advances will not only be more significant, but alos more simple, since the idea
of cognitive mapping is by definition simple.
Cheers
Peter Robinson
2. Re: Homosequences - Start Again
Very interesting reading. Both the general comments and the concrete suggestion.
Cheers,
Salix
3. Re: Homosequences - Start Again
Well said...
I kind of like the idea of assuming statements in type constructs are boolean
expressions. It differentiates them more from other functions.
Plus I've been wondering about some kind of built-in to test whether all
elements of a sequence are a basic type (integer or sequence).
I don't know if I can discuss mapping "real-world concepts of data objects to
code" though. I'm not a CS guy, just a noisy hobbyist. Plus it seems to me that
most of the "big picture vision" stuff belongs to Rob.
--
A complex system that works is invariably found to have evolved from a simple
system that works.
--John Gall's 15th law of Systemantics.
"Premature optimization is the root of all evil in programming."
--C.A.R. Hoare
j.
4. Re: Homosequences - Start Again
I definitely agree with your comments and am sometimes bewildered as you are by
the way development is being handled and what are the discussed issues. More
detail follows.
Peter Robinson wrote:
>
> Hi all
>
> I wrote this (several times), but didn't send it.
>
> “I've almost posted a few times lately, but pulled back because I think the
> contributors should run the show. My own load of f/t non-programming job and
> p/t accelerated Masters in CS make it hard to use my favourite language, and
> impossible to contribute to the effort. Most of my Euphoria work is direct
> programming
> for research and ad hoc purposes, but as a committed user, I'm worried about
> where OpenEu is going. In particular, I think development is being
> consistently
> discussed at too low a level. “Enhancements” seem to be limited to a neat
> little
> function here, a little sugar there, which in 2 -3 years time will look like
> a wounded body with band-aids all over it.
The only consistent plan I see in the discussions is: hey, don't change
anything. Otherwise, as you say, it's just a collection of individual needs which
are more or less shared. Trying to discuss things at a higher level elicits a
"too complicated" response, which is almost equivalent to a death sentence on the
topic being considered any further. I've never seen this "too complicated" thing
anywhere else.
As I have said in the past, one of the main issues is that there is a small
group of say 20 regular posters (often quite less) at any given time. How this
group is representative of the hopefully larger user community is a mystery. In
theory, Rob may have clues - if any feedback is emailed, it will be at RDS.
>
> Take the latest discussion on arrays/lists, etc, and assume for the sake of
> argument that a programming language is a user-computer interface that seeks
> to map cognitive concepts to code as seamlessly as possible. Entities that
> contain
> uniform data are common cognitive models, so we would like an easy way to
> declare
> them. Entities with fixed, non-uniform data are also common real world
> conceptions.
> String objects are also common. While we love the flexibility of Euphorian
> sequences,
> often (as good programmers) we would like to constrain the data within a
> sequence.
> At the moment, the method of doing that is to write a series of quasi-boolean
> expressions within a type block, rather than to declare the encapsulated data
> explicitly. I'd rather see our champions argue about this:-
>
> Can Euphoria do better at mapping real-world concepts of data objects to code?
Euphoria was designed as the fastest possible interpreter - makes sense on 40MHz
machines, perhaps less today. It was designed for the installer to fit on a
floppy, but machines may no longer have a floppy drive today.
Consistency with "business models", or user's native task/problem
representation, is quite absent - except when that model happen to match the
heterogeneous sequence pattern -. What matters is less many keywords and thinner
docs, it seems.
>
> Than this:-
>
> Should it be sequence of integer, or seq_of_ints, or list or array or .. who
> cares?
>
> If the solution were considered at a higher-level, it would be the sort of
> enhancement
> that elevates the language to another plane – not just sugar.
150% agreed.
> Note that I'm
> not talking about OO. I'm talking about the way that everyone on this list
> thinks
> about real-world objects, whether they admit it, or realise it, or not. Rob
> observed that users don't often use the type construct. If you look at all
> programmers,
> not just Euphorians, they use the type construct constantly, although under
> other names and guises. So could it be that Euphorians don't use it because
> its syntax doesn't reflect the way they think about the problem space?
>
> Another completely different example. When a proposed new function is
> discussed,
> the discussion starts with an implementation, someone else comes up with a
> different
> implementation with different parameters and/or return values, someone else
> starts talking at the machine-level about how fast it will be if you run it
> in a million-fold loop, and someone else says it's all crap, etc, and each
> person
> seems to have a proprietary interest in his own implementation or idea.
You forgot adding that then the discussion dies without any decision being
recorded.
> When
> a new function is proposed, the implementation shouldn't be relevant until
> after
> it's decided to include it in the langauge. All that's required at the
> decision
> stage is the function signature. Once that's agreed, everyone can engage in
> friendly competition to decide how to implement it (with plagiarism
> encouraged).
> I'm not saying this will avoid argument, but at least the argument will be
> about
> the right things.”
>
> I was going to go on with more examples, but since writing the above, the
> discussion
> on homogeneous sequences, which are just a trivial subset of the overall
> problem,
> has gone berserk. If the discussion were at a higher level, a much broader
> range
> of solutions would be considered. Just as an example, a declarative approach
> within type blocks reflects more how people think about entities, and solves
> lots more problems than what's currently being discussed. Each of the
> following
> declarative constructs does little more than translate boolean expressions
> into
> simpler declarations:-
>
> type integer_list( sequence x )
> integer x[]
> end type
>
> type integer_matrix( sequence x )
> sequence x[]
> integer x[][]
> end type
>
> type customer( sequence x )
> integer x[1] -- customer ID
> sequence x[2] –- name
> sequence x[3] –- address
> sequence x[4] –- DOB
> end type
>
> OR
>
> type customer( sequence x )
> integer x[1]
> sequence x[2..4]
> end type
>
> Aliasing can be accomodated in such type blocks without adding a single word
> to the language.
>
> type customer( sequence x )
> integer x[1] .id –- I've assumed dot access, but it could also be
> shorthand
> for a subscript constant
> sequence x[2] .name –- but the alias is more sensitive –
> x[address][name]
> should fail
> sequence x[3] .address
> end type
>
> Once you accept a declarative shorthand for boolean expressions, the following
> is equally intuitive:-
>
> type ten_ints( sequence x )
> length(x) = 10 – insert any boolean expression you want
> end type
>
> Since type blocks are just a series of boolean expressions, why not ASSUME
> that
> in a declarative syntax? None of these examples offend core Euphorian
> principles.
> You'd have to look twice to realise that they're illegal.
Agreed, except that types are predicates in the current state of the language,
so I'd use "structure" instead of "type". Oops, another keyword - won't fly.
> I put them forward primarily as an example of the broader approach I'm
> advocating.
> If our champions approach the problems at a higher level, I think the advances
> will not only be more significant, but alos more simple, since the idea of
> cognitive
> mapping is by definition simple.
Not only that, but it speeds up development because a/ coding is more
straightforward and b/ bugs are less likely, since they very often come from a
discrepancy between the coder's mind and the language set of text to executable
rules. I have raised this sort of issues before in an invariably lonely way.
CChris
>
> Cheers
> Peter Robinson
5. Re: Homosequences - Start Again
Peter Robinson wrote:
>
> My own load of f/t non-programming job and
> p/t accelerated Masters in CS make it hard
> to use my favorite language,and impossible
> to contribute to the effort.
They're giving Masters degrees in Counter-strike?!?! OMG! Sign me up! I
totally PWN at that game.
6. Re: Homosequences - Start Again
CChris wrote:
> I have raised
> this sort of issues before in an invariably lonely way.
lol ... you are still a new kid on the block ...
Some have been suggesting significant changes for a long time.
eg. http://www.users.bigpond.com/ddparnell/euphoria/product.htm
Peter's views are old news.
It used to be "Nothing ever changes, well not in a hurry anyway." but now there
is real potential for Euphoria to get back on track with the modern needs of
developers.
--
Derek Parnell
Melbourne, Australia
Skype name: derek.j.parnell
7. Re: Homosequences - Start Again
Peter Robinson wrote:
> Rob observed that users don't often use the type construct.
> If you look at all programmers, not just Euphorians,
> they use the type construct constantly, although under
> other names and guises.
In most other languages you *have* to pre-declare all your data
in order to do anything with it. You can't build arrays,
stacks, queues, trees, strings, structures, arrays of strings,
arrays of floating-point numbers, or anything else *without* using types.
> So could it be that Euphorians
> don't use it because its syntax doesn't reflect the way
> they think about the problem space?
In Euphoria, you are free to declare all variables as "object"
if you like. It doesn't prevent you from building and using
any kind of interesting data structure.
Most Euphoria programmers will use the pre-declared types
"integer" or "sequence" or "atom", where appropriate,
rather than "object". They don't mind doing that.
Few or no extra keystrokes.
However, creating a user-defined type is not necessary
for getting the job done, so why bother?
Types can help catch bugs, but debugging is already
pretty easy, given all the other run-time error checks.
Types also document your variables better, but so do comments,
another feature you are free to ignore.
Another issue, is that checking a sequence for
type conformance of all elements, is currently O(n),
so it's generally more expensive than it's worth.
That's why types are not used as much in Euphoria.
The recently proposed enhancement would greatly
alleviate the O(n) problem, (as well as helping the
Translator to generate somewhat faster C code).
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
8. Re: Homosequences - Start Again
- Posted by Robert Craig <rds at Rapi?Euphor?a.com>
Aug 16, 2007
-
Last edited Aug 17, 2007
CChris wrote:
> The only consistent plan I see in the discussions is: hey, don't change
> anything.
> Otherwise, as you say, it's just a collection of individual needs which are
> more or less shared. Trying to discuss things at a higher level elicits a "too
> complicated" response, which is almost equivalent to a death sentence on the
> topic being considered any further. I've never seen this "too complicated"
> thing
> anywhere else.
What other forums do you participate in,
where things are very different?
> As I have said in the past, one of the main issues is that there is a small
> group of say 20 regular posters (often quite less) at any given time. How this
> group is representative of the hopefully larger user community is a mystery.
> In theory, Rob may have clues - if any feedback is emailed, it will be at RDS.
When I was still getting registrations, 80-90% of the people
who registered were people who had never posted a single message
on EUforum. These days I still get email from people who never post here.
However, I now have less of an idea of how many users there are "out there".
Most people are not keenly interested in language design,
or even if they are, they don't feel qualified to comment
on ideas put forward by people who have been using Euphoria
for many years, have gone through the source code, etc.
Most people do not have problems in using a relatively
simple language like Euphoria, that require
clarification on this forum (assuming they even have
the required English skills to post).
> Euphoria was designed as the fastest possible interpreter
True to some extent.
> - makes sense on 40MHz machines, perhaps less today.
People will always value performance, perhaps not in an
individual program, but when deciding what language
to invest their time in.
The first PC that I ran Euphoria on was a 486 50 MHz machine.
When that machine first came out, I remember reading an
article that speculated that only professionals in certain areas,
and other "power users" would ever need that kind of speed.
With faster machines and huge memories, you could also argue
that fewer will use C/C++, and more will want something easier
to learn and debug with, like Euphoria.
> It was designed for the installer to fit on a
> floppy,
Not true.
> but machines may no longer have a floppy drive today.
> Consistency with "business models", or user's native task/problem
> representation,
> is quite absent - except when that model happen to match the heterogeneous
> sequence
> pattern -. What matters is less many keywords and thinner docs, it seems.
One of the main goals, was to make a simpler language
that amateurs, hobbyists etc. could easily learn and use.
It was never my intention to compete against C++ and Microsoft
in the professional arena.
> > If the solution were considered at a higher-level, it would be the sort of
> > enhancement
> > that elevates the language to another plane – not just sugar.
>
> 150% agreed.
Then propose something that will truely take Euphoria "to a higher plane".
> > Another completely different example. When a proposed new function is
> > discussed,
> > the discussion starts with an implementation, someone else comes up with a
> > different
> > implementation with different parameters and/or return values, someone else
> > starts talking at the machine-level about how fast it will be if you run it
> > in a million-fold loop, and someone else says it's all crap, etc, and each
> > person
> > seems to have a proprietary interest in his own implementation or idea.
>
> You forgot adding that then the discussion dies without any decision being
> recorded.
OK, from now on, I think anyone who is serious about a proposal
should eventually, after a period of discussion and analysis,
write a summary of his/her (revised) proposal, and call for a vote.
People can vote by posting a message here.
Voters should clearly say "Yes" or "No", and can give
an optional, very brief (one or two sentence)
reason for their vote.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
9. Re: Homosequences - Start Again
- Posted by CChris <christian.cuvier at agr?culture.?ouv.fr>
Aug 16, 2007
-
Last edited Aug 17, 2007
Robert Craig wrote:
>
> CChris wrote:
> > The only consistent plan I see in the discussions is: hey, don't change
> > anything.
> > Otherwise, as you say, it's just a collection of individual needs which are
> > more or less shared. Trying to discuss things at a higher level elicits a
> > "too
> > complicated" response, which is almost equivalent to a death sentence on the
> > topic being considered any further. I've never seen this "too complicated"
> > thing
> > anywhere else.
>
> What other forums do you participate in,
> where things are very different?
>
Eiffel, FreePascal, to quote the ones I'm currently browsing or on which I post.
I still have to look at the D thing as well, I wish I did it earlier.
> > As I have said in the past, one of the main issues is that there is a small
> > group of say 20 regular posters (often quite less) at any given time. How
> > this
> > group is representative of the hopefully larger user community is a mystery.
> > In theory, Rob may have clues - if any feedback is emailed, it will be at
> > RDS.
>
> When I was still getting registrations, 80-90% of the people
> who registered were people who had never posted a single message
> on EUforum. These days I still get email from people who never post here.
> However, I now have less of an idea of how many users there are "out there".
>
> Most people are not keenly interested in language design,
> or even if they are, they don't feel qualified to comment
> on ideas put forward by people who have been using Euphoria
> for many years, have gone through the source code, etc.
>
> Most people do not have problems in using a relatively
> simple language like Euphoria, that require
> clarification on this forum (assuming they even have
> the required English skills to post).
>
Very true. However, they can tell you if they are happy with it, not to tell you
if they are not, and ask naive questions which could help you in future
decisions. As I said, if anyone has clue, it should be RDS for obvious reasons.
> > Euphoria was designed as the fastest possible interpreter
>
> True to some extent.
And it has succeeded in that area.
>
> > - makes sense on 40MHz machines, perhaps less today.
>
> People will always value performance, perhaps not in an
> individual program, but when deciding what language
> to invest their time in.
>
> The first PC that I ran Euphoria on was a 486 50 MHz machine.
> When that machine first came out, I remember reading an
> article that speculated that only professionals in certain areas,
> and other "power users" would ever need that kind of speed.
>
> With faster machines and huge memories, you could also argue
> that fewer will use C/C++, and more will want something easier
> to learn and debug with, like Euphoria.
>
Some people at M$ assumed that 640kb was well above the ordinary user's need 
People will always value performance. Except that, when speed becomes high
enough, performance is no longer an issue in 80% of cases and other aspects may
come into play. You hardly care if some routine takes 2200 or 640 nanoseconds,
except when you call it in a loop. And people critically in need of speed will
use a lower level language anyway, be it C or assembly. This is why I am not 100%
sure that, for non CPU intensive code, cutting edge performance in Euphoria is as
important as it was 10-15 years ago. Even more so now that the Translator is
public.
> > It was designed for the installer to fit on a
> > floppy,
>
> Not true.
Did I dream this up? I'll check the "propaganda" texts...
>
> > but machines may no longer have a floppy drive today.
> > Consistency with "business models", or user's native task/problem
> > representation,
> > is quite absent - except when that model happen to match the heterogeneous
> > sequence
> > pattern -. What matters is less many keywords and thinner docs, it seems.
>
> One of the main goals, was to make a simpler language
> that amateurs, hobbyists etc. could easily learn and use.
> It was never my intention to compete against C++ and Microsoft
> in the professional arena.
>
Nor mine, although I think Eu could be easily far better, the potential is
there. And the "easy to use part" is debatable in some areas. EuForum is full of
detailed accounts about them.
> > > If the solution were considered at a higher-level, it would be the sort of
> enhancement</font></i>
> > > that elevates the language to another plane – not just sugar.
> >
> > 150% agreed.
>
> Then propose something that will truely take Euphoria "to a higher plane".
>
* Check how the type system could accommodate a couple "machine" types to speed
up a variety of things.
* Design a fully integrated scoping system which makes the promise of modular
programming in Eu come true, without leaving supposedly corner cases that
supposedly no one will ever need.
* Start considering a reentrant front end/backend pair, so as to allow a variety
of dynamic constructs which are expected from an interpreted language, and
probably reduce the load time of large (GUI) programs as well;
* Start investigating the possibility of plugin systems, in applications first
(perhaps using conditional include statements), then if possible in the language
itself. This will allow those who like it bare bones to have it bare bones, and
those who like it cheesier to have it too. Instead of adjusting your learning
curve to the language, adjust the language to your learning curve.
* Upgrade to decent debugging facilities, featuring dynamic breakpoints and
expression watch most urgently.
Just some ideas I have/have started to work on, there are probably many more
useful things to do. For the most part, they can hardly be one man's spare time
projects. Open cooperation would be critically needed.
> > > Another completely different example. When a proposed new function is
> > > discussed,
> > > the discussion starts with an implementation, someone else comes up with a
> > > different
> > > implementation with different parameters and/or return values, someone
> > > else
> > > starts talking at the machine-level about how fast it will be if you run
> > > it
> > > in a million-fold loop, and someone else says it's all crap, etc, and each
> > > person
> > > seems to have a proprietary interest in his own implementation or idea.
> >
> > You forgot adding that then the discussion dies without any decision being
> > recorded.
>
> OK, from now on, I think anyone who is serious about a proposal
> should eventually, after a period of discussion and analysis,
> write a summary of his/her (revised) proposal, and call for a vote.
>
> People can vote by posting a message here.
> Voters should clearly say "Yes" or "No", and can give
> an optional, very brief (one or two sentence)
> reason for their vote.
>
Thanks! That's certainly a good thing to do.
CChris
> Regards,
> Rob Craig
> Rapid Deployment Software
> <a href="http://www.RapidEuphoria.com">http://www.RapidEuphoria.com</a>
10. Re: Homosequences - Start Again
- Posted by Bernie Ryan <xotron at b?uefrog?com>
Aug 16, 2007
-
Last edited Aug 17, 2007
Robert Craig wrote:
>
> CChris wrote:
> > The only consistent plan I see in the discussions is: hey, don't change
> > anything.
> > Otherwise, as you say, it's just a collection of individual needs which are
> > more or less shared. Trying to discuss things at a higher level elicits a
> > "too
> > complicated" response, which is almost equivalent to a death sentence on the
> > topic being considered any further. I've never seen this "too complicated"
> > thing
> > anywhere else.
>
> What other forums do you participate in,
> where things are very different?
>
> > As I have said in the past, one of the main issues is that there is a small
> > group of say 20 regular posters (often quite less) at any given time. How
> > this
> > group is representative of the hopefully larger user community is a mystery.
> > In theory, Rob may have clues - if any feedback is emailed, it will be at
> > RDS.
>
> When I was still getting registrations, 80-90% of the people
> who registered were people who had never posted a single message
> on EUforum. These days I still get email from people who never post here.
> However, I now have less of an idea of how many users there are "out there".
>
> Most people are not keenly interested in language design,
> or even if they are, they don't feel qualified to comment
> on ideas put forward by people who have been using Euphoria
> for many years, have gone through the source code, etc.
>
> Most people do not have problems in using a relatively
> simple language like Euphoria, that require
> clarification on this forum (assuming they even have
> the required English skills to post).
>
> > Euphoria was designed as the fastest possible interpreter
>
> True to some extent.
>
> > - makes sense on 40MHz machines, perhaps less today.
>
> People will always value performance, perhaps not in an
> individual program, but when deciding what language
> to invest their time in.
>
> The first PC that I ran Euphoria on was a 486 50 MHz machine.
> When that machine first came out, I remember reading an
> article that speculated that only professionals in certain areas,
> and other "power users" would ever need that kind of speed.
>
> With faster machines and huge memories, you could also argue
> that fewer will use C/C++, and more will want something easier
> to learn and debug with, like Euphoria.
>
> > It was designed for the installer to fit on a
> > floppy,
>
> Not true.
>
> > but machines may no longer have a floppy drive today.
> > Consistency with "business models", or user's native task/problem
> > representation,
> > is quite absent - except when that model happen to match the heterogeneous
> > sequence
> > pattern -. What matters is less many keywords and thinner docs, it seems.
>
> One of the main goals, was to make a simpler language
> that amateurs, hobbyists etc. could easily learn and use.
> It was never my intention to compete against C++ and Microsoft
> in the professional arena.
>
> > > If the solution were considered at a higher-level, it would be the sort of
> enhancement</font></i>
> > > that elevates the language to another plane – not just sugar.
> >
> > 150% agreed.
>
> Then propose something that will truely take Euphoria "to a higher plane".
>
> > > Another completely different example. When a proposed new function is
> > > discussed,
> > > the discussion starts with an implementation, someone else comes up with a
> > > different
> > > implementation with different parameters and/or return values, someone
> > > else
> > > starts talking at the machine-level about how fast it will be if you run
> > > it
> > > in a million-fold loop, and someone else says it's all crap, etc, and each
> > > person
> > > seems to have a proprietary interest in his own implementation or idea.
> >
> > You forgot adding that then the discussion dies without any decision being
> > recorded.
>
> OK, from now on, I think anyone who is serious about a proposal
> should eventually, after a period of discussion and analysis,
> write a summary of his/her (revised) proposal, and call for a vote.
>
> People can vote by posting a message here.
> Voters should clearly say "Yes" or "No", and can give
> an optional, very brief (one or two sentence)
> reason for their vote.
>
Rob:
I agree 100% with this.
It seems that some users come along and are always trying to
push the langauge away from its orginal purpose.
I chose to use Euphoria because of it's simplicity and ease of use.
I often see user's objecting to the way the langauge works.
Then I look in the archive to see what programs they have written
and I find a couple of small simple programs that don't require
any extra features or special skill to write.
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
