1. New Euphoria features
- Posted by Brent W. Hughes <bwh566 at yahoo.com> Feb 22, 2005
- 496 views
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
- Posted by Patrick Barnes <mrtrick at gmail.com> Feb 22, 2005
- 468 views
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
- Posted by ZNorQ <znorq at holhaug.com> Feb 23, 2005
- 468 views
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
- Posted by "Juergen Luethje" <j.lue at gmx.de> Feb 23, 2005
- 475 views
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
- 613 views
- 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
- 462 views
- 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
- 486 views
- 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
- 465 views
- 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
- Posted by Pete Lomax <petelomax at blueyonder.co.uk> Feb 24, 2005
- 469 views
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
- Posted by ZNorQ <znorq at holhaug.com> Feb 24, 2005
- 456 views
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
- Posted by ZNorQ <znorq at holhaug.com> Feb 24, 2005
- 462 views
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
- Posted by Pete Lomax <petelomax at blueyonder.co.uk> Feb 24, 2005
- 457 views
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
- Posted by ZNorQ <znorq at holhaug.com> Feb 24, 2005
- 459 views
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
- Posted by John E <jwfe at talk21.com> Feb 24, 2005
- 470 views
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