OpenEuphoria

Re: What's holding Euphoria back?

• Posted by jguy <jguy at ALPHALINK.COM.AU> Jan 31, 1999
• 471 views

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).