1. Another No Vote On Strings (was Re: Stupid Newbie-sounding question.)
On Wed, 02 Jun 2004 14:19:39 -0700, "Michael J. Sabal"
<guest at RapidEuphoria.com> wrote:
>posted by: Michael J. Sabal <m_sabal at yahoo.com>
>
>Pete Lomax wrote:
>>
>> As I said before, I'll agree with an argument against this on
>> technical grounds. Non-string Eu is perfectly useable, and wonderfully
>> fast. I might favour string handling, but it is votes what count.
>>
>> Regards,
>> Pete
>> PS I can be bribed 
)
>>
>I've done a lot of work with strings in DOS, Win32Lib, and now GTK2.
>I can't say I've ever been stuck at a point where I absolutely needed
>a string type.
stuck? no. Dragging my left fingernail over the screen getting cramp
in my arm, serious eyestrain and taking five times longer than I
should while writing out each character of a 150-character string,
several times, that I am trying to process, yes.
(and I strongly suspect you've not had much cause to do that)
Another one I really enjoy is deleting five or six characters for each
one you want to keep, just to double-check that the file and pathname
in the ex.err is indeed the same as the file that exists right there
that just won't open (not that it often is).
> In fact, I can only think of one situation where a
>string type would even have been helpful: writing sequences to a file with
>human-readable strings to allow the file to be manipulated outside the
>program.
Well that's a .ini file, which you surely have no problem with, and
can easily be managed with or without strings, perhaps by a miniscule
amount easier with strings, but nothing to gripe over.
> However, I now would consider that to be a very dangerous
>programming practice, ymmv. Add a new type or not, it really doesn't
>matter to me.
>At the same time, I believe the puts() statement checks for strings
>before executing, so I expect there already is some level of string
>support already in the language.
Well, without confirming that either way, if you defined or somehow
calculated
weights={74,111,104,110}
and then got "John" displayed, you might feel different.
Yes?
No?
Maybe?
(apologies for the spoiler space, felt I needed it there, just hope it
was enough...)
(actually, of course, puts does no such checking. It will take an atom
or a sequence, but puts(1,{74.5,104.1}) will display "Jh", and
puts(1,{{3,74.5},104.1}) just crashes.).
>Like I said, either way it doesn't matter to me.
Fair enough, another No vote then.
While I vote Yes, I can live without it too, just the "no use
whatsoever" brigade rub me up the wrong way.
Those "I prefer speed" chaps are a much nicer bunch tho )
Regards,
Pete
2. Re: Another No Vote On Strings (was Re: Stupid Newbie-sounding question.)
On 2 Jun 2004, at 23:49, Pete Lomax wrote:
>
>
> On Wed, 02 Jun 2004 14:19:39 -0700, "Michael J. Sabal"
> <guest at RapidEuphoria.com> wrote:
>
> >posted by: Michael J. Sabal <m_sabal at yahoo.com>
> >
> >Pete Lomax wrote:
> >>
> >> As I said before, I'll agree with an argument against this on
> >> technical grounds. Non-string Eu is perfectly useable, and wonderfully
> >> fast. I might favour string handling, but it is votes what count.
Votes count with RDS?
What about associated lists?
type[1] = "s"
data[1] = "John"
type[2] = "i"
data[2] = 47
Now, a cute lil print routine to look at type and do appropriately unto data,
and problem is solved?
Kat
3. Re: Another No Vote On Strings (was Re: Stupid Newbie-sounding question.)
On Wed, 2 Jun 2004 20:23:25 -0500, Kat <gertie at visionsix.com> wrote:
>> On Wed, 02 Jun 2004 14:19:39 -0700, "Michael J. Sabal"
>> <guest at RapidEuphoria.com> wrote:
>>
>> >posted by: Michael J. Sabal <m_sabal at yahoo.com>
>> >
>> >Pete Lomax wrote:
>> >>
>> >> As I said before, I'll agree with an argument against this on
>> >> technical grounds. Non-string Eu is perfectly useable, and wonderfully
>> >> fast. I might favour string handling, but it is votes what count.
>
>Votes count with RDS?
YES. You not been paying attention?
Fair enough, I guess RC has a block vote of around 5000 )
(and NO STRINGS seems to be winning by a landslide even without that)
It *IS* rather rare, but RC folded on x[1..$] just last year.
That was asked for HERE, and you will see that in 2.5
(Only, I guess, if you buy it, that is ;--)))
Arguing a point/complaining loudly/voicing your opinions, but just
getting nowhere can be rather disheartening.
Buttoning your lip, and then wondering why no-one ever listens to you
is just plain stupid, though.
>What about associated lists?
>type[1] = "s"
>data[1] = "John"
>
>type[2] = "i"
>data[2] = 47
>
>Now, a cute lil print routine to look at type and do appropriately unto data,
>and problem is solved?
Maybe you missed my fudge on that:
http://www.listfilter.com/cgi-bin/esearch.exu?fromMonth=5&fromYear=9&toMonth=6&toYear=9&postedBy=lomax&keywords=tInt
(Crikey, can't believe that is only 31st May; feels much longer ago)
Surely you have a routine that will do a *fair* job, as do I:
(http://palacebuilders.pwp.blueyonder.co.uk/eppp.html)
A native string type in Eu would make it MUCH better, but would, of
course, make Eu slower.
I'm perfectly OK that native string handling, which I want, has been
discussed, and the consensus appears to be it will not go in.
Such is life
Regards,
Pete
PS but I'm probably a bit more devious that you give me credit for
4. Re: Another No Vote On Strings (was Re: Stupid Newbie-sounding question.)
Pete Lomax wrote:
>
> I'm perfectly OK that native string handling, which I want, has been
> discussed, and the consensus appears to be it will not go in.
> Such is life
>
I don't think a vote has anything to do with this really, since we
already know that the language design will not accomodate ANY more
types. However, it is an interesting discussion and may be useful
to someone who is, perhaps at this very moment, writing the language
which will replace Euphoria.
Irv
