1. New Euphoria features
I'm curious about the direction that Euphoria might be taking in the future.
Does Robert Craig maintain a list of features that he's thinking of adding to
future releases?
Brent
2. Re: New Euphoria features
On Mon, 21 Feb 2005 19:13:54 -0800, Brent W. Hughes
<guest at rapideuphoria.com> wrote:
> I'm curious about the direction that Euphoria might be taking in the future.
> Does Robert
> Craig maintain a list of features that he's thinking of adding to future
> releases?
Not one that is publically accessible, or that users can give feedback on.
--
MrTrick
3. Re: New Euphoria features
IF I'm so lucky, I would wish for the following features;
#1;
Select Case
Case .. or ..
Case Else
end Select
I hate having to use IF / ELSIF in this case.
#2;
100% object oriented? :D
#3;
AND the ability make references to source files in order to 'build' a
complete main source code for compiling/running; IE,
-- CODE.
#INSERT c:\euphoria\source\myFunction.txt
-- MORE CODE.
#INSERT c:\euphoria\source\myProcedure.txt
-- EVEN MORE CODE.
This should load the 2 textfiles into the main source code and THEN
execute it. You might say - why not use include?? Well, sometimes
the code have to be at a specifc position in the source, and it might
be large and give a poor overview over the main code. In that case I
would cut it out - put it in an own separate file and just refer to
it as shown above. Some might say this is messy, and that might be true
too, but it's something I'd like to see in Euphoria.
Kenneth aka ZNorQ
Brent W. Hughes wrote:
>
> I'm curious about the direction that Euphoria might be taking in the future.
> Does
> Robert Craig maintain a list of features that he's thinking of adding to
> future releases?
>
> Brent
>
4. Re: New Euphoria features
ZNorQ wrote:
> IF I'm so lucky, I would wish for the following features;
<snip>
> #3;
> AND the ability make references to source files in order to 'build' a
> complete main source code for compiling/running; IE,
>
> -- CODE.
> #INSERT c:\euphoria\source\myFunction.txt
> -- MORE CODE.
> #INSERT c:\euphoria\source\myProcedure.txt
> -- EVEN MORE CODE.
>
> This should load the 2 textfiles into the main source code and THEN
> execute it. You might say - why not use include?? Well, sometimes
> the code have to be at a specifc position in the source, and it might
> be large and give a poor overview over the main code. In that case I
> would cut it out - put it in an own separate file and just refer to
> it as shown above. Some might say this is messy, and that might be true
> too, but it's something I'd like to see in Euphoria.
>
> Kenneth aka ZNorQ
You can already do this, using the insert command of my preprocessor
EuKa <http://www.rapideuphoria.com/euka.zip>. It would look like this:
-- CODE.
~$c:\euphoria\source\myFunction.txt~
-- MORE CODE.
~$c:\euphoria\source\myProcedure.txt~
-- EVEN MORE CODE.
Regards,
Juergen
5. Re: New Euphoria features
- Posted by D. Newhall <derek_newhall at yahoo.com>
Feb 23, 2005
-
Last edited Feb 24, 2005
ZNorQ wrote:
>
> IF I'm so lucky, I would wish for the following features;
>
> #1;
> Select Case
> Case .. or ..
> Case Else
> end Select
>
> I hate having to use IF / ELSIF in this case.
Yeah, lack of select and case statements are really annoying but its one less
keyword that people need to learn about.
> #2;
> 100% object oriented? :D
Hey, Euphoria is a clean and simple language we don't need any objects messing
it up! :p
(Although, in all honesty I'd rather Rob add gotos then add support for OOP.)
If I could add anything to Euphoria it'd be pointers. It's annoying when you use
long desriptive variable names to have to type for example (in a program I'm
working on now)
if equal( running_tasks[priority][task_id][TASK_NAME], task_to_kill ) then
running_tasks[priority][task_id][TASK_NAME] =
kill_task( running_tasks[priority][task_id][TASK_NAME] )
elsif equal( sleeping_tasks[priority][task_id][TASK_NAME], task_to_kill ) then
sleeping_tasks[priority][task_id][TASK_NAME] =
kill_task( sleeping_tasks[priority][task_id][TASK_NAME] )
else
printf(2, "Error: No task named %s found.\n", {task_to_kill} )
end if
when using pointers I could just type something along the lines of
current_task = pointer_to(running_tasks[priority][task_id][TASK_NAME])
if equal(current_task, task_to_kill) then
current_task = kill_task(current_task)
else
current_task = pointer_to(sleeping_tasks[priority][task_id][TASK_NAME])
if equal(current_task, task_to_kill) then
current_task = kill_task(current_task)
else
printf(2, "Error: No task named %s found.\n", {task_to_kill})
end if
end if
The second method is a lot easier to type out and is still just as readable.
6. Re: New Euphoria features
- Posted by CChris <christian.cuvier at agriculture.gouv.fr>
Feb 23, 2005
-
Last edited Feb 24, 2005
D. Newhall wrote:
>
> ZNorQ wrote:
> >
> > IF I'm so lucky, I would wish for the following features;
> >
> > #1;
> > Select Case
> > Case .. or ..
> > Case Else
> > end Select
> >
> > I hate having to use IF / ELSIF in this case.
> Yeah, lack of select and case statements are really annoying but its one less
> keyword
> that people need to learn about.
>
Why? It will be there when you need it, but are you learning all the keywords
and constructs of a language at once ??? I wouldn't recommend that anyway.
> > #2;
> > 100% object oriented? :D
> Hey, Euphoria is a clean and simple language we don't need any objects messing
> it up!
> :p
>
Hey, Euphoria lacks modularity because it lacks objects (in the OOP sense)
and correct namespace system. When you look at the kind of obfuscated code
you need to get them, I wonder how can this language claim to be "clean".
> (Although, in all honesty I'd rather Rob add gotos then add support for OOP.)
>
>
> If I could add anything to Euphoria it'd be pointers. It's annoying when you
> use long
> desriptive variable names to have to type for example (in a program I'm
> working on
> now)
>
> if equal( running_tasks[priority][task_id][TASK_NAME], task_to_kill ) then
> running_tasks[priority][task_id][TASK_NAME] =
> kill_task( running_tasks[priority][task_id][TASK_NAME] )
> elsif equal( sleeping_tasks[priority][task_id][TASK_NAME], task_to_kill )
> then
> sleeping_tasks[priority][task_id][TASK_NAME] =
> kill_task( sleeping_tasks[priority][task_id][TASK_NAME] )
> else
> printf(2, "Error: No task named %s found.\n", {task_to_kill} )
> end if
>
> when using pointers I could just type something along the lines of
>
> current_task = pointer_to(running_tasks[priority][task_id][TASK_NAME])
> if equal(current_task, task_to_kill) then
> current_task = kill_task(current_task)
> else
> current_task = pointer_to(sleeping_tasks[priority][task_id][TASK_NAME])
> if equal(current_task, task_to_kill) then
> current_task = kill_task(current_task)
> else
> printf(2, "Error: No task named %s found.\n", {task_to_kill})
> end if
> end if
>
> The second method is a lot easier to type out and is still just as readable.
>
Pointers are supposed to be unsafe, hard to debug etc. I don't fully agree
with that view.
However, some solution to the problem you state is needed. Creating aliases
for things, like in:
ref current_task running_tasks[priority][task_id][TASK_NAME]
--do some stuff, using "current_task" as a macro
deref current_task
may enable one to have it both ways.
CChris
7. Re: New Euphoria features
- Posted by "David Jarvis" <davidj at ultrasmart.org>
Feb 23, 2005
-
Last edited Feb 24, 2005
Dear Members
Pls keep Eu simple so it stays fast, cheap, and easy to learn.
David
On 23 Feb 2005 at 13:45, CChris wrote:
>
>
> posted by: CChris <christian.cuvier at agriculture.gouv.fr>
>
> D. Newhall wrote:
> >
> > ZNorQ wrote:
> > >
> > > IF I'm so lucky, I would wish for the following features;
> > >
> > > #1;
> > > Select Case
> > > Case .. or ..
> > > Case Else
> > > end Select
> > >
> > > I hate having to use IF / ELSIF in this case.
> > Yeah, lack of select and case statements are really annoying but
its
> > one less keyword that people need to learn about.
> >
>
> Why? It will be there when you need it, but are you learning all
the
> keywords and constructs of a language at once ??? I wouldn't
recommend
> that anyway.
>
> > > #2;
> > > 100% object oriented? :D
> > Hey, Euphoria is a clean and simple language we don't need any
> > objects messing it up! :p
> >
>
> Hey, Euphoria lacks modularity because it lacks objects (in the OOP
> sense) and correct namespace system. When you look at the kind of
> obfuscated code you need to get them, I wonder how can this
language
> claim to be "clean".
>
> > (Although, in all honesty I'd rather Rob add gotos then add
support
> > for OOP.)
> >
> >
> > If I could add anything to Euphoria it'd be pointers. It's
annoying
> > when you use long desriptive variable names to have to type for
> > example (in a program I'm working on now)
> >
> > if equal( running_tasks[priority][task_id][TASK_NAME],
> > task_to_kill ) then
> > running_tasks[priority][task_id][TASK_NAME] =
> > kill_task( running_tasks[priority][task_id][TASK_NAME] )
> > elsif equal( sleeping_tasks[priority][task_id][TASK_NAME],
> > task_to_kill ) then
> > sleeping_tasks[priority][task_id][TASK_NAME] =
> > kill_task( sleeping_tasks[priority][task_id][TASK_NAME] )
> > else
> > printf(2, "Error: No task named %s found.\n", {task_to_kill}
)
> > end if
> >
> > when using pointers I could just type something along the lines
of
> >
> > current_task =
> > pointer_to(running_tasks[priority][task_id][TASK_NAME]) if
> > equal(current_task, task_to_kill) then
> > current_task = kill_task(current_task)
> > else
> > current_task =
> > pointer_to(sleeping_tasks[priority][task_id][TASK_NAME]) if
> > equal(current_task, task_to_kill) then
> > current_task = kill_task(current_task)
> > else
> > printf(2, "Error: No task named %s found.\n",
{task_to_kill})
> > end if
> > end if
> >
> > The second method is a lot easier to type out and is still just
as
> > readable.
> >
>
> Pointers are supposed to be unsafe, hard to debug etc. I don't
fully
> agree with that view. However, some solution to the problem you
state
> is needed. Creating aliases for things, like in:
>
> ref current_task running_tasks[priority][task_id][TASK_NAME]
> --do some stuff, using "current_task" as a macro
> deref current_task
>
> may enable one to have it both ways.
>
> CChris
>
>
>
>
8. Re: New Euphoria features
- Posted by D. Newhall <derek_newhall at yahoo.com>
Feb 23, 2005
-
Last edited Feb 24, 2005
CChris wrote:
> Why? It will be there when you need it, but are you learning all the keywords
> and constructs of a language at once ??? I wouldn't recommend that anyway.
Actually, that's exactly how I learned it. I read the reference manual all the
way through at work. It's probably something that's peculiar to me but I learn
programming languages by reading reference manuals instead of tutorials. I tried
reading "Learning Perl" but never finished it and read "Programming Perl"
instead.
> Hey, Euphoria lacks modularity because it lacks objects (in the OOP sense)
> and correct namespace system. When you look at the kind of obfuscated code
> you need to get them, I wonder how can this language claim to be "clean".
Euphoria has perfectly fine modularity (except for maybe a few scope issues).
That's one of the reasons I stil use Euphoria. It's easier to do modular
programming than in most other languages and you don't need to make a class for
everything like in OO languages. Also, modular procedural programming (Euphoria,
Modula-2, Ada 83, etc.) is a LOT easier to teach to new programmers than object
oriented programming (like Java, SmallTalk, Eiffel, etc.) because you don't need
to deal with inheritance, polymorphism, and all that other stuff that's good for
OOP but just gets in the way if you just want to parse some text.
> Pointers are supposed to be unsafe, hard to debug etc. I don't fully agree
> with that view.
> However, some solution to the problem you state is needed. Creating aliases
> for things, like in:
>
> ref current_task running_tasks[priority][task_id][TASK_NAME]
> --do some stuff, using "current_task" as a macro
> deref current_task
>
> may enable one to have it both ways.
Yes, pointers are unsafe but if they were carefully designed and implemented
they'd make many tasks a lot simpler. At the very least I'd like a way to get a
reference to a variable (ala something like variable_id()) since it'd make OO
programming a lot easier without imposing OOP on the programmer or allowing the
programmer to use pointers.
9. Re: New Euphoria features
ZNorQ wrote:
>> >
>> > IF I'm so lucky, I would wish for the following features;
>> >
>> > #1;
>> > Select Case
>> > Case .. or ..
>> > Case Else
>> > end Select
>> >
>> > I hate having to use IF / ELSIF in this case.
Sorry, but that is a truly AWFUL way to ask for change. You give
absolutely no reason /why/ it would be better. Note that this must not
be about personal preference, it must be a genuine gain, for all.
See below:
>> > #2;
>> > 100% object oriented? :D
If you want OO, use Java/C++ 
)
CChris wrote:
>Pointers are supposed to be unsafe, hard to debug etc. I don't fully agree
>with that view.
>However, some solution to the problem you state is needed. Creating aliases
>for things, like in:
>
>ref current_task running_tasks[priority][task_id][TASK_NAME]
>--do some stuff, using "current_task" as a macro
I agree wholeheartedly, thought I would prefer alias, and further that
it is only available inside routines, since I think it adds complexity
if not defined locally.
alias rt to running_tasks[priority][task_id][TASK_NAME]
alias st to sleeping_tasks[priority][task_id][TASK_NAME]
if equal( rt, task_to_kill ) then
rt = kill_task( rt )
elsif equal( st, task_to_kill ) then
st = kill_task( st )
...
which I think is a darn sight better than:
if equal( running_tasks[priority][task_id][TASK_NAME],
task_to_kill ) then
running_tasks[priority][task_id][TASK_NAME] = kill_task(
running_tasks[priority][task_id][TASK_NAME] )
elsif equal( sleeping_tasks[priority][task_id][TASK_NAME],
task_to_kill ) then
sleeping_tasks[priority][task_id][TASK_NAME] = kill_task(
sleeping_tasks[priority][task_id][TASK_NAME] )
Note that an alias is not "efficient", for that you probably need
local var(s), (I couldn't see a way with the above to improve matters
anyway, given refcount issues). It performs all the work that the
longhand version does, unless someone has a bright idea.
Though as I've said before, the only way you'll get anywhere with this
is to implement it in the open source eu.ex, sorry.
Regards,
Pete
10. Re: New Euphoria features
D. Newhall wrote:
>
> ZNorQ wrote:
> >
> > IF I'm so lucky, I would wish for the following features;
> >
> > #1;
> > Select Case
> > Case .. or ..
> > Case Else
> > end Select
> >
> > I hate having to use IF / ELSIF in this case.
> Yeah, lack of select and case statements are really annoying but its one less
> keyword
> that people need to learn about.
>
> > #2;
> > 100% object oriented? :D
> Hey, Euphoria is a clean and simple language we don't need any objects messing
> it up!
> :p
>
> (Although, in all honesty I'd rather Rob add gotos then add support for OOP.)
>
>
> If I could add anything to Euphoria it'd be pointers. It's annoying when you
> use long
> desriptive variable names to have to type for example (in a program I'm
> working on
> now)
>
> if equal( running_tasks[priority][task_id][TASK_NAME], task_to_kill ) then
> running_tasks[priority][task_id][TASK_NAME] =
> kill_task( running_tasks[priority][task_id][TASK_NAME] )
> elsif equal( sleeping_tasks[priority][task_id][TASK_NAME], task_to_kill )
> then
> sleeping_tasks[priority][task_id][TASK_NAME] =
> kill_task( sleeping_tasks[priority][task_id][TASK_NAME] )
> else
> printf(2, "Error: No task named %s found.\n", {task_to_kill} )
> end if
>
> when using pointers I could just type something along the lines of
>
> current_task = pointer_to(running_tasks[priority][task_id][TASK_NAME])
> if equal(current_task, task_to_kill) then
> current_task = kill_task(current_task)
> else
> current_task = pointer_to(sleeping_tasks[priority][task_id][TASK_NAME])
> if equal(current_task, task_to_kill) then
> current_task = kill_task(current_task)
> else
> printf(2, "Error: No task named %s found.\n", {task_to_kill})
> end if
> end if
>
> The second method is a lot easier to type out and is still just as readable.
>
If I understand this correctly, we're rather talking about some sort of
abbrivation - or rather an alias. If I'm not mistaking, there is a
WITH / END WITH for object manipulation in VB (Not sure if it where there
I saw it) which lets you modify an object without having to give reference
to the whole 'path', ie. instead of writing the line
'myObject.myfield.lines.text', you could write
WITH myObject.myfield.lines DO
.text = 'This is a test'
.colour = Blue
.. etc.
END WITH
Sorry if I totally misunderstood this... :D
Kenneth aka ZNorQ
11. Re: New Euphoria features
Pete Lomax wrote:
>
> ZNorQ wrote:
> >> >
> >> > IF I'm so lucky, I would wish for the following features;
> >> >
> >> > #1;
> >> > Select Case
> >> > Case .. or ..
> >> > Case Else
> >> > end Select
> >> >
> >> > I hate having to use IF / ELSIF in this case.
> Sorry, but that is a truly AWFUL way to ask for change. You give
> absolutely no reason /why/ it would be better. Note that this must not
> be about personal preference, it must be a genuine gain, for all.
Hey, did I step on your toes here? I'm not asking for any changes, the
subject was brougth up, I answered what additions I'd like to see in
Euphoria (I kinda take back the OOP preference - like Eu programming
style the way it is). And why shouldn't I mention this as my personal
preference? I can't speak for the whole community what they want!
Anyone is welcome to agree or disagree as much as they whan, and yes -
I think it IS a genuine gain - for all.
I'm sorry I didn't give my reason why it would be better with the inclusion
of "Select Case", so here it is (remember, my English is poor, and so is my
programming knowlege. I do not know all the technical words/jargons, but I
hope you understand.)
'Select case' is a good way to checking the content of a SINGLE variable's
(of any type) content without having to restate the whole expression each time.
Especially if there is a lot to consider. It's clean, and gives you a good
overview. By using IF / ELSIF you have to retype the expression - or -
using alot's of 'OR' statements.
PS! We still need IF / ELSIF! :D
> See below:
>
> >> > #2;
> >> > 100% object oriented? :D
> If you want OO, use Java/C++ )
>
Yes, I totally agree with you on this one - I do take this one back! :D
> CChris wrote:
>
> >Pointers are supposed to be unsafe, hard to debug etc. I don't fully agree
> >with that view.
> >However, some solution to the problem you state is needed. Creating aliases
> >for things, like in:
> >
> >ref current_task running_tasks[priority][task_id][TASK_NAME]
> >--do some stuff, using "current_task" as a macro
> I agree wholeheartedly, thought I would prefer alias, and further that
> it is only available inside routines, since I think it adds complexity
> if not defined locally.
>
> }}}
<eucode>
> alias rt to running_tasks[priority][task_id][TASK_NAME]
> alias st to sleeping_tasks[priority][task_id][TASK_NAME]
>
> if equal( rt, task_to_kill ) then
> rt = kill_task( rt )
> elsif equal( st, task_to_kill ) then
> st = kill_task( st )
> ...
> </eucode>
{{{
>
> which I think is a darn sight better than:
>
> }}}
<eucode>
> if equal( running_tasks[priority][task_id][TASK_NAME],
> task_to_kill ) then
> running_tasks[priority][task_id][TASK_NAME] = kill_task(
> running_tasks[priority][task_id][TASK_NAME] )
> elsif equal( sleeping_tasks[priority][task_id][TASK_NAME],
> task_to_kill ) then
> sleeping_tasks[priority][task_id][TASK_NAME] = kill_task(
> sleeping_tasks[priority][task_id][TASK_NAME] )
> </eucode>
{{{
>
> Note that an alias is not "efficient", for that you probably need
> local var(s), (I couldn't see a way with the above to improve matters
> anyway, given refcount issues). It performs all the work that the
> longhand version does, unless someone has a bright idea.
>
> Though as I've said before, the only way you'll get anywhere with this
> is to implement it in the open source eu.ex, sorry.
>
> Regards,
> Pete
>
>
12. Re: New Euphoria features
On Thu, 24 Feb 2005 03:08:29 -0800, ZNorQ <guest at RapidEuphoria.com>
wrote:
>Hey, did I step on your toes here?
No.
> I'm not asking for any changes,
Ah, I didn't realize that, sorry.
Pete
13. Re: New Euphoria features
Correction to
> By using IF / ELSIF you have to retype the expression - or -
> using alot's of 'OR' statements.
Using alot of 'OR' statements wouldn't work - you would have to use
IF expression THEN
ELSIF expression
ELSIF expression
... etc.
ENDIF
The essence is that you would have to rewrite the expression each time, you
wouldn't that using SELECT CASE.
ZNorQ..
14. Re: New Euphoria features
ZNorQ wrote:
><snip>
> > when using pointers I could just type something along the lines of
> >
> > current_task = pointer_to(running_tasks[priority][task_id][TASK_NAME])
> > if equal(current_task, task_to_kill) then
> > current_task = kill_task(current_task)
> > else
> > current_task = pointer_to(sleeping_tasks[priority][task_id][TASK_NAME])
> > if equal(current_task, task_to_kill) then
> > current_task = kill_task(current_task)
> > else
> > printf(2, "Error: No task named %s found.\n", {task_to_kill})
> > end if
> > end if
> >
> > The second method is a lot easier to type out and is still just as readable.
> >
> If I understand this correctly, we're rather talking about some sort of
> abbrivation - or rather an alias. If I'm not mistaking, there is a
> WITH / END WITH for object manipulation in VB (Not sure if it where there
> I saw it) which lets you modify an object without having to give reference
> to the whole 'path', ie. instead of writing the line
> 'myObject.myfield.lines.text', you could write
> WITH myObject.myfield.lines DO
> .text = 'This is a test'
> .colour = Blue
> .. etc.
> END WITH
>
> Sorry if I totally misunderstood this... :D
>
> Kenneth aka ZNorQ
>
Pascal has 'with', which allows the name of a record (structure) to be
omitted within the block it is declared for. Elements of the record
can just be referred to by their name. Pascal uses a dot notation to
append the element name to the record name. The long winded naming in the
Eu example would not be resolved, since these are indices to arrays, (well,
sequences). Ah, but what if Euphoria allowed dot notation for named
elements instead of square brackets and index values... :)
John
