1. suggestion
- Posted by jacques deschênes <desja at glo?e?rotter.net> May 13, 2008
- 756 views
I suggest that we the trace the line for the next version. If we always add new features, we'll never see the end of it. here how I see it. 1) before any work on a new version: discuss improvements 2) agree on which ones will be included in next version. 3) trace the line. 4) start working on next version 5) queue any further suggestions for after next version. 6) release next version 7) goto to step 1 Jacques Deschênes
2. Re: suggestion
- Posted by Jason Gade <jaygade at y??oo.com> May 13, 2008
- 684 views
jacques deschênes wrote: > > > I suggest that we the trace the line for the next version. If we always add > new features, we'll never see the end of it. > > here how I see it. > > 1) before any work on a new version: discuss improvements > 2) agree on which ones will be included in next version. > 3) trace the line. > 4) start working on next version > 5) queue any further suggestions for after next version. > 6) release next version > 7) goto to step 1 > > Jacques Deschênes No goto! But yeah, we do seem to be experiencing some feature creep and keep moving the actual target. I thought that 4.0 would include the new standard library and the namespace improvement. The other stuff is pie-in-the-sky future stuff, right? I think. -- 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.
3. Re: suggestion
- Posted by Jeremy Cowgar <jeremy at cowga?.?om> May 13, 2008
- 698 views
jacques deschênes wrote: > > I suggest that we the trace the line for the next version. If we always add > new features, we'll never see the end of it. > > here how I see it. > > 1) before any work on a new version: discuss improvements > 2) agree on which ones will be included in next version. > 3) trace the line. > 4) start working on next version > 5) queue any further suggestions for after next version. > 6) release next version > 7) goto to step 1 > It's always good to have a plan yes. I created a roadmap on the wiki a while ago: http://euwiki.ayo.biz/Roadmap however, I have been stalling for some decisions to be made. In stalling, I started a doc overhaul which CK Lester is working on (and could use some help). During this time, I have spent time in the interpreter and translator code learning it. In learning, I found a few things I could do. I closed some bugs, saw some old feature requests out there, so I began posting here for discussion as to see which features should be implemented or not. The big thing to me that needs done is more improvements of the namespace. That's of the utmost priority but we are not totally sure what to do there yet to solve some name conflicts. That's another thing that put me in a holding pattern. SF.net has a feature request list: http://sourceforge.net/tracker/?group_id=182827&atid=902785 The wiki also has a feature request list (some of which I've implemented): http://euwiki.ayo.biz/Category:Requested_functionalities I think we should focus on things that will possibly break code as 4.0 does have a few of those in it. If we are going to break code, I think we should have one release that breaks code, not one release that breaks a little code (4.0), then have 4.1 break a little more, 4.2 break a little more, etc... (well, actually, I think within major versions, code should not be broken). Breaking code should not be a repetitive thing. Your right. A list needs to be created. Now, how to go about creating this list? -- Jeremy Cowgar http://jeremy.cowgar.com
4. Re: suggestion
- Posted by jacques deschênes <desja at gl?betrotter.?et> May 13, 2008
- 717 views
Jeremy Cowgar wrote: > > jacques deschênes wrote: > > > > I suggest that we the trace the line for the next version. If we always add > > new features, we'll never see the end of it. > > > > here how I see it. > > > > 1) before any work on a new version: discuss improvements > > 2) agree on which ones will be included in next version. > > 3) trace the line. > > 4) start working on next version > > 5) queue any further suggestions for after next version. > > 6) release next version > > 7) goto to step 1 > > > > It's always good to have a plan yes. I created a roadmap on the wiki a while > ago: <a href="http://euwiki.ayo.biz/Roadmap">http://euwiki.ayo.biz/Roadmap</a> > however, I have been stalling for some decisions to be made. > > In stalling, I started a doc overhaul which CK Lester is working on (and could > use some help). During this time, I have spent time in the interpreter and > translator > code learning it. In learning, I found a few things I could do. I closed some > bugs, saw some old feature requests out there, so I began posting here for > discussion > as to see which features should be implemented or not. > > The big thing to me that needs done is more improvements of the namespace. > That's > of the utmost priority but we are not totally sure what to do there yet to > solve > some name conflicts. That's another thing that put me in a holding pattern. > > SF.net has a feature request list: <a > href="http://sourceforge.net/tracker/?group_id=182827&atid=902785">http://sourceforge.net/tracker/?group_id=182827&atid=902785</a> > > The wiki also has a feature request list (some of which I've implemented): > <a > href="http://euwiki.ayo.biz/Category:Requested_functionalities">http://euwiki.ayo.biz/Category:Requested_functionalities</a> > > I think we should focus on things that will possibly break code as 4.0 does > have a few of those in it. If we are going to break code, I think we should > have one release that breaks code, not one release that breaks a little code > (4.0), then have 4.1 break a little more, 4.2 break a little more, etc... > (well, > actually, I think within major versions, code should not be broken). Breaking > code should not be a repetitive thing. > > Your right. A list needs to be created. > > Now, how to go about creating this list? > > -- > Jeremy Cowgar > <a href="http://jeremy.cowgar.com">http://jeremy.cowgar.com</a> the line for me as for version 4.0 should be: 1) fix bugs 2) standard libraries (no addition from now) 3) namespace resolution (Mat seem to have an acceptable solution to it, freeze it there, if we wait for a perfect solution,we'll never see the end). that's it, that's all for preprocessor athougth I've been waiting for it for a long time it should be queued. Jacques Deschênes
5. Re: suggestion
- Posted by Jeremy Cowgar <jeremy at co?ga?.com> May 13, 2008
- 703 views
jacques deschênes wrote: > > the line for me as for version 4.0 should be: > > 1) fix bugs > 2) standard libraries (no addition from now) > 3) namespace resolution (Mat seem to have an acceptable solution to it, freeze > it there, if we wait for a perfect solution,we'll never see the end). > > that's it, that's all > > for preprocessor athougth I've been waiting for it for a long time it should > be queued. Hm, pre-processor is done. It contains features that people have been wanting for a long time. Also, continue is done and is part of 4.0. I think also that a case statement should be added. 4.0 is a major release and I think it should contain not tiny improvements, but something that warrants a major release. So far, I think we are on a good track. The labeled loops I think also should go into 4.0. -- Jeremy Cowgar http://jeremy.cowgar.com
6. suggestion
- Posted by Mike Fowler <stoner at NELSUN.GEN.NZ> Sep 30, 1997
- 716 views
---8<--- snip -> This idea has come up before. Exception handling of this sort might -> be nice, but it is technically a rather tricky thing to add to the -> current implementation. -> However I'll add your request to my (infamous!) suggestion folder. -> well, another handy little addition that C has, is adding 1 to an integer. In euphoria, to add 1 to the integer "add", you'd have to type: add = add + 1 whereas in C you can just type add ++ and to take 1 away, its just "add --" Though it's not deathly important, it would be nice Mike Fowler - mike.fowler at nelsun.gen.nz o__ --- _,>/'_ --- (_) \(_) --- Tip for the month: Don't have a signature :)
7. Re: suggestion
- Posted by Robert B Pilkington <bpilkington at JUNO.COM> Sep 30, 1997
- 710 views
>-> This idea has come up before. Exception handling of this sort might >-> be nice, but it is technically a rather tricky thing to add to the >-> current implementation. >-> However I'll add your request to my (infamous!) suggestion folder. >-> > >well, another handy little addition that C has, is adding 1 to an >integer. In euphoria, to add 1 to the integer "add", you'd have to >type: > >add = add + 1 > >whereas in C you can just type > >add ++ >and to take 1 away, its just "add --" C also has things like: add += 4 add -= 4 add *= 4 add /= 4 Which would be: add = add + 4 add = add - 4 add = add * 4 add = add / 4 >Though it's not deathly important, it would be nice It would be, wouldn't it? Although I don't know how much it would slow Euphoria down........... (It will need to check for each new operator, --, ++, +=, -=, *=, and /=, taking up time.)
8. Re: suggestion
- Posted by Ralf Nieuwenhuijsen <nieuwen at XS4ALL.NL> Oct 01, 1997
- 735 views
Robert B Pilkington wrote: > >whereas in C you can just type > > > >add ++ > >and to take 1 away, its just "add --" > > C also has things like: > add += 4 > add -= 4 > add *= 4 > add /= 4 > > Which would be: > add = add + 4 > add = add - 4 > add = add * 4 > add = add / 4 > > >Though it's not deathly important, it would be nice Why, it would be more complicated for no extra flexibility. That c needs those so badly, is because for about any form of loop/for/while you'll those special commands, plus the fact that their meaning totally differs from the above said. In c, everything returns a value, add++ isn't the same as add = add + 1. Not even in C. Try this: -------- C --------------- add = 4; if (add++ == 5) then Do_a () else Do_b () ------------------------- It will call (do_b) not (do_a). Cause in add++ returns the value of add and then adds one to it. The returned value is compared with 5. At that point it is still 4. You should use ++add to have the effect you want. But why, as you can avoid all the trouble by a few more chars, but with a lot more readability, do want to use add++ instead of add = add + 1. BTW If you really really want this, write a pre-processor, but all c-programmers will get totally confused. > It would be, wouldn't it? > Although I don't know how much it would slow Euphoria down........... (It > will need to check for each new operator, --, ++, +=, -=, *=, and /=, > taking up time.) Eh.. no, if Euphoria would be procession your code in runtime, it would run like Commedore Basic. Actually speed wasn't influenced by this at all. As Robert once told us, the code is first being pre-compiled to a queue with the memory address of the code which should do that piece of magic and with the addresses of the parameters for that routine.... It would just generate a different address. No Euphoria does not interpreter your code by -if -then statements. Althrough this would be normal for most interpreters. But we all know the speed of Euphoria (being 99% in c, and still a zillion times faster than the asm routines of MS, iffing through your code..) I mean, Euphoria isn't close to totally speed optimized. (with 99% written in C) But maybe in the future..... Ralf Nieuwenhuijsen nieuwen at xs4all.nl
9. Re: suggestion
- Posted by "Vikas B. Patel" <patelv at EROLS.COM> Oct 01, 1997
- 708 views
Hi, C and C++ also have BLOCK COMMENTS! it's kinda annoying to put '--' in front of every line! Euphoria needs block comments (or am i wrong?) Bye, Vikas B. Patel ******************************************************************* \*The Programmers' Guild:For the Amatuer and Hardcore Programmers*/ \\* http://www.geocities.com/SiliconValley/Way/7272/ *// \\\*OM Jai Hind OM*/// *******************************************************************
10. Re: suggestion
- Posted by Irv <mountains at MINDSPRING.COM> Oct 01, 1997
- 723 views
Vikas B. Patel wrote: > > Hi, > C and C++ also have BLOCK COMMENTS! > it's kinda annoying to put '--' in front of every line! > Euphoria needs block comments (or am i wrong?) > Bye, So does Turbo Pascal, but it's just no big deal. Sometimes having block comments can cause problems; after you add and delete a lot, you can accidently comment out some working code. I prefer the --'s Irv
11. Re: suggestion
- Posted by Ralf Nieuwenhuijsen <nieuwen at XS4ALL.NL> Oct 02, 1997
- 722 views
Irv wrote: > Vikas B. Patel wrote: > > > > Hi, > > C and C++ also have BLOCK COMMENTS! > > it's kinda annoying to put '--' in front of every line! > > Euphoria needs block comments (or am i wrong?) > > Bye, > > So does Turbo Pascal, but it's just no big deal. Sometimes having block > comments can cause problems; after you add and delete a lot, you can > accidently comment out some working code. I prefer the --'s If people want stuff like this in Euphoria, there is no need for RDS to rewrite it. Cause the compiled EUphoria code that will be executed will be the same. (Just like the suggestions about =+ and ++) You can for example write a preprocessor, a program that replaces your new code, with the good euphoria code. Or you can wait for David Cuny to have a working version of the macro language. Then you enter such stuff in a definition file like this: | ^1 ++ | >> ^1 = ^1 + 1 | ^1 -- | >> ^1 = ^1 - 1 | ^1 -= | >> ^1 = ^1 - BTW this language is still to be changed, real practical work has not been done, just wait for him to finish this tool, that will makes us all able to write a lot compact and cleaner code. No, here's a real suggestion... (RDS will need to totally rewrite their code to this implend this one, so i guess they won't) This is based upon the ICON language... Every function can return two types of return-values: + FAILURE (something like false) + NON-FAILURE (Normal function respons) Now lets say, that in a function the word 'suspend' returns a value, but if there are more values wanted the code will be executed from the suspend. The keyword every, makes us always want to have every value. AN example: -- This function returns values from 1 to a*2, stepping 2. function upto2 ( integer a ) for j = 1 to a do suspend a*2 end for end function -- This will print all the numbers.. every print(1, upto2 ( 10 ) ) -- ALso you can do this trick sequence text_sequence text_sequence = "I will count the spaces in this sentence" every find(' ' , text_sequence) puts(1,"Found another space!\n") -- We need this function too.. function upto (integer a) for r = 1 to a do suspend r end for end function -- We can also strip all the spaces.. sequence new_text every (not find(' ', text_sequence)) new_text = append(new_text, text_sequence[upto(length(text_sequence))]) -------------------------------------------------------------------------- Kind a looks interesting doesn't it, very short compact code... Every more loops are avoided with these tricks. We all know that if we want to strip all spaces now, it takes up a lot more code. I somebody wants to know more about, do a web-search on: ICON PROGRAMMING LANGUAGE ALthrough this is hard to implend, i do think you should consider this Robert, it will make Euphoria even more powerfull and you don't need to rewrite the stuff that executes the code, but only the compiler (to be able to compile this kind of code), am i right ? Please give me your opinion... Ralf NIeuwenhuijsen nieuwen at xs4all.nl