1. Stupid Newbie-sounding question.
Ok..I know this is a stupid newbie-sounding question....and I've always avoided
this issue, because I didn't know how to do it...
But, this time, it seems unavoidable...
I have a sequence of variables, which contains atoms, integers, sequences, text,
etc...
I am trying to save each variable on separate lines of a file, that could easily
be edited....the data file would look simliar to this..
2341 NAME John
3432 AGE 34
2341 FLAGS {a sequence of flags}
etc..
anyway..here's the problem i'm having...ok..without using a loop..it's easy to
save that to a file..like this...
puts(id,sprint(variable_for_idnumber))
puts(id," ")
puts(id,variable_for_what_variable_this_id)
puts(id," ")
puts(id,variable_for_the_variable_value)
puts(id,"\n")
ok..here's where i have my problem...as far as "flags" and "age"..it's easy...I
can say..
if atom(variable_for_the_variable_value) then
print(id,sprint(variable_for_the_variable_value)
else
puts(id,variable_for_the_variable_value)
end if
but the problem with that is that it prints "John" as a string of the ascii
codes, instead of an easily editable "John"..
if i add if sequence() it counts "John" as a sequence, just like the sequence
of flags..
so my question is...
how i can (within a loop) tell it to evaluate whether to puts or print?
bah..told you it was a stupid newbie question
Michelle Rogers
2. Re: Stupid Newbie-sounding question.
Michelle wrote:
> but the problem with that is that it prints "John" as a string of the ascii
> codes,
> instead of an easily editable "John"..
> if i add if sequence() it counts "John" as a sequence, just like the
> sequence of
> flags..
> so my question is...
> how i can (within a loop) tell it to evaluate whether to puts or print?
>
> bah..told you it was a stupid newbie question
>
> Michelle Rogers
>
Not stupid at all.
What the Eu docs call "flexible", I call a design flaw.
Euphoria cannot tell the difference between "John" and {74,111,104,110}
where the latter might be a series of integers or flags or whatever.
The easy way is to not try to write a universal "print" function which
has to somehow detect how things are supposed to be printed,
but just use printf(.. with the appropriate params to print the entire
sequence at one time. Use \n as appropriate to break it up into lines.
If your flags are always either 0 or 1, (which aren't printable characters),
you might look for 0 or 1 in every sequence, and if found, consider this to
be a sequence of flags, otherwise print as a string.
Irv.
3. Re: Stupid Newbie-sounding question.
irv mullins wrote:
>
>
> Michelle wrote:
>
> > but the problem with that is that it prints "John" as a string of the ascii
> > codes,
> > instead of an easily editable "John"..
> > if i add if sequence() it counts "John" as a sequence, just like the
> > sequence of
> > flags..
> > so my question is...
> > how i can (within a loop) tell it to evaluate whether to puts or print?
> >
> > bah..told you it was a stupid newbie question
> >
> > Michelle Rogers
> >
>
> Not stupid at all.
> What the Eu docs call "flexible", I call a design flaw.
> Euphoria cannot tell the difference between "John" and {74,111,104,110}
> where the latter might be a series of integers or flags or whatever.
>
> The easy way is to not try to write a universal "print" function which
> has to somehow detect how things are supposed to be printed,
> but just use printf(.. with the appropriate params to print the entire
> sequence at one time. Use \n as appropriate to break it up into lines.
>
> If your flags are always either 0 or 1, (which aren't printable characters),
> you might look for 0 or 1 in every sequence, and if found, consider this to
> be a sequence of flags, otherwise print as a string.
>
> Irv.
>
bah...well..i will be (probably forever) adding variables to the sequence...and
no...all of the sequences will not be "flags" that may be 0 or 1..
As a matter of fact, some sequences may be sequences of text...
I was trying to make it so that I never had to change the read/write procedures,
even though I would be adding variables on...
You seem to be saying that it may be impossible to do this? That I may have to
manually read/write every line, instead of making a loop? So, that means that
each time I add a new variable to the sequence, I have to also go add it to the
read/write procedures...bah..was trying to get around that.
hmm..*thinking "out loud"*...this isn't the ideal way to do it..but maybe I
could assign a fourth parameter to each "variable type" which is a 0 or a 1 to
tell if the variable should be holding a string or just plain text...well..or
even a 2 for atoms, I guess...although that I can check for
4. Re: Stupid Newbie-sounding question.
Michelle wrote:
>
>
> bah...well..i will be (probably forever) adding variables to the
> sequence...and no...all
> of the sequences will not be "flags" that may be 0 or 1..
> As a matter of fact, some sequences may be sequences of text...
> I was trying to make it so that I never had to change the read/write
> procedures, even
> though I would be adding variables on...
> You seem to be saying that it may be impossible to do this? That I may have
> to manually
> read/write every line, instead of making a loop? So, that means that each
> time I add
> a new variable to the sequence, I have to also go add it to the read/write
> procedures...bah..was
> trying to get around that.
>
> hmm..*thinking "out loud"*...this isn't the ideal way to do it..but maybe I
> could assign
> a fourth parameter to each "variable type" which is a 0 or a 1 to tell if the
> variable
> should be holding a string or just plain text...well..or even a 2 for atoms, I
> guess...although
> that I can check for
You could add a "tag" to each variable, to indicate the type:
For example, use 0 to indicate a string, -1 a flag, and 1 an integer:
Then your variables would look like:
{0,"John"} -- var[2] is a string
{-1,{1,1,0,1}} -- var[2] contains flags: TRUE, TRUE, FALSE, TRUE
{1,{1,2,3,4,5}} -- var[2] contains integers 1,2,3,4,5
Then your routine could pick off the "tag" and send the rest to the
appropriate print formatting routine.
Kind of awkward, because you also have to remember to add the tag when
the variable is created, and have to handle the data separately from the
tag when doing anything with or to the variables - such as enter strings,
compare strings, flags, etc. In the long run, probably more work than
just modifying a single format string to use with a printf() statement.
Irv
5. Re: Stupid Newbie-sounding question.
Irv wrote:
> Michelle wrote:
>
>> but the problem with that is that it prints "John" as a string of the ascii
>> codes,
>> instead of an easily editable "John"..
>> if i add if sequence() it counts "John" as a sequence, just like the
>> sequence of
>> flags..
>> so my question is...
>> how i can (within a loop) tell it to evaluate whether to puts or print?
>>
>> bah..told you it was a stupid newbie question
>>
>> Michelle Rogers
>
> Not stupid at all.
> What the Eu docs call "flexible", I call a design flaw.
> Euphoria cannot tell the difference between "John" and {74,111,104,110}
> where the latter might be a series of integers or flags or whatever.
[snip]
Yes, like "integer" is a special type of atom, there definitely should
be a "string" datatype, which is a special type of sequence.
At the first glance, it might look as if an additional data type would
make Euphoria more complicated, but (latest) at the second glance it
is clear that Euphoria would become *much* more flexible (see Michelle's
problem here), simpler, safer, and better readable.
Regards,
Juergen
6. Re: Stupid Newbie-sounding question.
Michelle, Irv and Juergen have burst my bubble.
I had figured that, if I worked at it long enough, I could master the
way Euphoria handles this sort of thing. Answer: it doesn't.
Allen
7. Re: Stupid Newbie-sounding question.
Allen V Robnett wrote:
>
> Michelle, Irv and Juergen have burst my bubble.
> I had figured that, if I worked at it long enough, I could master the
> way Euphoria handles this sort of thing. Answer: it doesn't.
And that is the #1 cause of errors and problems when using Euphoria.
Strangely, some languages handle this with no difficulty - see Lua,
for example. I we are going to have data types at all, then surely
a string type would be one of the most important and frequently used.
Irv
8. Re: Stupid Newbie-sounding question.
Juergen Luethje wrote:
>
>
> Irv wrote:
>
> > Michelle wrote:
> >
> >> but the problem with that is that it prints "John" as a string of the ascii
> >> codes,
> >> instead of an easily editable "John"..
> >> if i add if sequence() it counts "John" as a sequence, just like the
> >> sequence
> of
> >> flags..
> >> so my question is...
> >> how i can (within a loop) tell it to evaluate whether to puts or print?
> >>
> >> bah..told you it was a stupid newbie question
> >>
> >> Michelle Rogers
> >
> > Not stupid at all.
> > What the Eu docs call "flexible", I call a design flaw.
> > Euphoria cannot tell the difference between "John" and {74,111,104,110}
> > where the latter might be a series of integers or flags or whatever.
>
> [snip]
>
> Yes, like "integer" is a special type of atom, there definitely should
> be a "string" datatype, which is a special type of sequence.
>
> At the first glance, it might look as if an additional data type would
> make Euphoria more complicated, but (latest) at the second glance it
> is clear that Euphoria would become *much* more flexible (see Michelle's
> problem here), simpler, safer, and better readable.
>
> Regards,
> Juergen
>
Well, I can see your problem, and I agree that that adding "string" would
do so, I must say something. There is a way to tell if it is a string or
not. In your program, ""'s and {},s mean the same thing, so they reccomend
using ""'s for text(a string of typeable characters), and {}'s for other
sequences. However, for a way to find out, you can make two types, like this:
type char(object x)
if integer(x) then
if (x >= 'a' and x <= 'z') or -- all lowercase characters
(x >= 'A' and x <= 'Z') or -- all uppercase characters
(x >= '0' and x <= '9') or -- all numericial characters
find(x, "?<>,./\\|[]{}`" & --\ all of the other symbols
"~!@#$%^&*()-=_" & --- that you can type, even
"+:\'\"\t\r\n" & {32}) then --/ with "Shift" held down.
return 1 -- return true, since only one char. is checked.
end if
elsif sequence(x) -- if x is not an integer
return (length(x) = 1 and char(x[1]))
end if
end type
global type string(sequence x)
for elem = 1 to length(x) do
if not char(x[elem]) then
return 0
end if
end for
return 1
end type
-------------------------------------------------
| Name: | Nicholas Koceja |
| Occupation: | Computer genius |
| Programs in: | BASIC, HTML, Euphoria |
| Programs Completed: | 3-5 |
| Programs Incomplete: | 20-30 |
| Operating System: | Windows XP |
-------------------------------------------------
9. Re: Stupid Newbie-sounding question.
>Juergen Luethje wrote:
<snip>
>> At the first glance, it might look as if an additional data type would
>> make Euphoria more complicated,
Adding a string type takes the number of cases for the "&" operator
from 8 to 19, without considering unicode strings. Just so you know. I
agree that string types might be nice, but they are far from trivial.
>Nicholas Koceja wrote:
<snip>
> if (x >= 'a' and x <= 'z') or -- all lowercase characters
> (x >= 'A' and x <= 'Z') or -- all uppercase characters
> (x >= '0' and x <= '9') or -- all numericial characters
> find(x, "?<>,./\\|[]{}`" & --\ all of the other symbols
> "~!@#$%^&*()-=_" & --- that you can type, even
> "+:\'\"\t\r\n" & {32}) then --/ with "Shift" held down.
<snip>
Yuk. The above will not cope with multinational character sets either.
The following is much simpler, faster and better:
type string(object s)
object c
if not sequence(s) then return 0 end if
for i=1 to length(s) do
c=s[i]
if not integer(c) or c<0 or c>255 then return 0 end if
end for
return 1
end type
Regards,
Pete
10. Re: Stupid Newbie-sounding question.
>> > Michelle wrote:
>> >
>> >> but the problem with that is that it prints "John" as a string of the
>> >> ascii codes,
>> >> instead of an easily editable "John"..
Michelle, before you dig a hole, if I'm not already too late, you may
like to try a quick play with my pretty print routine:
http://palacebuilders.pwp.blueyonder.co.uk/eppp.html
Eg:
include ppp.e
pp("fred")
pp({1,2,3,4,5})
will print:
"fred"
{1,2,3,4,5}
without needing any extra hints.
Regards,
Pete
11. Re: Stupid Newbie-sounding question.
Pete wrote:
>> Juergen Luethje wrote:
> <snip>
>>> At the first glance, it might look as if an additional data type would
>>> make Euphoria more complicated,
>
> Adding a string type takes the number of cases for the "&" operator
> from 8 to 19, without considering unicode strings. Just so you know. I
> agree that string types might be nice, but they are far from trivial.
I think you are describing the point of view of the developer of the
language, right? That's interesting. I didn't know that, but I truely
believe that implementing a string datatype will mean considerable work.
Well, I am willing to pay some extra $ for such an enhancement.
>From the point of view of the user of the language, in most (if not all)
cases the "&" operator should work with a built-in string type, like it
currently works with our user-defined string types.
[snipped in agreement]
Regards,
Juergen
12. Re: Stupid Newbie-sounding question.
My approach to this problem:
We need a new keyword; "of".
Usage:
type char ( integer c )
-- return 1 valid character, 0 otherwise
end type
--myStr is a string
sequence of char myStr
It is an extension to the type checking system on sequences, and is applied
whenever an element of the sequence is changed. The existing type checks are
slow because they have applied to the whole sequence whenever a single
element is changed. This "of" typing would only check the elements that are
changed in the sequence.
If you have a complex data structure list, you could have:
type myDataStructure( sequence s)
--return 1 if valid myDataStructure, 0 otherwise
end type
--master_list is a 1-dimensional array of myDataStructures
sequence of myDataStructure master_list
This would not break any existing code, as "sequence" without an 'of' would
mean no restrictions.
Multi-dimensional arrays are also possible:
--2d array of integers
sequence of sequence of integer 2d_array
type textpict_line( sequence s)
if length(s) = 80 then return 1
else return 0
end if
end type
--2d array where the length of each line is fixed, and consists of
characters
sequence of textpict_line of char text_picture
Rules:
--------
1. Only types that have sequence as a base can be listed before the last
type.
So: sequence of sequence of char is ok.
and: sequence of char of sequence is NOT okay.
2. Whenever an element of a type is changed, the type that the element
should be is checked. The rest of the variable was not affected, don't check
it.
3. If using a custom type as the base, eg: textpict_line of char text_line,
the textpict_line type checking will only be invoked when the length of the
sequence changes. (If the of keyword is not used, it will be invoked as
normal)
4. If casting between types: ie - generic sequence to sequence of char, then
a full type check will be performed: The base type will be checked first,
then the element type will be checked against each element.
Suggestion #2:
Allow some simple type defines, a la c/c++.
This could be done without adding extra code, perhaps like so:
type rgb (sequence of integer c)
return length(c) = 3
end type
type rgb_map ( sequence of sequence of rgb x)
return 1
end type
If no extra checking has to be done, then the type just returns 1.
That's my take on the situation. I can't see any problems with this right
now, and Rob, I'd like to hear your thoughts on this.
Cheers.
MrTrick
>From: Juergen Luethje <j.lue at gmx.de>
>Reply-To: EUforum at topica.com
>To: EUforum at topica.com
>Subject: Re: Stupid Newbie-sounding question.
>Date: Mon, 31 May 2004 11:35:27 +0200
>
>
>Pete wrote:
>
> >> Juergen Luethje wrote:
> > <snip>
> >>> At the first glance, it might look as if an additional data type would
> >>> make Euphoria more complicated,
> >
> > Adding a string type takes the number of cases for the "&" operator
> > from 8 to 19, without considering unicode strings. Just so you know. I
> > agree that string types might be nice, but they are far from trivial.
>
>I think you are describing the point of view of the developer of the
>language, right? That's interesting. I didn't know that, but I truely
>believe that implementing a string datatype will mean considerable work.
>Well, I am willing to pay some extra $ for such an enhancement.
>
> >From the point of view of the user of the language, in most (if not all)
>cases the "&" operator should work with a built-in string type, like it
>currently works with our user-defined string types.
>
>[snipped in agreement]
>
>Regards,
> Juergen
>
>
>
>
13. Re: Stupid Newbie-sounding question.
Patrick Barnes wrote:
<snip code>
> That's my take on the situation. I can't see any problems with this right
> now, and Rob, I'd like to hear your thoughts on this.
The real problem is that it isn't all that useful because it only checks on
assignment.
Why does Euphoria have different functions for outputting variables,
depending on their type? If you choose the wrong one, you get a crash.
Other languages handle this transparently.
For example, if Euphoria actually used its type system, you could
do this:
a = 1
b = 3.1415
c = "Foo bar"
d = {1,4,7,234}
print(a,b,c,d)
All 4 should print the way you expect them to, IOW, 'c' doesn't look
like a series of strange numbers, and 'd' doesn't try to print as
a 4-letter word.
I believe languages such as Lua and Python handle this without any
problem, and they are untyped languages. Surely a language which forces
you to declare specific types for a variable should actually make use
of that information, shouldn't it?
Why does Euphoria have any types at all, if it isn't going to use them to
make the programmers job easier, and to reduce errors?
Irv
14. Re: Stupid Newbie-sounding question.
>From: irv mullins <guest at RapidEuphoria.com>
>Subject: Re: Stupid Newbie-sounding question.
> > That's my take on the situation. I can't see any problems with this
>right
> > now, and Rob, I'd like to hear your thoughts on this.
>
>The real problem is that it isn't all that useful because it only checks on
>assignment.
Actually, I guess it's a thread hijack. I wasn't trying to address the
string debate in terms of printing... Like I said in the trace thread, I
don't think it matters that much unless you're tracing.
>Why does Euphoria have different functions for outputting variables,
>depending on their type? If you choose the wrong one, you get a crash.
>Other languages handle this transparently.
>
>For example, if Euphoria actually used its type system, you could
>do this:
>
>a = 1
>b = 3.1415
>c = "Foo bar"
>d = {1,4,7,234}
>
>print(a,b,c,d)
Well, the printf function works properly, for what that's worth.
>All 4 should print the way you expect them to, IOW, 'c' doesn't look
>like a series of strange numbers, and 'd' doesn't try to print as
>a 4-letter word.
Okay, that is fair enough.... This could actually address the types a bit
though (not var_arg_lists, that is another thing altogether)
Consider: If a variable is "cast" to a generic type:
type char( integer c)
return (c <= 0) and (c >= 255) --Ignoring unicode matters, this is just
an example.
end type
type string ( sequence of char s)
return 1
end type
procedure print_variable( object x )
if atom(x) then --Print a number
print(1,x)
else if string(x) then --Print a string
puts(1, x)
else --Print a generic sequence
print(1,x)
end if
end procedure
Now, in the implementation of this, there would be some kind of tag on the
variable (inside the interpreter) that would remain attached to the variable
even if it was cast to a generic type (object, in this case). After all, the
data hasn't changed. If any assignment is made to the variable, then there
must be some checks as to whether the variable should retain its tag. So, no
matter how complex the type, a type-check on a variable that has been cast
to generic but not modified is trivial.
>I believe languages such as Lua and Python handle this without any
>problem, and they are untyped languages. Surely a language which forces
>you to declare specific types for a variable should actually make use
>of that information, shouldn't it?
After typing out the example above, I see what you mean... in that with
default behaviour the above function would mistakenly take a 1-dimensional
sequence of integers below 255 for a string, and print it. This *could* be
fixed by creating a new built-in function that would check the tag on the
variable, and return a 1 if the variable has that tag.
procedure print_variable( object x )
if atom(x) then --Print a number
print(1,x)
else if variable_tag(x, "string") then --Print a string
puts(1, x)
else --Print a generic sequence
print(1,x)
end if
end procedure
So, the variable_tag function would only check if the object x is already
validated as a string, and would not attempt to cast from any other type.
>Why does Euphoria have any types at all, if it isn't going to use them to
>make the programmers job easier, and to reduce errors?
Because Rob is only one man, and has the same blinkers (think racehorses) as
all of us do. Obviously no one person has a perfect paradigm, but by working
together we can improve things.
MrTrick
15. Re: Stupid Newbie-sounding question.
Patrick Barnes wrote:
> My approach to this problem:
>
> We need a new keyword; "of".
> Usage:
>
> type char ( integer c )
> -- return 1 valid character, 0 otherwise
> end type
>
> --myStr is a string
> sequence of char myStr
>
> It is an extension to the type checking system on sequences, and is applied
> whenever an element of the sequence is changed. The existing type checks are
> slow because they have applied to the whole sequence whenever a single
> element is changed. This "of" typing would only check the elements that are
> changed in the sequence.
This idea has come up before.
I haven't ruled it out.
I was quite interested in this a few years ago.
As I recall, the thing that made me lose some
interest was the fear that few people
would use it, and it wouldn't provide a great deal
of benefit to those who did use it. It would
also make the language more complicated,
not to mention verbose.
In other languages, you need types in order to
define the layout of your data in memory.
In Euphoria, a type is just a documentation
and debugging aid, and few people seem to
bother defining them.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
16. Re: Stupid Newbie-sounding question.
Patrick Barnes wrote:
> Now, in the implementation of this, there would be some kind of tag on the
> variable (inside the interpreter) that would remain attached to the
> variable even if it was cast to a generic type (object, in this case).
For the case of literals and expressions, there is no tag to look up. For
example:
? "a string"
? aString & " another string"
In these cases, the best Euphoria can do is determine that they are both
sequences.
-- David Cuny
17. Re: Stupid Newbie-sounding question.
>From: Robert Craig <guest at RapidEuphoria.com>
>Subject: Re: Stupid Newbie-sounding question.
>This idea has come up before.
>I haven't ruled it out.
>I was quite interested in this a few years ago.
>As I recall, the thing that made me lose some
>interest was the fear that few people
>would use it, and it wouldn't provide a great deal
>of benefit to those who did use it. It would
>also make the language more complicated,
>not to mention verbose.
>
>In other languages, you need types in order to
>define the layout of your data in memory.
>In Euphoria, a type is just a documentation
>and debugging aid, and few people seem to
>bother defining them.
>
Um, that's like saying "I don't need to replace the broken bicycle, no one
is using it"...
The main issue with Euphoria's sequences is that they're so damn flexible
that it can be confusing!
Issue #1:
function myFunc(sequence r1, sequence r2, sequence r3)
Okay Rob... What sort of structure do these sequences have to have? I don't
know! If we had the ability to use stronger typing, then function
myFunc(text_picture r1, string r2, flag_list r3) would make a lot more
sense. I could go and look at the type declaration, and figure out what to
pass to the function.
People don't use the types like this at the moment because it's so damn
computationally expensive for sequences.
Issue #2:
Run-time slicing and sequence errors are my main cause of problems. The
primary error I make is missing a set of braces around a concatenation
command....
type vector(sequence s)
return length(s) = 2 and atom(s[1]) and atom(s[2])
end type
type vector_list(sequence of vector s)
return 1
end type
vector_list vectors
vectors = getVectors()
Say I wanted to add a vector to that list (and I'm not quite paying enough
attention)
vectors &= NewVector(30, 20)
Hmm... Unbeknownst to me, the last two elements of vector are now 30 and
20... not the last element being {30,20} like i'd hoped.
Unfortunately, I only find out when I try to reference it, which may be a
long way from this error. At least with differential checking, an error
would show up at that point of error, and I can fix it quicker.
While we're talking about types, it would be nice if:
Should the checked variable be an incompatible type with the parameter, it
will just return 0, not crash the interpreter:
type myStruct (sequence s)
if -------- return 1
else return 0
end type
object x
...
x = 0
...
if myStruct(x) then return 1 end if
...
This crashes.
That would actually help "of"s case.
I think that having types like this would make the language *easier* to
understand, not more complex. Especially, it would make someone elses code
easier to read.
MrTrick
18. Re: Stupid Newbie-sounding question.
Patrick Barnes wrote:
>
> >From: Robert Craig <guest at RapidEuphoria.com>
> >Subject: Re: Stupid Newbie-sounding question.
> >This idea has come up before.
> >I haven't ruled it out.
> >I was quite interested in this a few years ago.
> >As I recall, the thing that made me lose some
> >interest was the fear that few people
> >would use it, and it wouldn't provide a great deal
> >of benefit to those who did use it. It would
> >also make the language more complicated,
> >not to mention verbose.
> >
> >In other languages, you need types in order to
> >define the layout of your data in memory.
> >In Euphoria, a type is just a documentation
> >and debugging aid, and few people seem to
> >bother defining them.
> >
> Um, that's like saying "I don't need to replace the broken bicycle, no one
> is using it"...
>
> The main issue with Euphoria's sequences is that they're so damn flexible
> that it can be confusing!
> Issue #1:
> function myFunc(sequence r1, sequence r2, sequence r3)
>
> Okay Rob... What sort of structure do these sequences have to have? I don't
> know! If we had the ability to use stronger typing, then function
> myFunc(text_picture r1, string r2, flag_list r3) would make a lot more
> sense. I could go and look at the type declaration, and figure out what to
> pass to the function.
> People don't use the types like this at the moment because it's so damn
> computationally expensive for sequences.
This is true. And there is the trade off - speed & flexibility against
structure and complexity. Think of it in terms of a bicycle without
training wheels and one with training wheels
RDS has chosen speed. Meaning that the coder has more responsibility to
provide quality assurance than the translator does. Yes this does mean
more work for the coder and better discipline.
Would you prefer a slower Euphoria if it had structures, strings and
an improved type system? If so, you may have to wait until v2.5 comes out
and someone adds these to the slower version.
> Issue #2:
> Run-time slicing and sequence errors are my main cause of problems. The
> primary error I make is missing a set of braces around a concatenation
> command....
> type vector(sequence s)
> return length(s) = 2 and atom(s[1]) and atom(s[2])
> end type
> type vector_list(sequence of vector s)
> return 1
> end type
> vector_list vectors
> vectors = getVectors()
> Say I wanted to add a vector to that list (and I'm not quite paying enough
> attention)
> vectors &= NewVector(30, 20)
> Hmm... Unbeknownst to me, the last two elements of vector are now 30 and
> 20... not the last element being {30,20} like i'd hoped.
>
Learn to love the append() function.
'append' adds ONE element, the source, to a sequence. newlength = oldlength +
1.
'&' adds all the source elements to a sequence. newlength = oldlength +
sourcelength.
Another way of visualizing this is that '&' is like joining together two
sets of train carriges together. 'append' joins one new carriage and places
all the new stuff into that new carriage.
> Unfortunately, I only find out when I try to reference it, which may be a
> long way from this error. At least with differential checking, an error
> would show up at that point of error, and I can fix it quicker.
This is also an arguement for some type of 'assert' system that would help
trap errors during development and could be automatically removed for the
release version.
> While we're talking about types, it would be nice if:
> Should the checked variable be an incompatible type with the parameter, it
> will just return 0, not crash the interpreter:
> type myStruct (sequence s)
> if -------- return 1
> else return 0
> end type
>
> object x
> ...
> x = 0
> ...
> if myStruct(x) then return 1 end if
> ...
> This crashes.
>
> That would actually help "of"s case.
>
> I think that having types like this would make the language *easier* to
> understand, not more complex. Especially, it would make someone elses code
> easier to read.
Ummmm? Why not code so that it works?
type myStruct (object s)
if sequence(s) return 1
else return 0
end type
--
Derek Parnell
Melbourne, Australia
19. Re: Stupid Newbie-sounding question.
>From: Derek Parnell <guest at RapidEuphoria.com>
>Subject: Re: Stupid Newbie-sounding question.
> > Okay Rob... What sort of structure do these sequences have to have? I
>don't
> > know! If we had the ability to use stronger typing, then function
> > myFunc(text_picture r1, string r2, flag_list r3) would make a lot more
> > sense. I could go and look at the type declaration, and figure out what
>to
> > pass to the function.
> > People don't use the types like this at the moment because it's so damn
> > computationally expensive for sequences.
>
>This is true. And there is the trade off - speed & flexibility against
>structure and complexity. Think of it in terms of a bicycle without
>training wheels and one with training wheels
>
>RDS has chosen speed. Meaning that the coder has more responsibility to
>provide quality assurance than the translator does. Yes this does mean
>more work for the coder and better discipline.
Well, if you're writing a library that other people would use, I would say
that it's the library programmer's responsibility to check the data passed
to it.
I think that types could be implemented in a way that would run *faster*
than without. Without these types, libraries and functions need to check
that the data passed to it is valid. This results in redundant checks.
Having types supplemented with the "of" command speeds it up many-fold over
the old type system, because data will only be checked that has changed. And
because that if a variable is of a certain type, it is *known* already that
it is valid, so it won't need to be checked multiple times.
> > Issue #2:
> > Run-time slicing and sequence errors are my main cause of problems. The
> > primary error I make is missing a set of braces around a concatenation
> > command....
>Learn to love the append() function.
I know, but '&' uses less keys... (my bad, I know).
It's still a valid argument (slicing and seq errors). It's very easy to
misplace a subscript, or make some error if you are breaking up and
reassembling a sequence in one line.
> > Unfortunately, I only find out when I try to reference it, which may be
>a
> > long way from this error. At least with differential checking, an error
> > would show up at that point of error, and I can fix it quicker.
>
>This is also an arguement for some type of 'assert' system that would help
>trap errors during development and could be automatically removed for the
>release version.
Well, type checking could be turned off for release. The user won't know how
to fix a code error, no matter how helpful the error message.
>Ummmm? Why not code so that it works?
>
> type myStruct (object s)
> if sequence(s) return 1
> else return 0
> end type
Because it is non-intuitive.
Because there is no shortcut for 'and' in this form:
type myStruct ( object s )
return sequence(s) and length(s) = 4 and integer(s[1])
end type
Crashes if not a sequence.
Derek, if someone passes a badly-formed sequence into one of the Win32lib
functions, the error is stated to be inside that function, when in fact it
was the fault of the other programmer. The trace window or ex.err may show
the value of the sequence (or maybe only the first part), but it may not be
easy to elucidate that a) the error resulted from their own mistake. b)
Exactly what was wrong with that sequence they passed, anyway.
MrTrick
20. Re: Stupid Newbie-sounding question.
>This is true. And there is the trade off - speed & flexibility against
>structure and complexity. Think of it in terms of a bicycle without
>training wheels and one with training wheels
>
>RDS has chosen speed. Meaning that the coder has more responsibility to
>provide quality assurance than the translator does. Yes this does mean more
>work for the coder and better discipline.
So does that mean we peek and poke everything directly to memory?
None of those fancy atoms for me! I like dealing with my floats in raw
IEEE form!
MrTrick
21. Re: Stupid Newbie-sounding question.
Derek Parnell wrote:
> This is true. And there is the trade off - speed & flexibility against
> structure and complexity. Think of it in terms of a bicycle without
> training wheels and one with training wheels
Let's ignore for the moment the fact that certain kinds of structure
and complexity may actually make the coding experience more flexible
and less complex, and tackle the issue of speed:
> RDS has chosen speed. Meaning that the coder has more responsibility to
> provide quality assurance than the translator does. Yes this does mean
> more work for the coder and better discipline.
>
> Would you prefer a slower Euphoria if it had structures, strings and
> an improved type system? If so, you may have to wait until v2.5 comes out
> and someone adds these to the slower version.
My impression is that RDS cares far too much about speed, and too little
for other factors which may be more important to the bulk of users.
That might explain why the same languages which RDS proclaims to be
"10 to 30 times" slower than Euphoria also happen to be 10 to 30
(or maybe 100) times more popular.
And even if speed was an overriding concern when Euphoria was
designed, surely it isn't all that important anymore, when even
the cheap WalMart price-busters run at 2.7 ghz.
Irv
22. Re: Stupid Newbie-sounding question.
Patrick Barnes wrote:
>
> >This is true. And there is the trade off - speed & flexibility against
> >structure and complexity. Think of it in terms of a bicycle without
> >training wheels and one with training wheels
> >
> >RDS has chosen speed. Meaning that the coder has more responsibility to
> >provide quality assurance than the translator does. Yes this does mean more
> >work for the coder and better discipline.
>
> So does that mean we peek and poke everything directly to memory?
> None of those fancy atoms for me! I like dealing with my floats in raw
> IEEE form!
Now you're getting it
But seriously, folks... the current internal structures used by Euphoria
mean that it is quick for Euphoria to distinguish between integers, atoms,
and sequences, but if you add any more 'native' types, things are going
to slow down a lot. RDS has given more priority to the speed aspect of
Euphoria than to providing assistance to coders to enhance application
quality. Coders can still produce quality Euphoria applications, but it
takes more effort to do so in Euphoria than some other languages (eg.
Ada, Eiffel, D). But on the other hand, when compared to still other languages,
Euphoria provides better QA (eg. C/C++, Assembler).
BTW, peek/poke for IEEE floating point is slower than using atom types!
--
Derek Parnell
Melbourne, Australia
23. Re: Stupid Newbie-sounding question.
irv mullins wrote:
>
>
> Derek Parnell wrote:
>
> > This is true. And there is the trade off - speed & flexibility against
> > structure and complexity. Think of it in terms of a bicycle without
> > training wheels and one with training wheels
>
> Let's ignore for the moment the fact that certain kinds of structure
> and complexity may actually make the coding experience more flexible
> and less complex, and tackle the issue of speed:
>
> > RDS has chosen speed. Meaning that the coder has more responsibility to
> > provide quality assurance than the translator does. Yes this does mean
> > more work for the coder and better discipline.
> >
> > Would you prefer a slower Euphoria if it had structures, strings and
> > an improved type system? If so, you may have to wait until v2.5 comes out
> > and someone adds these to the slower version.
>
> My impression is that RDS cares far too much about speed, and too little
> for other factors which may be more important to the bulk of users.
> That might explain why the same languages which RDS proclaims to be
> "10 to 30 times" slower than Euphoria also happen to be 10 to 30
> (or maybe 100) times more popular.
>
> And even if speed was an overriding concern when Euphoria was
> designed, surely it isn't all that important anymore, when even
> the cheap WalMart price-busters run at 2.7 ghz.
Firstly, I agree with you totally. My opinion is that Euphoria is more
than fast enough for any of the application for which I would choose to
use it. Making it 50% slower would still leave it more than fast enough.
Secondly, I'm not trying to suggest that RDS is either right or wrong. I'm
just stating what I believe to be objective facts without adding any bias
in any direction. Maybe I'm not so good at doing that though
--
Derek Parnell
Melbourne, Australia
24. Re: Stupid Newbie-sounding question.
>From: Derek Parnell <guest at RapidEuphoria.com>
>Subject: Re: Stupid Newbie-sounding question.
> > So does that mean we peek and poke everything directly to memory?
> > None of those fancy atoms for me! I like dealing with my floats in raw
> > IEEE form!
>
>Now you're getting it
>
>But seriously, folks... the current internal structures used by Euphoria
>mean that it is quick for Euphoria to distinguish between integers, atoms,
>and sequences, but if you add any more 'native' types, things are going
>to slow down a lot.
That's fine, we have integers, atoms, and sequences... but we can't easily
know what is inside a sequence. I'm not trying to add any more native
things.
MrTrick
25. Re: Stupid Newbie-sounding question.
Derek Parnell wrote:
>
> irv mullins wrote:
> >
> > And even if speed was an overriding concern when Euphoria was
> > designed, surely it isn't all that important anymore, when even
> > the cheap WalMart price-busters run at 2.7 ghz.
>
> Firstly, I agree with you totally. My opinion is that Euphoria is more
> than fast enough for any of the application for which I would choose to
> use it. Making it 50% slower would still leave it more than fast enough.
>
I agree that Euphoria is fast enough for *most* things that I like to
do with it, however, it wouldn't be if it slowed down (especially by
50%). I write a lot of custom optimization code in Euphoria, and it's
often right on the edge of being fast enough for some things. If it
slowed down, I'd have to stop using Euphoria for these tasks (yes,
even running on 3Ghz machines).
It's mainly the flexibility/speed combination that I like. I can
develop these things very quickly, and more of my time is focused on the
algorithms, rather than data structure or garbage collection, which
can be really important when you're looking at, say, hundreds of thousands
or millions of possible solutions.
I'm sure I'm in the minority on this (although going by User Contributions,
not totally alone), but thought I'd speak up for those of us for whom
speed still matters.
Matt Lewis
26. Re: Stupid Newbie-sounding question.
>From: Matt Lewis <guest at RapidEuphoria.com>
>Subject: Re: Stupid Newbie-sounding question.
> > Firstly, I agree with you totally. My opinion is that Euphoria is more
> > than fast enough for any of the application for which I would choose to=
> > use it. Making it 50% slower would still leave it more than fast enough=
.
>
>I agree that Euphoria is fast enough for *most* things that I like to
>do with it, however, it wouldn't be if it slowed down (especially by
>50%). I write a lot of custom optimization code in Euphoria, and it's
>often right on the edge of being fast enough for some things. If it
>slowed down, I'd have to stop using Euphoria for these tasks (yes,
>even running on 3Ghz machines).
Yes, you may think it doesn't matter whether a sub-routine takes 0.01=20
seconds or 0.0001...
But if your program needs to call this subroutine 1000 times at startup,=
=20
then those small differences are magnified 1000-fold.
Algorithmic efficiency is the most important thing now, not so much things=
=20
like how many bytes a primitive type is stored in (some exceptions), and=
=20
things like the processing time spent in the main portion of the code.
>
>It's mainly the flexibility/speed combination that I like. I can
>develop these things very quickly, and more of my time is focused on the
>algorithms, rather than data structure or garbage collection, which
>can be really important when you're looking at, say, hundreds of thousands=
>or millions of possible solutions.
>
>I'm sure I'm in the minority on this (although going by User Contributions=
,
>not totally alone), but thought I'd speak up for those of us for whom
>speed still matters.
>
>Matt Lewis
>
>
>
>
27. Re: Stupid Newbie-sounding question.
--0-400992202-1086181540=:84115
Content-Type: text/plain; charset=us-ascii
No, No! Please don't make Euphoria slower!
Slow BAD, fast GOOD !!
I am in total agreement with Matt Lewis ...
<soapbox>
One of the greatest advantages Euphoria has is its combination of
speed and flexibility. I am also very focused upon algorithms and have
recently switched to Euphoria because I can develop a lot of the
scientific code that was only previously possible using C, Fortran or
an analogous compiled-only language.Python is similarly flexible in
that you can develop and test code rapidly but compared to Euphoria,
it runs like molasses. Euphoria is a superb environment for developing
CPU-intensive code since even interpreted, it runs fast enough to
allow you to see what your code will do in a reasonable timeframe.
I am very interested in molecular simulation and recently started
working with a structure that was too large to work with using the
Python scripts I had developed to set up such simulations. Using
Euphoria I was able to rapidly rewrite (and greatly improve) these
scripts and I was thrilled at how rapidly and easily Euphoria allowed
me to do this, but most of all, I was "Euphoric" to see how fast the
new code ran, even before I had compiled it. In a few seconds,my new
Euphoria code can easily prepare an ensemble of half a million atoms
for a molecular dynamics simulation. I never found out how long this
same ensemble took with my old Python script since I never had the
patience to let it finish - but after 1 hour, I was still waiting!
However ... the speed expands the scope of what it's possible to do
and as Matt pointed out, it doesn't take long to push the envelope. I
am already starting to work with larger ensembles of atoms and the
wait time increases with the number of atoms.
Euphoria lets you do stuff you couldn't do otherwise and slowing it
down any would be the opposite direction to the good way forward.
Doing stuff fast is why we use computers in the first place!
</soapbox>
Best
Gordon
Matt Lewis <guest at RapidEuphoria.com> wrote:
Derek Parnell wrote:
irv mullins wrote:
>
> And even if speed was an overriding concern when Euphoria was
> designed, surely it isn't all that important anymore, when even
> the cheap WalMart price-busters run at 2.7 ghz.
Firstly, I agree with you totally. My opinion is that Euphoria is more
than fast enough for any of the application for which I would choose to
use it. Making it 50% slower would still leave it more than fast enough.
I agree that Euphoria is fast enough for *most* things that I like to
do with it, however, it wouldn't be if it slowed down (especially by
50%). I write a lot of custom optimization code in Euphoria, and it's
often right on the edge of being fast enough for some things. If it
slowed down, I'd have to stop using Euphoria for these tasks (yes,
even running on 3Ghz machines).
It's mainly the flexibility/speed combination that I like. I can
develop these things very quickly, and more of my time is focused on the
algorithms, rather than data structure or garbage collection, which
can be really important when you're looking at, say, hundreds of
thousands
or millions of possible solutions.
I'm sure I'm in the minority on this (although going by User
Contributions,
not totally alone), but thought I'd speak up for those of us for whom
speed still matters.
Matt Lewis
:::::::::: Gordon Webster ::::::::::
--0-400992202-1086181540=:84115
Content-Type: text/html; charset=us-ascii
<DIV>
<DIV>No, No! Please don't make Euphoria slower!</DIV>
<DIV> </DIV>
<DIV>Slow BAD, fast GOOD !!</DIV>
<DIV> </DIV>
<DIV>I am in total agreement with Matt Lewis ...</DIV>
<DIV> </DIV>
<DIV><soapbox></DIV>
<DIV> </DIV>
<DIV>One of the greatest advantages Euphoria has is its combination of
speed and flexibility. I am also very focused upon algorithms and have
recently switched to Euphoria because I can develop a lot of the
scientific code that was only previously possible using C, Fortran or
an analogous compiled-only language.Python is similarly flexible in
that you can develop and test code rapidly but compared to Euphoria,
it runs like molasses. Euphoria is a superb environment for developing
CPU-intensive code since even interpreted, it runs fast enough to
allow you to see what your code will do in a reasonable timeframe.</DIV>
<DIV> </DIV>
<DIV>I am very interested in molecular simulation and recently started
working with a structure that was too large to work with
using the Python scripts I had developed to set up such
simulations. Using Euphoria I was able to rapidly rewrite (and greatly
improve) these scripts and I was thrilled at how rapidly and easily
Euphoria allowed me to do this, but most of all, I was "Euphoric" to
see how fast the new code ran, even before I had compiled it. In a few
seconds,my new Euphoria code can easily prepare an ensemble of half a
million atoms for a molecular dynamics simulation. I never found out
how long this same ensemble took with my old Python script since I
never had the patience to let it finish - but after 1 hour, I was
still waiting! </DIV>
<DIV> </DIV>
<DIV>However ... the speed expands the scope of what it's possible to
do and as Matt pointed out, it doesn't take long to push the envelope.
I am already starting to work with larger ensembles of atoms and the
wait time increases with the number of atoms.</DIV>
<DIV> </DIV>
<DIV>Euphoria lets you do stuff you couldn't do otherwise and slowing
it down any would be the opposite direction to the good way forward.
Doing stuff fast is why we use computers in the first place!</DIV>
<DIV> </DIV>
<DIV></soapbox></DIV>
<DIV> </DIV>
<DIV>Best</DIV>
<DIV> </DIV>
<DIV>Gordon</DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV><B><I>Matt Lewis <guest at RapidEuphoria.com></I></B> wrote:</DIV>
<BLOCKQUOTE class=replbq style="BORDER-LEFT: #1010ff 2px solid;
MARGIN-LEFT: 5px; PADDING-LEFT: 5px">============ The Euphoria Mailing
List ============ <BR><BR><BR>posted by: Matt Lewis
<MATTHEWWALKERLEWIS at yahoo.com><BR><BR>Derek Parnell wrote:<BR>>
<BR>> irv mullins wrote:<BR>> > <BR>> > And even if
speed was an overriding concern when Euphoria was <BR>> >
designed, surely it isn't all that important anymore, when even
<BR>> > the cheap WalMart price-busters run at 2.7 ghz.<BR>>
<BR>> Firstly, I agree with you totally. My opinion is that
Euphoria is more<BR>> than fast enough for any of the application
for which I would choose to<BR>> use it. Making it 50% slower would
still leave it more than fast enough.<BR>> <BR><BR>I agree that
Euphoria is fast enough for *most* things that I like to <BR>do with
it, however, it wouldn't be if it slowed down (especially by<BR>50%).
I write a lot of custom optimization code in Euphoria, and it's
<BR>often right on the edge of being fast enough for some things. If
it <BR>slowed down, I'd have to stop using Euphoria for these tasks
(yes,<BR>even running on 3Ghz machines).<BR><BR>It's mainly the
flexibility/speed combination that I like. I can <BR>develop these
things very quickly, and more of my time is focused on
the<BR>algorithms, rather than data structure or garbage collection,
which <BR>can be really important when you're looking at, say,
hundreds of thousands <BR>or millions of possible
solutions.<BR><BR>I'm sure I'm in the minority on this (although going
by User Contributions,<BR>not totally alone), but thought I'd speak up
for those of us for whom <BR>speed still matters.<BR><BR>Matt
Lewis<BR><BR>--^----------------------------------------------------------------<BR>This
email was sent to: gwalias-bb at yahoo.com<BR><BR>EASY UNSUBSCRIBE click
here: http://topica.com/u/?b1dd66.b7HXOn.Z3dhbGlh<BR>Or send an email
to: EUforum-unsubscribe at topica.com<BR><BR>For Topica's
complete suite of email marketing solutions
visit:<BR>http://www.topica.com/?p=TEXFOOTER<BR>--^----------------------------------------------------------------<BR></BLOCKQUOTE></DIV><BR><BR>::::::::::
Gordon Webster ::::::::::
--0-400992202-1086181540=:84115--
28. Re: Stupid Newbie-sounding question.
On Wed, 02 Jun 2004 04:34:18 -0700, Matt Lewis
<guest at RapidEuphoria.com> wrote:
>Derek Parnell wrote:
>> use it. Making it 50% slower would still leave it more than fast enough.
>> irv mullins wrote:
>slowed down, I'd have to stop using Euphoria for these tasks (yes,
>even running on 3Ghz machines).
>I'm sure I'm in the minority on this (although going by User Contributions,
>not totally alone), but thought I'd speak up for those of us for whom
>speed still matters.
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
)
29. Re: Stupid Newbie-sounding question.
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. 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. 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.
Like I said, either way it doesn't matter to me.
Mike Sabal
30. Re: Stupid Newbie-sounding question.
Pete Lomax wrote:
>
> On Wed, 02 Jun 2004 04:34:18 -0700, Matt Lewis
> <guest at RapidEuphoria.com> wrote:
>
> >Derek Parnell wrote:
> >> use it. Making it 50% slower would still leave it more than fast enough.
> >> irv mullins wrote:
> >slowed down, I'd have to stop using Euphoria for these tasks (yes,
> >even running on 3Ghz machines).
> >I'm sure I'm in the minority on this (although going by User Contributions,
> >not totally alone), but thought I'd speak up for those of us for whom
> >speed still matters.
I'm confused. Who said the last quote above (starting with
"slowed down" and ending with "still matters")? I can't figure out
if it was Derek or Matt or an unknown guest, and I can't find
the original message in the list!
31. Re: Stupid Newbie-sounding question.
On Wed, 02 Jun 2004 14:39:05 -0700, cklester <guest at RapidEuphoria.com>
wrote:
>Pete Lomax wrote:
>> On Wed, 02 Jun 2004 04:34:18 -0700, Matt Lewis wrote:
>> >Derek Parnell wrote:
>> >> use it. Making it 50% slower would still leave it more than fast enough.
>> >> irv mullins wrote:
<oops>
>> >slowed down, I'd have to stop using Euphoria for these tasks (yes,
>> >even running on 3Ghz machines).
>> >I'm sure I'm in the minority on this (although going by User Contributions,
>> >not totally alone), but thought I'd speak up for those of us for whom
>> >speed still matters.
>
>I'm confused. Who said the last quote above (starting with
>"slowed down" and ending with "still matters")? I can't figure out
>if it was Derek or Matt or an unknown guest, and I can't find
>the original message in the list!
My bad, irv penned no words there at all (I snipped them).
Derek said 50%, Matt said slowed down..matters, and I believe you
snipped all my words
)
Pete
32. Re: Stupid Newbie-sounding question.
Pete Lomax wrote:
> PS I can be bribed
)
Jeez, why are you programming, man?
There's a great future for you in politics!
Irv