1. suggestion
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
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
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
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
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
---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
>-> 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
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
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
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
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
