1. Feature for next Eu
Well, it looks like the 'add-this-syntax' thread has returned...
I think I've made my views on most of the ideas presented in
the thread known already ("no", for the most part.)
However, I wish to present the case for something that should
be simpler, a lot less controversial, and not requiring the
grafting of a new paradigm into the language:
The 'remove' function.
Basically, it would work like so...
x = {1,2,3,4,5}
x = remove (x,3) -- x is now {1,2,4,5}
Now, I'm not demanding that this be made a new built-in
function. Simply having it stuck in MISC.E would be
fine (although honestly, it might be time for a
SEQUENCE.E file.)
The reason I ask for it is because I find myself having
to rewrite the function for numerous programs and
libraries. And of course, I usually make it local in
any code I release... I figure that if *I* need it,
other people's code that mine is to work with might
have the function as well. Having several local copies
of the same function, which is what I'm running into,
usually shows that there's a better way to do things...
In short, I think this would be a very nice addition to
the next release's MISC.E file.
(BTW - as to what other routines to include in a
SEQUENCE.E file, should the idea be taken seriously, I
would suggest:
insert (s,x,3) --> s[1..2] & x & s[3..length(s)]
last (s,5) --> the last 5 elements of s
reverse (s) --> moved from MISC.E
sort (s) --> moved from SORT.E
custom_sort (s) --> moved from SORT.E
dsort (s) --> descending; eliminates 'call_func'
bfind (x,s) --> find within a sorted sequence)
Rod Jackson
2. Re: Feature for next Eu
On Thu, 11 Nov 1999 17:11:50 -0600, Roderick Jackson <rjackson at CSIWEB.COM>
wrote:
> The 'remove' function.
>
>Basically, it would work like so...
>
> x = {1,2,3,4,5}
>
> x = remove (x,3) -- x is now {1,2,4,5}
So does that mean: remove the third element from the sequence x, or, remove
all instances of the value 3 from the sequence x. I assume the former but
your example could go either way. 8^)
-- Brian
3. Re: Feature for next Eu
Rod Jackson wrote:
> The 'remove' function.
>
>Basically, it would work like so...
>
> x = {1,2,3,4,5}
>
> x = remove (x,3) -- x is now {1,2,4,5}
I would suggest calling it "delete" instead, to pair with your "insert"
idea.
Also, the "3" in this function is referring to what -- the index, or the
sequence contents? I would assume it's the index, paralleling this with
"insert", but I just want to be clear on what you're proposing...
>Now, I'm not demanding that this be made a new built-in
>function. Simply having it stuck in MISC.E would be
>fine (although honestly, it might be time for a
>SEQUENCE.E file.)
Hear, hear! I've had my own SEQUENCE.E file for quite a while now, and it
includes some of the routines you've suggested.
>(BTW - as to what other routines to include in a
>SEQUENCE.E file, should the idea be taken seriously, I
>would suggest:
>
> insert (s,x,3) --> s[1..2] & x & s[3..length(s)]
Bad parm order -- if you're going to have "delete(s,3)" (or "remove(s,3)",
whatever), you should have the index parm in the same location for the
paired routines. "insert(s,3,x)" would be more consistent, IMO.
> last (s,5) --> the last 5 elements of s
?? I guess I don't see much need for this, although I admit it's kind of a
pain to have to code s[length(s)-4..length(s)] instead. I guess I've never
run into a situation where I've needed anything like this...
> reverse (s) --> moved from MISC.E
Definitely!
> sort (s) --> moved from SORT.E
> custom_sort (s) --> moved from SORT.E
I disagree -- the sort routines should remain in their own library,
methinks.
> dsort (s) --> descending; eliminates 'call_func'
Hmm -- I'd code "reverse(sort(s))" instead, but that probably isn't quite as
speed-efficient...
> bfind (x,s) --> find within a sorted sequence)
Definitely.
Hep yadda,
Gabriel Boehme
----------
The modern world is a crowd of very rapid racing cars all brought to a
standstill and stuck in a block of traffic.
G.K. Chesterton
----------
4. Re: Feature for next Eu
>> dsort (s) --> descending; eliminates 'call_func'
>Hmm -- I'd code "reverse(sort(s))" instead, but that probably isn't quite
as
>speed-efficient...
I tend to just use a= -sort(-a)
Matthew W Lewis
...no .sig...
5. Re: Feature for next Eu
Matthew W Lewis wrote:
> I tend to just use a= -sort(-a)
This is the sort (no pun intended) of things I frequent this list for. Not the
obnoxious religious claptrap C K Lester & co would like to ram down our throats.
jiri
6. Re: Feature for next Eu
Hello,
Matthew W Lewis wrote:
>I tend to just use a= -sort(-a)
This really is sweet. I'd never have thought of it on my own.
later,
Lewis Townsend
______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com
7. Re: Feature for next Eu
Jiri, I would never do that to you.
> -----Original Message-----
> From: Euphoria Programming for MS-DOS
> [mailto:EUPHORIA at LISTSERV.MUOHIO.EDU]On Behalf Of Jiri Babor
> Sent: Thursday, November 11, 1999 6:24 PM
> To: EUPHORIA at LISTSERV.MUOHIO.EDU
> Subject: Re: Feature for next Eu
>
>
> Matthew W Lewis wrote:
>
> > I tend to just use a= -sort(-a)
>
> This is the sort (no pun intended) of things I frequent this list
> for. Not the
> obnoxious religious claptrap C K Lester & co would like to ram
> down our throats.
>
> jiri
>
8. Re: Feature for next Eu
On Thu, 11 Nov 1999, you wrote:
> Matthew W Lewis wrote:
>
> > I tend to just use a= -sort(-a)
>
> This is the sort (no pun intended) of things I frequent this list for. Not the
> obnoxious religious claptrap C K Lester & co would like to ram down our
> throats.
>
> jiri
Jiri, I've seen your picture. You appear to be old enough to have learned
that the world doesn't revolve around you or your beliefs.
Once you realize that _your_ beliefs are religious claptrap as well,
you will find it easier to ignore the advertisements of others.
Irv - drink Fosters
Note: This sig has just forced poor jiri to go out and buy a Foster's.
9. Re: Feature for next Eu
Irv, your subtle Fosters campaign has been very funny. Thanks for the
laughs <hiccup>.
>
>Irv - drink Fosters
>
>Note: This sig has just forced poor jiri to go out and buy a Foster's.
P.S. I wanted to send this privately but couldn't immediately figure out
how. Sorry, EU-list!
10. Re: Feature for next Eu
> Irv - drink Fosters
> Irv - worship Fosters
And I thought only low lives and Australians drank the vile stuff.
jiri
11. Re: Feature for next Eu
Matthew W Lewis wrote:
>>> dsort (s) --> descending; eliminates 'call_func'
>>
>>Hmm -- I'd code "reverse(sort(s))" instead, but that probably isn't
>>quite as speed-efficient...
>
>I tend to just use a= -sort(-a)
But that won't always work -- compare() ALWAYS evaluates atoms as "less
than" a sequence, so switching signs won't necessarily perform a correct
descending sort.
To prove it, here's an example program which illustrates what happens:
------------
include misc.e
include sort.e
constant seq = {-3, {6,-12}, 7, {-6,12}}
? sort(seq) -- ascending sort
? -sort(-seq) -- descending sort, sign change
? reverse(sort(seq)) -- descending sort, reverse
------------
With a sign change descending sort, the atom values remain at the beginning
of the resulting sequence. What we get is not a sequence sorted in
descending order, but instead a kind of mish-mash. With reverse(), we truly
get a descending sort.
True, the sign change method will work perfectly fine if you're sorting all
atoms or all sequences. However, if you're planning to do a descending sort
a sequence containing atoms AND sequences, you'll have to use reverse().
All of which moves me a bit closer to agreeing with Rod, that an "official"
dsort() routine might be a good idea.
Hep yadda,
Gabriel Boehme
----------
The ultimate measure of a man is not where he stands in moments of comfort,
but where he stands at times of challenge and controversy.
Martin Luther King, Jr.
----------
12. Re: Feature for next Eu
Boehme, Gabriel wrote:
>> The 'remove' function.
>>
>>Basically, it would work like so...
>>
>> x = {1,2,3,4,5}
.>
>> x = remove (x,3) -- x is now {1,2,4,5}
>
>I would suggest calling it "delete" instead, to pair with your "insert"
>idea.
>
>Also, the "3" in this function is referring to what -- the index, or the
>sequence contents? I would assume it's the index, paralleling this with
>"insert", but I just want to be clear on what you're proposing...
My mistake; the second parameter would indeed be the index,
not the value.
>> insert (s,x,3) --> s[1..2] & x & s[3..length(s)]
>
>Bad parm order -- if you're going to have "delete(s,3)" (or "remove(s,3)",
>whatever), you should have the index parm in the same location for the
>paired routines. "insert(s,3,x)" would be more consistent, IMO.
Well, either way wouldn't bother me...
>> last (s,5) --> the last 5 elements of s
>
>?? I guess I don't see much need for this, although I admit it's kind of a
>pain to have to code s[length(s)-4..length(s)] instead. I guess I've never
>run into a situation where I've needed anything like this...
I've got something planned that could benefit from it; but
you're right, it's probably not something one would see
very often. Probably better left alone.
Rod Jackson
13. Re: Feature for next Eu
Roderick Jackson wrote:
> last (s,5) --> the last 5 elements of s
Long standing on my wish list is an 'end' operator, like this:
s = s[1..end]
instead of:
s = s[1..length(s)]
I suspect that this falls into the 'extra typing' clause, but it occurs
often enough that having an idiomatic way of doing in in Euphoria is
justified.
It's been mentioned a number of times that routine_id it disturbs the
'purity' of Euphoria. Now, I'm the first to whine that it's not the most
elegant construct in Euphoria. But, for me, it certainly has been one of the
most valuable new features in Euphoria.
Without it, writing EE was painful. All thee the event loops all had to be
written inside out. I suspect that's why virtually no one (including myself)
has used the TextGUI library.
Virtually all the GUI toolkits I've coded since the introduction of
routine_id have depended on it: WinMan, Win32Lib, Dos32Lib, and all flavors
of Llama. My interpreters (such as Eu) couldn't be written without it,
either.
All this is to say that a feature, be it routine_id/peek/poke, etc.)
shouldn't be dismissed merely because it's 'inelegant'.
-- David Cuny
14. Re: Feature for next Eu
- Posted by Everett Williams <rett at GVTC.COM>
Nov 12, 1999
-
Last edited Nov 13, 1999
On Fri, 12 Nov 1999 16:06:44 -0800, Cuny, David at DSS <David.Cuny at
DSS.CA.GOV> wrote:
>Roderick Jackson wrote:
>
>> last (s,5) --> the last 5 elements of s
>
>Long standing on my wish list is an 'end' operator, like this:
>
> s = s[1..end]
>
>instead of:
>
> s = s[1..length(s)]
>
>I suspect that this falls into the 'extra typing' clause, but it occurs
>often enough that having an idiomatic way of doing in in Euphoria is
>justified.
Also, very natural and clear.
>It's been mentioned a number of times that routine_id it disturbs the
>'purity' of Euphoria. Now, I'm the first to whine that it's not the most
>elegant construct in Euphoria. But, for me, it certainly has been one of the
>most valuable new features in Euphoria.
>
>Without it, writing EE was painful. All thee the event loops all had to be
>written inside out. I suspect that's why virtually no one (including myself)
>has used the TextGUI library.
>
>Virtually all the GUI toolkits I've coded since the introduction of
>routine_id have depended on it: WinMan, Win32Lib, Dos32Lib, and all flavors
>of Llama. My interpreters (such as Eu) couldn't be written without it,
>either.
>
>All this is to say that a feature, be it routine_id/peek/poke, etc.)
>shouldn't be dismissed merely because it's 'inelegant'.
>
>-- David Cuny
I didn't day that the capability wasn't needed, I said that it damages the
beauty and the CLARITY of the code...with as much emphasis as I
can put on the clarity. There is bound to be a cleaner method of
accomplishing this purpose. I don't have one in my head now, but I
am working on it.
Everett L.(Rett) Williams
rett at gvtc.com
15. Re: Feature for next Eu
Rod Jackson wrote:
>Now, I'm not demanding that this be made a new built-in
>function. Simply having it stuck in MISC.E would be
>fine (although honestly, it might be time for a
>SEQUENCE.E file.)
>
>The reason I ask for it is because I find myself having
>to rewrite the function for numerous programs and
>libraries. And of course, I usually make it local in
>any code I release... I figure that if *I* need it,
>other people's code that mine is to work with might
>have the function as well. Having several local copies
>of the same function, which is what I'm running into,
>usually shows that there's a better way to do things...
>
>In short, I think this would be a very nice addition to
>the next release's MISC.E file.
BTW, how's it going with the MATH.E idea? Status report, Mathew Houndsell?
With official MATH.E and SEQUENCE.E libraries, we can one day get rid of
MISC.E once and for all.
Lionel
______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com
16. Re: Feature for next Eu
Hey, Rod. I'm with you here, both on the "add syntax" thing and on the
SEQUENCE.E thing.
One function that is needed is the 'sum' function.
J.
-----Original Message-----
From: Roderick Jackson <rjackson at CSIWEB.COM>
To: EUPHORIA at LISTSERV.MUOHIO.EDU <EUPHORIA at LISTSERV.MUOHIO.EDU>
Date: Thursday, November 11, 1999 3:12 PM
Subject: Feature for next Eu
>Well, it looks like the 'add-this-syntax' thread has returned...
>
>I think I've made my views on most of the ideas presented in
>the thread known already ("no", for the most part.)
>
>However, I wish to present the case for something that should
>be simpler, a lot less controversial, and not requiring the
>grafting of a new paradigm into the language:
>
> The 'remove' function.
>
>Basically, it would work like so...
>
> x = {1,2,3,4,5}
>
> x = remove (x,3) -- x is now {1,2,4,5}
>
>Now, I'm not demanding that this be made a new built-in
>function. Simply having it stuck in MISC.E would be
>fine (although honestly, it might be time for a
>SEQUENCE.E file.)
>
>The reason I ask for it is because I find myself having
>to rewrite the function for numerous programs and
>libraries. And of course, I usually make it local in
>any code I release... I figure that if *I* need it,
>other people's code that mine is to work with might
>have the function as well. Having several local copies
>of the same function, which is what I'm running into,
>usually shows that there's a better way to do things...
>
>In short, I think this would be a very nice addition to
>the next release's MISC.E file.
>
>(BTW - as to what other routines to include in a
>SEQUENCE.E file, should the idea be taken seriously, I
>would suggest:
>
> insert (s,x,3) --> s[1..2] & x & s[3..length(s)]
> last (s,5) --> the last 5 elements of s
> reverse (s) --> moved from MISC.E
> sort (s) --> moved from SORT.E
> custom_sort (s) --> moved from SORT.E
> dsort (s) --> descending; eliminates 'call_func'
> bfind (x,s) --> find within a sorted sequence)
>
>
>Rod Jackson
>
__________________________________________
NetZero - Defenders of the Free World
Get your FREE Internet Access and Email at
http://www.netzero.net/download/index.html
17. Re: Feature for next Eu
On Fri, 12 Nov 1999, you wrote:
> > Irv - drink Fosters
> > Irv - worship Fosters
>
> And I thought only low lives and Australians drank the vile stuff.
> jiri
No,.
We Americans have been pioneering the 40 oz.'er of Malt Liquer for quite a
while now, and once those people crawl back out of the gutter, they go...hmm.
A Pint of Fosters tastes much better, still leaves the hangover, and comes in a
Pint...
Monty in Oregon --Drink Fosters (Live Forever ((in a pickeling jar))
PS...When there are editors that will block comment...why use that extremely
unreadable C type block commenting. I love the two little dashes...you can put
them anywhere, they are easy to remove, and can be parsed out by a
pre-processor very easily.
Why not just stick a couple of megs of blank space
in the executable (ex.exe or exw.exe, or .exu) for all of the future
"enhancements" those coming over from other languages want, that way we can
already know in advance how large the interpreters will get. Instead of a
"theoretical limit" some time in the future, we can say "hey, when it gets over
6.4 megs of size, we stop adding features (uh enhancements)" That way you guys
can just argue about which routine will fit in the last 2.463 k of the
interpeter.
And we can have a built in tcp/ip stack, gui, and picture of Rob and
Junko for calling fromthe "about" menu 
-
my 2 pennies.
m
18. Re: Feature for next Eu
Monty,
Man with tongue in cheek sometimes risks serious injury when falling
flat on face drunk. Foster's, 40 oz. lagers, whatever happened to good
old fashioned German dopel bocks(sp).
Everett L.(Rett) Williams
rett at gvtc.com
