1. Re[4]: Why some people have not upgraded
- Posted by akusaya at gmx.net
Jan 03, 2006
>> Could it be something 'big' like ignoring function results? :D
p> No disrespect intended, aku, but that does blow my mind that you think
p> that 'big'. It just seems so tiny against the include file problems and
p> non-blocking i/o...
Yes, I also think that ignoring function results is a tiny thing, but
I consider it as 'big' when seen from RDS point of view, because I
think RDS is always busy implementing difficult things but not the most
simple things...
>> May we know what are the "several other things? :D
>> Could it be something 'big' like ignoring function results? :D
p> I'm still busy with multitasking in the Translator.
p> Until that's done, I don't want to think about other features.
I'm refering to your message, "There are several other things I'd like
to include in a 3.0 alpha release besides multitasking.", so I thought
you have decided them, no?
2. Re: Re[4]: Why some people have not upgraded
akusaya wrote:
>
> >> Could it be something 'big' like ignoring function results? :D
> p> No disrespect intended, aku, but that does blow my mind that you think
> p> that 'big'. It just seems so tiny against the include file problems and
> p> non-blocking i/o...
>
> Yes, I also think that ignoring function results is a tiny thing, but
> I consider it as 'big' when seen from RDS point of view, because I
> think RDS is always busy implementing difficult things but not the most
> simple things...
>
(snip)
Well, in this case RDS probably won't implement it because it's a bad idea. A
function returns a value so, naturally, if I forget to catch this value I'll be
trying to make it do somthing it shouldn't be doing and isn't permitted in the
language so I would of course expect an error to occur.
The Euphoria Standard Library project :
http://esl.sourceforge.net/
The Euphoria Standard Library mailing list :
https://lists.sourceforge.net/lists/listinfo/esl-discussion
3. Re: Re[4]: Why some people have not upgraded
D. Newhall wrote:
>
> akusaya wrote:
> >
> > >> Could it be something 'big' like ignoring function results? :D
> > p> No disrespect intended, aku, but that does blow my mind that you think
> > p> that 'big'. It just seems so tiny against the include file problems and
> > p> non-blocking i/o...
> >
> > Yes, I also think that ignoring function results is a tiny thing, but
> > I consider it as 'big' when seen from RDS point of view, because I
> > think RDS is always busy implementing difficult things but not the most
> > simple things...
> >
> (snip)
>
> Well, in this case RDS probably won't implement it because it's a bad idea.
> A function returns a value so, naturally, if I forget to catch this value I'll
> be trying to make it do somthing it shouldn't be doing and isn't permitted in
> the language so I would of course expect an error to occur.
I'd have to agree, but I would like a void variable that uses no memory to
discard the value, but still error if I've simply forgot to assign it to
something!
Alex
4. Re: Re[4]: Why some people have not upgraded
Alex Chamberlain wrote:
> I'd have to agree, but I would like a void variable that uses no memory to
> discard
> the value, but still error if I've simply forgot to assign it to something!
> Alex
Do you actually think Robert would ever agree to this? You are suggesting for
him to introduce a garbage variable when we already can achieve this? In fact we
obviously have two, often three choices:
1) void = where(fn)
2) void( where(fn) )
3) machine_proc(WHERE, fn)
Heres the way I see it...
If Euphoria left the "relm of the minimalists" and instead tried to cater
everyones fine desires, we would probably end up with a vastly different
language, that very few people could appreciate. Euphoria would become a language
that is difficult to get a grasp on, retain specific knowledge; basically just
harder to develop general projects. Euphoria would become loaded with features &
enhancements that could only be helpful in rare cases. Euphoria would be pulled
from every corner, thus having no clear sense of direction.
I agree that Euphoria is missing alot, but besides a couple core language design
decisions, the problem stems exclusively from our libraries rather than the core
specification. The core language is a piece of the puzzle; but the contributed
programs & libraries are much more important and are really the basis for
Euphoria's survival to this day. The problem that plagues us is our small
community. We have a wide spectrum of libraries, tools, IDEs, etc. that vary
greatly in quality, reliability, and surely documentation; our efforts are
fragmented and leave many "holes" with specific functionality.
The best thing we could hope for at this point is that Euphoria's popularity,
positive reputation, and community continue to grow but however, maybe at a
quicker rate than before.
I think these threads have worn out their welcome here... can we please deviate
from them and engage in more productive conversations?
Regards,
Vincent
5. Re: Re[4]: Why some people have not upgraded
On 1/3/06, D. Newhall <guest at rapideuphoria.com> wrote:
> Well, in this case RDS probably won't implement it because it's a bad ide=
a. A function returns a value so, naturally, if I forget to catch this valu=
e I'll be trying to make it do somthing it shouldn't be doing and isn't per=
mitted in the language so I would of course expect an error to occur.
That's certainly presumptive, at best. You don't write every function
you use, you don't use every value a function returns (system_exec?),
and many functions do MORE than just return a value.
If you don't want to use the value a function returns... you can currently =
do:
global object JUNK
...
JUNK = myfuncwithignoredreturn()
--...Great, every time I call this, it has to de-allocate the data
that was previously stored in JUNK, allocate space for the return
value, and set it, for nothing.
Or you can do:
if myfuncwithignoredreturn() then end if
--...Why the hell would we use a control structure for no reason? Not
to mention the fact that this crashes if the func returns a sequence.
There's still overhead too - the interpreter has to store the return
value long enough to calculate whether it's zero or not, and the
comparison has to be done.
I used to think that the language having a procedure call and a
function call was quite logical, but after becoming acquainted with
plenty of other languages, I'd say it's a rather useless feature.
--
MrTrick
----------
