1. What's holding Euphoria back?
Four things are keeping Euphoria from being used in
commercial applications:
1. Lack of structures
2. Name space problems
3. Abysmal waste of disk space when writing data files.
4. A lack of true random access for files.
There's been lots of discussion and suggestions for ways to
solve 1 and 2.
Little has been said about 3 (yes, I know Ralf has a package
to compress data. That's not the point. We need to store
single characters as one byte on disk, not two, three or more.)
Strangely enough, implementing structures as suggested by Ralf,
Falkon, and others could solve problems 3 and 4 as well, if the
structure elements could be specified as "fixed". Length (struct)
would then return the "record length" and you could do random
access seeks. Coding without a length would allow dynamic
allocation as it is done now.
structure employee
sequence name[20] -- fixed length of 20 bytes
integer age -- already fixed at the length of a Euphoria integer
atom wage -- already fixed at the length of a Euphoria atom
end structure
puts(fn,employee) -- would write a block of x bytes to disk in a
compact form, always the same length.
Therefore, seek(length(employee) * recNO would seek the recNO'th
employee on the file.
printf(1,"%s is %d years old",{employee.name, employee.age})
better:
printf(1,"%s is %d years old",{employee.name,age})
employee[23].salary = employee[23].hours * employee[23].wage
or perhaps more useful in real life:
with employee[23]
printf(1,"%s is %d years old",{name,age})
salary = hours * wage
end with
If Rob is serious about Euphoria being used for real
commercial applications, he needs to seriously consider
these problem areas. I am not holding my breath, however.
Irv
2. Re: What's holding Euphoria back?
Irv Mullins writes:
> 1. Lack of structures
This has been discussed at length. There might be some
support eventually, but it has to be something elegant and powerful.
I don't want to keep adding "missing" features until Euphoria
becomes "C++ with sequences".
> 2. Name space problems
I consider name space issues to be very high priority for
the next major release. I did not want to open this
issue just before this release, as it impacts several different
things in Euphoria, such as binding, tracing and routine_id(),
in addition to normal symbol look-up. I want to do it right,
not just a quick band-aid solution.
> 3. Abysmal waste of disk space when writing data files.
> ... We need to store single characters as one byte on
> disk, not two, three or more
When you write one or more characters to disk using
puts(), they *are* stored as one byte each. If you think
that print() to disk is wasteful, don't use it.
> 4. A lack of true random access for files.
You can use seek() and where() to position yourself
randomly at any byte in a file.
If you want to set up a large database, where the size
of the disk files matters, and the speed matters, I think
you can easily write your own set of very simple low-level routines
to take specific sequences and store them on disk compactly
and efficiently, since you will typically know the format of the
data you are storing, the sizes of integer values, the maximum
length of strings etc.
Regards,
Rob Craig
Rapid Deployment Software
http://members.aol.com/FilesEu/
3. Re: What's holding Euphoria back?
Touche Rob! Well said!!
-----Original Message-----
From: Robert Craig <rds at EMAIL.MSN.COM>
To: EUPHORIA at LISTSERV.MUOHIO.EDU <EUPHORIA at LISTSERV.MUOHIO.EDU>
Date: Friday, January 29, 1999 9:12 PM
Subject: Re: What's holding Euphoria back?
>Irv Mullins writes:
>> 1. Lack of structures
>
>This has been discussed at length. There might be some
>support eventually, but it has to be something elegant and powerful.
>I don't want to keep adding "missing" features until Euphoria
>becomes "C++ with sequences".
>
>> 2. Name space problems
>
>I consider name space issues to be very high priority for
>the next major release. I did not want to open this
>issue just before this release, as it impacts several different
>things in Euphoria, such as binding, tracing and routine_id(),
>in addition to normal symbol look-up. I want to do it right,
>not just a quick band-aid solution.
>
>> 3. Abysmal waste of disk space when writing data files.
>> ... We need to store single characters as one byte on
>> disk, not two, three or more
>
>When you write one or more characters to disk using
>puts(), they *are* stored as one byte each. If you think
>that print() to disk is wasteful, don't use it.
>
>> 4. A lack of true random access for files.
>
>You can use seek() and where() to position yourself
>randomly at any byte in a file.
>
>If you want to set up a large database, where the size
>of the disk files matters, and the speed matters, I think
>you can easily write your own set of very simple low-level routines
>to take specific sequences and store them on disk compactly
>and efficiently, since you will typically know the format of the
>data you are storing, the sizes of integer values, the maximum
>length of strings etc.
>
>Regards,
> Rob Craig
> Rapid Deployment Software
> http://members.aol.com/FilesEu/
4. Re: What's holding Euphoria back?
On Sat, 30 Jan 1999 00:05:41 -0500, Robert Craig <rds at EMAIL.MSN.COM> wrote:
>Irv Mullins writes:
>
>> 3. Abysmal waste of disk space when writing data files.
>> ... We need to store single characters as one byte on
>> disk, not two, three or more
>
>When you write one or more characters to disk using
>puts(), they *are* stored as one byte each. If you think
>that print() to disk is wasteful, don't use it.
Obviously there is something about Euphoria that I don't
understand. Below is a small test program that writes data
to a disk file. Please explain what is wrong.
sequence s
atom fn
constant NAME = 1, AGE = 2, WAGE = 3
fn = open("TEST.DAT","w")
s = {"Sue Smith",32,22.50}
? s
printf(1,"Name: %s \n", {s[NAME]})
printf(1,"Age: %d \n", s[AGE])
printf(1,"Wage: %4.2f \n", s[WAGE])
-- puts(fn,s) won't work "sequence found inside character string"
-- so we puts it one "field" at a time:
for i = 1 to length(s) do puts(fn,s[i])
end for
close(fn)
fn = open("TEST.DAT","r")
s = gets(fn)
close(fn)
? s
printf(1,"Name: %s \n", {s[NAME]})
printf(1,"Age: %d \n", s[AGE])
printf(1,"Wage: %4.2f \n", s[WAGE])
-- Sue, now known as "S", is 117 years old, and she makes 101 dollars an hour!
http://members.aol.com/FilesEu/
-- probably correct - she has lots of experience!
-- Irv
5. Re: What's holding Euphoria back?
>Irv Mullins writes:
>> 1. Lack of structures
>
>This has been discussed at length. There might be some
>support eventually, but it has to be something elegant and powerful.
>I don't want to keep adding "missing" features until Euphoria
>becomes "C++ with sequences".
Robert, is your goal to create a good language or to create something that
is the opposite of C ?
C has got little to do with such a discussion except for an example, but I
would prefer if you stick to 'euphoric' examples, since they are the only
ones that actually apply. No offense, but these kind of arguments are not
convincing.
>> 2. Name space problems
>
>I consider name space issues to be very high priority for
>the next major release. I did not want to open this
>issue just before this release, as it impacts several different
>things in Euphoria, such as binding, tracing and routine_id(),
>in addition to normal symbol look-up. I want to do it right,
>not just a quick band-aid solution.
This on the other hand is a really strong argument. There were several
ideas, all with different impacts.
The three 'ideas' already suggested:
1) Allow some prefix. Like graphics.pixel ()
2) Have a different global name space for each include file, based upon
the files it actually includes.
3) Allow to define which globals want to use, and which name you want to
use for them. Something in the line of:
include graphics.e -- normal include. Point 2 assumed for this.
include misc.e do
routine platform as platform
constant PI as PI_VALUE
end include
-- All other identifers are not global.
-- You cant choose any identifer that is not global in the include
statement block.
This too is just a suggestion. You will reckognize where its from. Modula.
>> 3. Abysmal waste of disk space when writing data files.
>> ... We need to store single characters as one byte on
>> disk, not two, three or more
>
>When you write one or more characters to disk using
>puts(), they *are* stored as one byte each. If you think
>that print() to disk is wasteful, don't use it.
Yes, we can do it ourselves. We always can. For graphics, mouse routines,
structures, etc. etc.
We can always do it ourselves, so why are their huge libraries linked for
graphics, mouse support, file IO with cashing, etc. ?
They should either be really good and powerfull or not linked to the
interpreter at all. I mean, file IO could have been coded (at simerlar
speed) using 100% Euphoria routines.
Like that, graphics libraries have also shown us, we need not to 'link'
those huge watcom libraries.
And I believe, your initial choice was to include powerfull libraries. You
gave support for VESA modes, had IO support with cache, etc. All signs to
show you wanted powerfull support for these things. Lets keep up with the
present. There are now faster and much more powerfull graphics libraries,
powerfull mouse routines that also work in VESA modes, powerfull IO routines
of Jaques Deschenes, etc.
It would be a waste, if in the end 9 out 10 programs use their own graphical
libraries, their own mouse routines, their own file io routines, etc. Yet
still half of the interpreters size (although its even compressed) is prolly
due to watcom libraries that enable the native euphoria support for these
things.
My point is, what is your choice on these things nowadays ?
Minimum-just-the-bare or powerfull-all-the-way ? But, please, not something
in between. I can understand Irv's problems with these things. Does euphoria
want powerfull IO support, or just he bare ? Powerfull graphics support or
just the bare tools ? And: do they need to be linked to the interpreter, or
be machine code inside Euphoria libraries ?
Ralf
6. Re: What's holding Euphoria back?
Irv Mullins wrote:
> Below is a small test program that writes data
> to a disk file. Please explain what is wrong.
>
> sequence s
> atom fn
> constant NAME = 1, AGE = 2, WAGE = 3
>
> fn = open("TEST.DAT","w")
>
> s = {"Sue Smith",32,22.50}
> ? s
> printf(1,"Name: %s \n", {s[NAME]})
> printf(1,"Age: %d \n", s[AGE])
> printf(1,"Wage: %4.2f \n", s[WAGE])
> -- puts(fn,s) won't work "sequence found inside character string"
> -- so we puts it one "field" at a time:
> for i = 1 to length(s) do puts(fn,s[i])
> end for
You are writing as a string s[2] which is an integer,
and s[3] which is a real. That's what's wrong.
> close(fn)
Then:
> fn = open("TEST.DAT","r")
> s = gets(fn)
you are reading as ONE SINGLE string a sequence the last
two elements of which you wrote as strings when
they should have been written respectively as
integer and real.
> close(fn)
>
> ? s
> printf(1,"Name: %s \n", {s[NAME]})
> printf(1,"Age: %d \n", s[AGE])
> printf(1,"Wage: %4.2f \n", s[WAGE])
No wonder that....:
> -- Sue, now known as "S", is 117 years old, and she makes 101 dollars an hour!
It is very simple:
printf(fn,"\n{\"%s\",%d,%0.2f",{s[1],s[2],s[3]})
You have just written this into that file:
{"Sue Smith",32,22.50}
which you later read back like this:
object buffer
sequence s
buffer=get(fn)
s=buffer[2]
Simple. It's only a matter of reading the documentation, which
mercifully, is not overly long. But I/O *is* the trickiest
part of every language. Likewise random access (which *is*
true random access).
Name space problems plague every language in different manners.
It is more a matter of brain [storage] space really. After
you've included as few a twenty *.e files each with as few
as twenty globals, there is no way in the world that you are
going to remember what belongs where, and precisely what
is the different between function foo() in glug.e and
functiom foo() in nyik.e, or where function foo() is at all.
I do not see any clean way out. Those .'s, those ::'s, those
"with... do"'s are all kludges. E.g.
with glug do
....
....
....
if foo() then
slurp() -- oops! that slurp is in nyik.e... so:
nyik::slurp() -- er... unless glug.e includes nyik.e, perhaps?
end if
....
end with
It comes back to giving a full name every time *if* you really
want to avoid bugs. But you can do that already by prefixing
every global with the filename, or an abbreviation of it.
No, what is holding Euphoria back, if something is, is
what held Oberon back (or Pascal). There is also, I suspect,
a strong interest in sticking to overly complex, bug-breeding
languages (I leave you to figure out why).
7. Re: What's holding Euphoria back?
At 00:05 1/30/99 -0500, Robert Craig wrote:
>Irv Mullins writes:
>> 1. Lack of structures
>
>This has been discussed at length. There might be some
>support eventually, but it has to be something elegant and powerful.
>I don't want to keep adding "missing" features until Euphoria
>becomes "C++ with sequences".
I would like to add my support to the idea of "elegant and powerful".
Sequences themselves are elegant and powerful. So far, the argument
for structures that I find most compelling is the namespace issue,
and apparently that will now be resolved (see #2 below).
I may be an old curmudgeon, but I refuse to use C++. IMHO it is way
overly complex for the supposed benefits. I probably wouldn't use
"C++ With Sequences" either, although it would be an improvement 
>> 2. Name space problems
>
>I consider name space issues to be very high priority for
>the next major release. I did not want to open this
>issue just before this release, as it impacts several different
>things in Euphoria, such as binding, tracing and routine_id(),
>in addition to normal symbol look-up. I want to do it right,
>not just a quick band-aid solution.
Again, I like Rob's approach. Obviously, the namespace issue must
be resolved for Euphoria to be viable for widespread use, but I would
much rather see Euphoria evolve slowly, in a well thought-out manner,
than to make a bunch of changes later to what was working code because
things were implemented too quickly.
If we get to vote on syntax, I prefer <module_name>.<variable_name>
to <module_name>::<variable_name>. The :: is just too C++ish for
me Of course, <variable_name> alone always refers to the current
module.
--
Don Groves
8. Re: What's holding Euphoria back?
Robert Craig wrote:
> If you want to set up a large database, where the size
> of the disk files matters, and the speed matters
I have written such a database, which so far consists
of some 15,000 files, each around 50K, growing at
the rate of some 200 a week. Associated with those
files, are two dictionaries, also growing, one containing
some 24,000 horses, the other 1,800 jockeys, each with
a list of all the past races they were in (at least,
those my 15,000 data files know about). There is more:
cross-correlation matrices, reconstructed results of
past races (one per month per track), etc. When you
have such a mess to manage, speed does matter, and
disk space I suppose. For speed, no way out. Most of
the data and statistics maintainance is slowed down
by disk access. The only way out is to stick files onto
a RAM disk and leave them there for as long as they
are needed. At any rate, I once ran a benchmark
comparing Euphoria 1.5a and Borland Pascal. At best,
Euphoria was as fast as Pascal, at worst 7.5 times
as slow. So what? I started the job in Pascal on a
486DX running at 50MHz, I continued on an AMD-K6 at
200MHz. It ran *faster*. Space? Since once upon
a time I wrote on a Kaypro II (Z80, 2MHz), with two
floppy disks, each holding 180K, I remember what
it was to save disk space. And that hangover stayed
with me for a long time. Writing correlation matrices
in binary representation rather than EBCDIC. Writing
*everything* like that. Having to write utilities to
be able to *read* that human-hostile stuff. Then I
realized that I was wrecking my nerves for just a few bytes
less. It was still tenable when I had only 85M of hard
disk. But with 3.2G, then another 6.4G? No longer.
Everything is now in "long-hand", even the correlation
matrices are formatted so that *I* can read them.
At any rate, it's all very silly. Most of the
commercial stuff I have seen (and hacked into)
was awfully wasteful of disk space. They never seemed
to have heard of variable-length fields, for instance.
And the disk-thrashing was deafening. And poor sods
paid good money for that.
and R. Craig continues:
> I think
> you can easily write your own set of very simple low-level routines
> to take specific sequences and store them on disk compactly
> and efficiently
It is easy, I have done it. But now I know better.
9. Re: What's holding Euphoria back?
On Sun, 31 Jan 1999 06:44:43 -0800, jguy <jguy at ALPHALINK.COM.AU> wrote:
>Irv Mullins wrote:
>> Below is a small test program that writes data
>> to a disk file. Please explain what is wrong.
<snip>
>
>you are reading as ONE SINGLE string a sequence the last
>two elements of which you wrote as strings when
>they should have been written respectively as
>integer and real.
>It is very simple:
>
>printf(fn,"\n{\"%s\",%d,%0.2f",{s[1],s[2],s[3]})
>
>You have just written this into that file:
>
>{"Sue Smith",32,22.50}
>
>which you later read back like this:
>
>object buffer
>sequence s
>
>buffer=get(fn)
>s=buffer[2]
>
>
>Simple. It's only a matter of reading the documentation, which
>mercifully, is not overly long. But I/O *is* the trickiest
>part of every language. Likewise random access (which *is*
>true random access).
Except for a couple of things:
1. Rob said it could be done with puts()
2. Your code doesn't work. The fix is easy, just a typo in the
sprintf(), but a beginner wouldn't know where to look.
3. In Pascal, for example, I could have written it write(fn,s)
and been done with it. Later I could add to or modify the
structure 's' without having to change the output formatting
in the printf(),or worse, printf's in multiple programs which
write to the same data file.
Actually, I shouldn't complain. There's nice job security in
writing your own i/o routines. Helps if you "forget" to supply
the source.
Irv
10. Re: What's holding Euphoria back?
UM...i might be wrong here...the REASION i got hooked on E is the lack
of structures. I love E's sequence's...there easier to use and work
with...i love the lack of pointers too...why use a pointer? its just a
refernce to the real thing...in C yuo need them cuz it passes the full
structure to a sub or funtion but E does not seam to(or at least it is
not a performance killer like it is in C). I like E the way it is...I
think it CAN be used commercial apps...I am planing on doing so once i
get this memory error fixed...I had it fixed untill i instsalled the
Zone software..Ill learn some day...work or play...not both..tell now i
have done both...guess i cant any longer...ill just get a new sys for
work and this will be for playing....~as i was saying~ Yes euphoria
could use some improvments...but not structures...thats going in the
wrong way...anyone else agree with me???
Grape Vine
>Four things are keeping Euphoria from being used in
>commercial applications:
>
>1. Lack of structures
>2. Name space problems
>3. Abysmal waste of disk space when writing data files.
>4. A lack of true random access for files.
>
>There's been lots of discussion and suggestions for ways to
>solve 1 and 2.
>Little has been said about 3 (yes, I know Ralf has a package
>to compress data. That's not the point. We need to store
>single characters as one byte on disk, not two, three or more.)
>
>Strangely enough, implementing structures as suggested by Ralf,
>Falkon, and others could solve problems 3 and 4 as well, if the
>structure elements could be specified as "fixed". Length (struct)
>would then return the "record length" and you could do random
>access seeks. Coding without a length would allow dynamic
>allocation as it is done now.
>
>structure employee
> sequence name[20] -- fixed length of 20 bytes
> integer age -- already fixed at the length of a Euphoria integer
> atom wage -- already fixed at the length of a Euphoria atom
>end structure
>
>puts(fn,employee) -- would write a block of x bytes to disk in a
> compact form, always the same length.
>
>Therefore, seek(length(employee) * recNO would seek the recNO'th
>employee on the file.
>
>printf(1,"%s is %d years old",{employee.name, employee.age})
>better:
>printf(1,"%s is %d years old",{employee.name,age})
>
>employee[23].salary = employee[23].hours * employee[23].wage
>
>or perhaps more useful in real life:
>with employee[23]
> printf(1,"%s is %d years old",{name,age})
> salary = hours * wage
>end with
>
>If Rob is serious about Euphoria being used for real
>commercial applications, he needs to seriously consider
>these problem areas. I am not holding my breath, however.
>
>Irv
______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com
11. Re: What's holding Euphoria back?
>work and this will be for playing....~as i was saying~ Yes euphoria
>could use some improvments...but not structures...thats going in the
>wrong way...anyone else agree with me???
I don't. There should be a way to "format" a sequence! Benefits cover
several fields:
More redable code. This is an issue on Euphoria... one of it's lait
motifs
is to provide a fast & flexible language easily maintainable in time.
Faster code. Less type checking = faster execution (specially for
several
thousand items per sequence)
Regards,
Daniel Berstein
daber at pair.com
12. Re: What's holding Euphoria back?
On Sat, 30 Jan 1999 00:05:41 -0500, Robert Craig <rds at EMAIL.MSN.COM> wrote:
>Irv Mullins writes:
>> 1. Lack of structures
>
>This has been discussed at length. There might be some
>support eventually, but it has to be something elegant and powerful.
>I don't want to keep adding "missing" features until Euphoria
>becomes "C++ with sequences".
>
This is an interesting remark for at least two reasons:
1. As people on this list know, no one despises C more than me.
I would be the last one to want Euphoria to be more like C.
2. Surely you are aware that "structures" are in no way unique
to C++,but are shared by Pascal, Icon, Ada, Modula II, VB,
Delphi, probably even modern versions of Fortran.
There are good reasons such things have been designed into
the languages. Clarity, safety, and scalability are three
that come to mind.
Irv
13. Re: What's holding Euphoria back?
On Sat, 30 Jan 1999 00:05:41 -0500, Robert Craig <rds at EMAIL.MSN.COM> wrote:
>Irv Mullins writes:
>> 4. A lack of true random access for files.
>
>You can use seek() and where() to position yourself
>randomly at any byte in a file.
>
>If you want to set up a large database, where the size
>of the disk files matters, and the speed matters, I think
>you can easily write your own set of very simple low-level routines
>to take specific sequences and store them on disk compactly
>and efficiently, since you will typically know the format of the
>data you are storing, the sizes of integer values, the maximum
>length of strings etc.
>
>Regards,
> Rob Craig
> Rapid Deployment Software
> http://members.aol.com/FilesEu/
Easily?
I was thinking of updating a small bookeeping package I wrote
10 years ago. My first thought was to write it in Euphoria.
I soon realized that I would have to write I/O routines for
15 different files, all of which need random access to records.
Now, considering I can accomplish the same task in, for instance,
Pascal, without having to write any low-level i/o, and
without introducing buggy code somewhere in those 15 i/o
packages, which language do you think I chose to do the job?
Please note: I do NOT consider the above to be in any way a "large"
commercial package.
Irv
14. Re: What's holding Euphoria back?
>>work and this will be for playing....~as i was saying~ Yes euphoria
>>could use some improvments...but not structures...thats going in the
>>wrong way...anyone else agree with me???
>
>I don't. There should be a way to "format" a sequence! Benefits cover
>several fields:
>
> More redable code. This is an issue on Euphoria... one of it's
lait motifs
>is to provide a fast & flexible language easily maintainable in time.
>
> Faster code. Less type checking = faster execution (specially
for several
>thousand items per sequence)
>
>
>Regards,
> Daniel Berstein
> daber at pair.com
>
That I understand...But what type checking is done on a sequence except
when it is read from? The way i understood the setup of a sequence was
all in the way it was read...That should do all the type checking that
is needed...The section that reads the sequence should know if its a
text or numbers...I also under stat that writing to a sequence you need
to know the kind og data that is there..again the program should know
what kind of data it is...I guess I just dont get it...Just write the
program in a way that you dont have a tex funtion reading a number data
block and things should work(at least in my mind it does...but then
again there is no gravity in my mind so its a judgment call..)...I do
like the idea of formated sequences...
sequence aaaa{
number of people in the room
each persons name
{
number of people in the room
each persons name
there age
}
}
the sequence is set up {XXX,{YYY,"name",ZZ)
when reading or writing i can a need for bounds on the age and maybe
on the length of there name...but setting is so only numbers are wrote
to XXX and ZZ is (to me) a waste of time...your not going to think that
some one who is 40 is a letter are you??? or some ones name that is
"john Q. plublic" has numbers for a name? there can be numbers in the
name...just remember every thing is ascii....
~random convergance of nero-electrical storms..(put my finger in the
light socket)
Grape Vine
______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com
15. Re: What's holding Euphoria back?
- Posted by Daniel Berstein <daber at PAIR.COM>
Jan 31, 1999
-
Last edited Feb 01, 1999
At 12:33 p.m. 31-01-99 -0800, you wrote:
>That I understand...But what type checking is done on a sequence except
>when it is read from? The way i understood the setup of a sequence was
>all in the way it was read...That should do all the type checking that
>is needed...
Sorry but I don't understand you. Are you saying that it ain't important
how you store the data, but the way you read it?! I don't want to be
rude, but you're mistaken. The way you storage information and how you
retrive it are BOTH important. I'm an excellent spanish reader, but give
me a german book and I won't understand a word!
>The section that reads the sequence should know if its a
>text or numbers...I also under stat that writing to a sequence you need
>to know the kind og data that is there..again the program should know
>what kind of data it is...I guess I just dont get it...Just write the
>program in a way that you dont have a tex funtion reading a number data
>block and things should work(at least in my mind it does...but then
>again there is no gravity in my mind so its a judgment call..)...
You're right here. It works... that's the way we do it now. That doesn't mean
it's the best way to do it. Sequences by definition are anarchist data
strcutures, they let you do the most inimaginable construct. That is GOOD,
and makes Euphoria unique. The problem is that real life problems need
real life solutions. Look at languages like Lisp, Scheme or Haskell, they
are great for investigation (AI, speech recognition, etc.), and rarely go
beyond
academic walls. Euphoria has a clear orientation to a practical solution tool.
To survive (and prospere) the real world Euphoria must adecuate.
>I do like the idea of formated sequences...
Me too ;)
>sequence aaaa{
> number of people in the room
> each persons name
> {
> number of people in the room
> each persons name
> there age
> }
> }
>
>the sequence is set up {XXX,{YYY,"name",ZZ)
I was thinking some kind of template:
template roommate
{sequence name, integer age}
end template
template room
{integer room_number, sequence roommates of roommate}
end template
sequence bedrooms of room
Now I can do:
sequence me of roommate
sequence myroom of room
me[name] = "Daniel Berstein"
me[age] = 25
myroom[room_number] = 101
myroom[roommates] = append(myroom[roommates], me)
bedrooms = append(bedrooms, myroom)
Can you see how this code is much more readable than the way we have
to do it now?
BTW A SizeOf() function would be helpful for I/O routines too.
>"john Q. plublic" has numbers for a name? there can be numbers in the
>name...just remember every thing is ascii....
I rember that all the time ;)
Regards,
Daniel Berstein
daber at pair.com
16. Re: What's holding Euphoria back?
- Posted by Daniel Berstein <daber at PAIR.COM>
Jan 31, 1999
-
Last edited Feb 01, 1999
At 05:14 a.m. 30-01-99 -0500, you wrote:
This answer is a bit outdated buy may explain some things:
>Obviously there is something about Euphoria that I don't
>understand. Below is a small test program that writes data
puts() as it name says is designed to output *strings*. The function will
only output the
lower 8 bits of any number. Try this:
sequence message
message = "Euphoria!"
? message
puts(1, message)
message = or_bits(message, 512)
? message
puts(1, message)
So for binary data the best is to use print(fn,...) and getc(fn).
Regards,
Daniel Berstein
daber at pair.com
17. Re: What's holding Euphoria back?
On Sun, 31 Jan 1999, Daniel Berstein wrote:
] I was thinking some kind of template:
]
] template roommate
] {sequence name, integer age}
] end template
]
] template room
] {integer room_number, sequence roommates of roommate}
] end template
[]
] Now I can do:
]
] sequence me of roommate
] sequence myroom of room
[etc.]
I posted a message on how to do this with the language features we *do*
have on the 11th of Jan. The subject line was "Structures Was Re:
Memory"...
We've already been here...
--
Carl R White -- Final Year Computer Science at the University of Bradford
E-mail........: cyrek- at -bigfoot.com -- Remove hyphens. Ta :)
URL...........: http://www.bigfoot.com/~cyrek/
Uncrackable...: "19.6A.23.38.52.73.45 25.31.1C 3C.53.44.39.58"
18. Re: What's holding Euphoria back?
>>That I understand...But what type checking is done on a sequence
except
>>when it is read from? The way i understood the setup of a sequence was
>>all in the way it was read...That should do all the type checking that
>>is needed...
>
>Sorry but I don't understand you. Are you saying that it ain't
important
>how you store the data, but the way you read it?! I don't want to be
>rude, but you're mistaken. The way you storage information and how you
>retrive it are BOTH important. I'm an excellent spanish reader, but
give
>me a german book and I won't understand a word!
>
>>The section that reads the sequence should know if its a
>>text or numbers...I also under stat that writing to a sequence you
need
>>to know the kind og data that is there..again the program should know
>>what kind of data it is...I guess I just dont get it...Just write the
>>program in a way that you dont have a tex funtion reading a number
data
>>block and things should work(at least in my mind it does...but then
>>again there is no gravity in my mind so its a judgment call..)...
>
>You're right here. It works... that's the way we do it now. That
doesn't mean
>it's the best way to do it. Sequences by definition are anarchist data
>strcutures, they let you do the most inimaginable construct. That is
GOOD,
>and makes Euphoria unique. The problem is that real life problems need
>real life solutions. Look at languages like Lisp, Scheme or Haskell,
they
>are great for investigation (AI, speech recognition, etc.), and rarely
;
>beyond
>academic walls. Euphoria has a clear orientation to a practical
solution tool.
What i was trying to say is that if every time you wite to the data
block and it has to be checked to make sure its of the right type then
that slows down the program. If at all times you only write the data in
the correct way and type you should be able to read it and skip the time
consuming type checking step...
>To survive (and prospere) the real world Euphoria must adecuate.
>
>>I do like the idea of formated sequences...
>
>Me too ;)
>
>>sequence aaaa{
>> number of people in the room
>> each persons name
>> {
>> number of people in the room
>> each persons name
>> there age
>> }
>> }
>>
>>the sequence is set up {XXX,{YYY,"name",ZZ)
>
>I was thinking some kind of template:
>
>template roommate
> {sequence name, integer age}
>end template
>
>template room
> {integer room_number, sequence roommates of roommate}
>end template
>
>sequence bedrooms of room
>
>Now I can do:
>
>sequence me of roommate
>sequence myroom of room
>
>me[name] = "Daniel Berstein"
>me[age] = 25
>
>myroom[room_number] = 101
>myroom[roommates] = append(myroom[roommates], me)
>
>bedrooms = append(bedrooms, myroom)
>
>Can you see how this code is much more readable than the way we have
>to do it now?
Just cuz its more readable dont mean it will be faster(and vise versa)
>
>BTW A SizeOf() function would be helpful for I/O routines too.
>
>>"john Q. plublic" has numbers for a name? there can be numbers in the
>>name...just remember every thing is ascii....
>
>I rember that all the time ;)
>
>
>Regards,
> Daniel Berstein
> daber at pair.com
>
______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com
