1. "OF" in types, yet again...
At the suggestion that I implement a test system to show how effective
the "of" type can be, I have done so....
Run benchmarks.ex to see how it performs on your machine.
To change the number of iterations, change constants.e.
"of" is at least 20 times faster at 10,000 records.
Everyone, what do you think? See test_of.ex for example.
--
MrTrick
2. Re: "OF" in types, yet again...
Sorry... the attachment was stripped out.
It can be found here: http://users.secsme.org.au/~prbarnes/misc/oth/of.zip
RobC, any comments?
On Sat, 3 Jul 2004 11:22:10 +1000, Patrick Barnes <mrtrick at gmail.com> wrote:
>
>
> At the suggestion that I implement a test system to show how effective
> the "of" type can be, I have done so....
>
> Run benchmarks.ex to see how it performs on your machine.
> To change the number of iterations, change constants.e.
>
> "of" is at least 20 times faster at 10,000 records.
>
> Everyone, what do you think? See test_of.ex for example.
> --
> MrTrick
>
>
>
>
--
MrTrick
3. Re: "OF" in types, yet again...
Patrick Barnes wrote:
>
> Sorry... the attachment was stripped out.
> It can be found here: <a
> href="http://users.secsme.org.au/~prbarnes/misc/oth/of.zip">http://users.secsme.org.au/~prbarnes/misc/oth/of.zip</a>
> RobC, any comments?
>
> On Sat, 3 Jul 2004 11:22:10 +1000, Patrick Barnes <mrtrick at gmail.com>
> wrote:
> >
> >
> > At the suggestion that I implement a test system to show how effective
> > the "of" type can be, I have done so....
> >
> > Run benchmarks.ex to see how it performs on your machine.
> > To change the number of iterations, change constants.e.
> >
> > "of" is at least 20 times faster at 10,000 records.
> >
> > Everyone, what do you think? See test_of.ex for example.
> > --
> > MrTrick
Thanks, I downloaded the zip and took a quick look at it.
I have no technical problems with implementing
something like this. As I said, I studied this in great detail
a few years ago. It's a logical and elegant extension to
the language. I would not restrict it to one-level of slice or
force the new syntax to appear only within a type declaration.
e.g. I would allow an infinite number of levels:
sequence of sequence of ... <type> x
Of course people will naturally demand a way to declare structures
and add them to the type system. e.g. sequence of mystruct x
I don't need a benchmark to show me that type checking one (subscript)
or a few (slice) elements will be much faster than checking
the whole sequence.
The only thing holding me back is that I doubt many people
would use this, and those that would use it would not benefit
greatly from it. I can't see many people bothering to say:
sequence of sequence of integer s
when they can just say
sequence s
I've found that most people are more interested in how few keystrokes
they can type to get the job done, than they are with adding
extra type-checking, especially with all the run-time checking
that Euphoria already has.
Beginners would have to read a big new section of the manual
describing all these wonderful types that they can create.
They would falsely conclude that this was an essential
part of the language, without which you can't do anything,
just like C++ or most other statically-typed languages.
In Euphoria, types are for documentation and debugging. Period.
They are not used to construct data structures, like in most
other languages. Thus they are not central to the language,
like they are in most other languages. I wouldn't want to
add a lot of fancy extensions to something that isn't very important.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
4. Re: "OF" in types, yet again...
I'll have to agree with Robert. In other languages, types are necessary. In
Euphoria, they aren't. Us advanced programmers (
) know what it's all about,
but beginners don't know what's important and what not.
Remember one of the motto's of Euphoria: 'Easier to learn than BASIC'. Adding
extra stuff that's not really necessary makes Euphoria less easy to learn.
What does a beginner really have to learn about types in Euphoria: atoms and
sequences.
Keep It Simple, Sydney.
Robert Craig wrote:
> Thanks, I downloaded the zip and took a quick look at it.
> I have no technical problems with implementing
> something like this. As I said, I studied this in great detail
> a few years ago. It's a logical and elegant extension to
> the language. I would not restrict it to one-level of slice or
> force the new syntax to appear only within a type declaration.
> e.g. I would allow an infinite number of levels:
> sequence of sequence of ... <type> x
>
> Of course people will naturally demand a way to declare structures
> and add them to the type system. e.g. sequence of mystruct x
>
> I don't need a benchmark to show me that type checking one (subscript)
> or a few (slice) elements will be much faster than checking
> the whole sequence.
>
> The only thing holding me back is that I doubt many people
> would use this, and those that would use it would not benefit
> greatly from it. I can't see many people bothering to say:
>
> sequence of sequence of integer s
>
> when they can just say
>
> sequence s
>
> I've found that most people are more interested in how few keystrokes
> they can type to get the job done, than they are with adding
> extra type-checking, especially with all the run-time checking
> that Euphoria already has.
>
> Beginners would have to read a big new section of the manual
> describing all these wonderful types that they can create.
> They would falsely conclude that this was an essential
> part of the language, without which you can't do anything,
> just like C++ or most other statically-typed languages.
>
> In Euphoria, types are for documentation and debugging. Period.
> They are not used to construct data structures, like in most
> other languages. Thus they are not central to the language,
> like they are in most other languages. I wouldn't want to
> add a lot of fancy extensions to something that isn't very important.
--
tommy online: http://users.pandora.be/tommycarlier
Euphoria Message Board: http://uboard.proboards32.com
5. Re: "OF" in types, yet again...
Tommy Carlier wrote:
>
> I'll have to agree with Robert. In other languages, types are necessary. In
> Euphoria,
> they aren't. Us advanced programmers () know what it's all about, but
> beginners
> don't know what's important and what not.
> Remember one of the motto's of Euphoria: 'Easier to learn than BASIC'. Adding
> extra
> stuff that's not really necessary makes Euphoria less easy to learn.
> What does a beginner really have to learn about types in Euphoria: atoms and
> sequences.
> Keep It Simple, Sydney.
Just exactly what is simple about the obscure errors you get when trying
to do things (like printing) which are easy in other languages?
How does that make Eu "easier" for the beginner?
This topic has been discussed to death here, and there isn't ever going to
be any change. Those who aren't willing to cope with the idiosyncracies
of Eu eventually move on. As do beginners who hit one to many stumbling
blocks.
Irv
6. Re: "OF" in types, yet again...
> posted by: Robert Craig <rds at RapidEuphoria.com>
> Thanks, I downloaded the zip and took a quick look at it.
> I have no technical problems with implementing
> something like this. As I said, I studied this in great detail
> a few years ago. It's a logical and elegant extension to
> the language. I would not restrict it to one-level of slice or
> force the new syntax to appear only within a type declaration.
> e.g. I would allow an infinite number of levels:
> sequence of sequence of ... <type> x
>
> Of course people will naturally demand a way to declare structures
> and add them to the type system. e.g. sequence of mystruct x
Which is not mutually exclusive with the "of" system.
> I don't need a benchmark to show me that type checking one (subscript)
> or a few (slice) elements will be much faster than checking
> the whole sequence.
>
> The only thing holding me back is that I doubt many people
> would use this, and those that would use it would not benefit
> greatly from it. I can't see many people bothering to say:
>
> sequence of sequence of integer s
>
> when they can just say
>
> sequence s
>
> I've found that most people are more interested in how few keystrokes
> they can type to get the job done, than they are with adding
> extra type-checking, especially with all the run-time checking
> that Euphoria already has.
I can type ~ 50wpm. I'm more interested in knowing where a bug in my
program occured, something that is a *lot* easier to do with speedy
yet comprehensive type definition.
> Beginners would have to read a big new section of the manual
> describing all these wonderful types that they can create.
> They would falsely conclude that this was an essential
> part of the language, without which you can't do anything,
> just like C++ or most other statically-typed languages.
I think not...
Even using the fancy "of" type system, the benchmark is much faster
with no type checking whatsoever. I don't think that this would be
used (or would simply be turned off) for production code.
The key is, that this is a wonderful testing tool. Put this in the
testing/debugging section, and it would not be seen as such an
essential thing.
> In Euphoria, types are for documentation and debugging. Period.
> They are not used to construct data structures, like in most
> other languages. Thus they are not central to the language,
> like they are in most other languages. I wouldn't want to
> add a lot of fancy extensions to something that isn't very important.
"not very important".... Your super-duper flexible sequences *are*
cool, and one can do pretty much anything with them. However, in all
non-trivial programs, there are one or two (or more) *large* variables
that have a structure very rigidly defined by all the routines that
use them.
Sometimes we want flexibility, sometimes we want to enforce structure
on our own code, so that if it misbehaves and changes something, we'll
know about it right away. It is significant.
--
MrTrick
7. Re: "OF" in types, yet again...
Someone wrote:
>sequence of sequence of integer s
I doubt i would use that exact line anywhere, but i would
DEFINATELY use this:
sequence of char
which would limit ANY element in this sequence to
a whole number between 0 and 255, or hex #00 to #FF.
I'd welcome this in a heartbeat, because from then on
i'd be able to store text in single bytes with the same
ease that i store anything else (usually) when using
Euphoria. Presently, for every character stored there
are four bytes used.
On the other hand, if it was going to slow storing and
retrieving down too much i would not like this 
I think as a min i would look for not less then 0.5 times
the speed it is now, although it really is app dependent.
Take care,
Al
And, good luck with your Euphoria programming!
My bumper sticker: "I brake for LED's"
8. Re: "OF" in types, yet again...
Al Getz wrote:
>
> Someone wrote:
>
> >sequence of sequence of integer s
>
> I doubt i would use that exact line anywhere, but i would
> DEFINATELY use this:
>
> sequence of char
>
> which would limit ANY element in this sequence to
> a whole number between 0 and 255, or hex #00 to #FF.
>
> I'd welcome this in a heartbeat, because from then on
> i'd be able to store text in single bytes with the same
> ease that i store anything else (usually) when using
> Euphoria. Presently, for every character stored there
> are four bytes used.
Unfortunately, I would still want to store your
chars in 4 bytes. The main reason I don't store
chars in one byte now is because I'd have to
create a new *internal* data type that would
make the interpreter much bigger, buggier,
slower, and harder to maintain.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
9. Re: "OF" in types, yet again...
On 3 Jul 2004, at 19:41, Robert Craig wrote:
>
>
> posted by: Robert Craig <rds at RapidEuphoria.com>
>
> Al Getz wrote:
> >
> > Someone wrote:
> >
> > >sequence of sequence of integer s
> >
> > I doubt i would use that exact line anywhere, but i would
> > DEFINATELY use this:
> >
> > sequence of char
> >
> > which would limit ANY element in this sequence to
> > a whole number between 0 and 255, or hex #00 to #FF.
> >
> > I'd welcome this in a heartbeat, because from then on
> > i'd be able to store text in single bytes with the same
> > ease that i store anything else (usually) when using
> > Euphoria. Presently, for every character stored there
> > are four bytes used.
>
> Unfortunately, I would still want to store your
> chars in 4 bytes. The main reason I don't store
> chars in one byte now is because I'd have to
> create a new *internal* data type that would
> make the interpreter much bigger, buggier,
> slower, and harder to maintain.
What about being able to map chars or sequence or objects back onto
allocated memory? Then Al could allocate some memory, point a sequential
list of chars onto it, and then map a sequence onto it. Assuming, of course,
when he assigns a value to the sequence, the char type checking is also
performed (because the was value changed when the overlying sequence
was changed).
Kat
