1. Eu vs perl
I found this posted on the perl.porters-gw newsgroup. The
answer is by none other than Larry Wall himself. Anybody
beg to differ with him?
simon at brecon.co.uk writes:
: As seen on today's Freshmeat:
:
: Euphoria Programming Language v2.2 for Linux, 32-bit Windows and
: 32-bit extended DOS. It is simple, flexible, and easy to learn and
: outperforms all popular interpreted languages.
: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
--Begin Wall's reply:
Primarily on sieve benchmarks, which of course are terribly representative
of typical Perl processing. And I do mean terribly...
: Whoa there!
Yeah, whoa there. 
: I haven't enough tuits to do serious stress-testing, but here's an
: inkling:
:
: ---------------
: % time ./lines bigwords
: lines nb-lines nb-nc-lines chars
: 314337 314337 314337 3244879 bigwords
: ./lines bigwords 1.03s user 0.05s system 100% cpu 1.075 total
:
: % time ./lines.pl bigwords
: lines nb-lines nb-nc-lines chars
: 314337 314337 314337 3244879 bigwords
: perl lines.pl bigwords 2.27s user 0.03s system 99% cpu 2.307 total
:
: % wc -l lines.ex lines.pl
: 109 lines.ex
: 4 lines.pl
:
: % cat lines.pl
: #!/usr/bin/perl -n
: BEGIN {$save=$ARGV[0];print "lines nb-lines nb-nc-lines chars\n"}
: $lines++; $nb++ if /\S/; $nbnclines++ unless /^--/; $chars+=length;
: END { print "$lines\t$nb\t$nbnclines\t$chars\t$save\n" }
: ---------------
:
: It may be verbose,
Yes, it's definitely verbose. I've included the lines example below.
If I had to summarize it in one sentence, I'd say that Euphoria looks
like Ada syntax grafted onto Lisp data. (I would have thought that was
cool 20 years ago.) It's not Ada, and it's not Lisp, but the cultural
flavors are strong...
(Of course, you have to expect some level of verbosity from a language
with a name as long as that. The author of Euphoria obviously doesn't
carry the gene for carpal tunnel...)
: but for an interpreted language, it's damned quick.
It's quicker on that problem for several reasons. One, it has integer
declarations. (You should try the perl with a "use integer".) Two, it
doesn't really have any strings to speak of, just numeric arrays that
it pretends are strings. (It's basically a toy language, as far as I'm
concerned.) Three, it cheats--it looks to me like it steals a bit from
each integer cell for something else, perhaps to tell whether it's an
object pointer instead. That'd be equivalent to us using one bit of an
SV* to say that it's really an integer instead. (I'm guessing this
from the documented range of integers, which is -1073741824 to
+1073741823.)
Another reason their interpreter is fast is because it's tuned for
one architecture.
There are a number of shortcomings in Euphoria from the Perl
programmer's perspective, not the least of which is the traditional
comp sci mindset of minimalism. Which leads to the attitude that
programmers should think like computers, not like humans.
That some people would want to think like computers should not be too
surprising. That the same people would also want everyone else to
think like computers shows a similar lack of imagination.
I'm not saying Euphoria isn't good at what it's good at, but
it's just not good at much of anything that Perl is good at.
Plus, I bet we can make the Perl version run considerably faster. Try
this version, which is also more correct than yours in several ways:
#!/usr/bin/perl
use integer;
@ARGV = "-" unless @ARGV;
print "lines nb-lines nb-nc-lines chars\n";
foreach my $file (@ARGV) {
my $b;
my $clines;
my $chars;
open(FILE, $file) or die "Can't open $file: $!\n";
if ($chars = -s $file) {
/\S/ || $b++, /^--/ && $clines++ while <FILE>;
}
else {
/\S/ || $b++, /^--/ && $clines++, $chars += length while <FILE>;
}
my $nb = $. - $b;
my $nbnclines = $. - $clines - $b;
print "$.\t$nb\t$nbnclines\t$chars\t$file\n";
close(FILE);
}
That runs 40% faster than your Perl version. Hmm, let's see now. [Clatter,
clatter, clatter.] If we rewrite that as
#!/usr/bin/perl
use integer;
@ARGV = "-" unless @ARGV;
print "lines nb-lines nb-nc-lines chars\n";
foreach my $file (@ARGV) {
my $lines;
my $b;
my $clines;
open(FILE, $file) or die "Can't open $file: $!\n";
undef $/;
$_ = <FILE>;
close(FILE);
$lines = tr/\n/\n/;
$b++ while /^\s*?\n/mg;
$clines++ while /^--/mg;
my $nb = $lines - $b;
my $nbnclines = $lines - $clines - $b;
my $chars = length;
print "$lines\t$nb\t$nbnclines\t$chars\t$file\n";
}
it now runs 60% faster than your version, which means it should now
outrun the Euphoria example. It's also a fifth the size, though of
course the Euphoria example does globbing for you too. That might take
another line of Perl. Oh, and I didn't put in the logic for a grand
total at the end, but that's just another few lines. On the other
hand, the Euphoria program has to pull in another 489 lines of include
files to do what it does, so it's really a 598 line program.
And you thought Rexx was verbose...
Why do language designers persist in thinking that simple languages
produce simple solutions? All it does is sweep the complexity of the
problem under someone else's carpet. They're making the same mistake
as the Rexx folks.
Their web page says, "Just say NO to complicated languages." I say, "Just
say no to complicated solutions."
: But no source.
That is one of the biggest shortcomings. In fact, that's a killer.
It would appear that for most people, Euphoria is just a temporary
mental state.
Larry
P.S. But please don't let me discourage anyone from making the
traditional benchmarks run faster. The Euphoria folks appear to be
especially partial to sieves. A well places "int" declaration or
two might do wonders, if someone spoke to the optimizer about it.
P.P.S. I suppose we could make Perl run even faster if we do like
Euphoria and only distribute binaries for Intel CPUs. Then we could
write it all in 386 assembly... 
P.P.P.S. Here's the lines program in Euphoria that I promised:
-- lines.ex
-- Count the number of lines, non-blank lines, non-blank/non-comment lines,
-- and characters in a text file or bunch of text files in the
-- current directory.
-- usage: lines.bat [file-spec ...]
-- example: lines *.e *.ex
include misc.e
include wildcard.e
include file.e
constant SCREEN = 1
constant TRUE = 1, FALSE = 0
function blank_line(sequence line)
-- TRUE if line is empty or all whitespace
for i = 1 to length(line) do
if not find(line[i], " \t\n") then
return FALSE
end if
end for
return TRUE
end function
function scan(integer fileNum)
-- count lines, non-blank lines, characters
object line
integer lines, nb_lines, nb_nc_lines, chars, c
lines = 0
nb_lines = 0
nb_nc_lines = 0
chars = 0
while TRUE do
line = gets(fileNum)
if atom(line) then
-- end of file
return {lines, nb_lines, nb_nc_lines, chars}
else
lines += 1
chars += length(line)
if platform() != LINUX then
chars += 1 -- line in file contains an extra \r
end if
if not blank_line(line) then
nb_lines += 1
c = match("--", line)
if not c or not blank_line(line[1..c-1]) then
nb_nc_lines += 1
end if
end if
end if
end while
end function
procedure lines()
-- main procedure
integer fileNum
sequence count, total_count
sequence file_names, dir_names
sequence cl, file_spec, name
-- gather eligible file names
cl = command_line()
file_spec = {}
for i = 3 to length(cl) do
file_spec = append(file_spec, cl[i])
end for
if length(file_spec) = 0 then
file_spec = {"*.*"}
end if
dir_names = dir(current_dir())
file_names = {}
for f = 1 to length(file_spec) do
for i = 1 to length(dir_names) do
if not find('d', dir_names[i][D_ATTRIBUTES]) then
name = dir_names[i][D_NAME]
if wildcard_file(file_spec[f], name) then
if not find(name, file_names) then
file_names = append(file_names, name)
end if
end if
end if
end for
end for
-- process all files
total_count = {0, 0, 0, 0}
puts(SCREEN, "lines nb-lines nb-nc-lines chars\n")
for i = 1 to length(file_names) do
fileNum = open(file_names[i], "r")
if fileNum = -1 then
printf(SCREEN, "cannot open %s\n", {file_names[i]})
else
count = scan(fileNum)
total_count = total_count + count
printf(SCREEN, "%5d%8d %8d %8d %s\n", count & {file_names[i]})
close(fileNum)
end if
end for
if length(file_names) > 1 then
printf(SCREEN, "%5d%8d %8d %8d total\n", total_count)
end if
end procedure
lines()
2. Re: Eu vs perl
- Posted by nieuwen at XS4ALL.NL
Dec 05, 1999
-
Last edited Dec 06, 1999
PS. Irv, could you post or mail this to the original author ?
> I'm not saying Euphoria isn't good at what it's good at, but
> it's just not good at much of anything that Perl is good at.
Depends on the goal: speed, maintainability, simplicity and portability and how
you want to
balance those. Perl is better that Euphoria for certain problems, with certain
'preference'
criteria. It's all so relative that's its a pretty context sensitive and any
attempt to gather the
conditions is as foolish as trying to make the ideal language.
> Plus, I bet we can make the Perl version run considerably faster. Try
> this version, which is also more correct than yours in several ways:
Yes, faster, at the cost of ?
You are, in the end, able to improve the perl, so it runs faster than the
Euphoria code,
however at which cost ? The euphoria code is intuitively written, without any
care of
optimization, yet it runs at a acceptable speed. So, when comparing the speed of
development rather than program execution, the benchmarks are different again.
I'm not saying you can throw away Perl, I'm just saying that Euphoria is far
more than a toy-
language, at least, when comparing to Perl, and considering Perl to be a serious
as todays IT
company considers it to be. (unfortunately, most IT companies are like annoying
echoes,
convincing themselves the actually know what they're talking about; Solving a
problem and
understanding the problem are still very different things.)
Off course, there's also the interest notion of number of lines used.
Just take a look at the Perl code, and the Euphoria code. Did you know that in
Euphoria you
are allowed to put multiple statements within the same line. You might almost be
able to write
such unreadable code as this Perl example is. (this statement is based on a
simple time
measure: how long does it take you to understand the code that you are looking
at, with
comparable experience with the language used within comparable situations. Ie.
Some parts
of the Perl code may be grasped faster, simple because 99% of all perl code is
used for
similar problems and is thus much more recognizable.)
> clatter, clatter.] If we rewrite that as
>
> #!/usr/bin/perl
[ code is cut ]
> }
>
> it now runs 60% faster than your version, which means it should now
> outrun the Euphoria example. It's also a fifth the size, though of
> course the Euphoria example does globbing for you too. That might take
> another line of Perl. Oh, and I didn't put in the logic for a grand
> total at the end, but that's just another few lines. On the other
> hand, the Euphoria program has to pull in another 489 lines of include
> files to do what it does, so it's really a 598 line program.
This is a completely dumb remark. Wether parts of the language are provided as
include files
or are part of the code of the interpreter/implementation is irrelevant to the
statement count.
One could even argue that the include files are a much better alternative
because you can see,
alter and understand the logic of them. They are not compiled nor part of the
implementation,
therefor they are only to be written once. Actually the more you can stuff into
include files, the
better. Languages offering all kinds of specific tools built in to them, may be
nice at a certain
point of time, but the expire much faster, and perhaps they're more in the
toy-category to put
it back into your terms.
> Their web page says, "Just say NO to complicated languages." I say, "Just
> say no to complicated solutions."
Hmm, bringing a complex solution back into many small and understandable simple
solutions
is good thing. It creates better maintainable, easier to debug and easier to
understand - code
that also more re-usable. Trying to solve every problem from beginning to end
using one
argument gives the same problem as bringing basic ethical judgement upto the
level of
wether-or-not you are allowed to drive without a beltbelt: the route is so long,
you can be
sure you missed a turn somewhere.
> : But no source.
>
> That is one of the biggest shortcomings. In fact, that's a killer.
> It would appear that for most people, Euphoria is just a temporary
> mental state.
In reality this merely limits its portability and speed of evolvement.
Only in the reality of most hypes, marketing managers, and wannebe-IT-companies
this might
be a killer. Plus, this has, besides portability, absolutely no influence in
the usability of
Euphoria. Wether or not it will exist and be as usable as it is in a 100 years,
are questions so
speculative and hard to make, any attempt is merely a sign of ignorance.
> P.P.S. I suppose we could make Perl run even faster if we do like
> Euphoria and only distribute binaries for Intel CPUs. Then we could
> write it all in 386 assembly...
For a language designer surprisedsed you're not seeing the difference between a
language
implementation and a language specification.
PPS. The code below code 1) be made to run much faster and 2) be programmed
using
much less statement. Simple wrap some of the built-in functionality of Perl is a
basic set of
routines and you would be done. (off course excluding the size of that
*reusable* include
file.) Now, that's where a language should be strong at.
Ralf Nieuwenhuijsen
[[ Email ]]
nieuwen at xs4all.nl
ralf_n at email.com
[[ I-Seek-You ]]
UIN: 9389920
[[ The Elevator ]]
http://www.xs4all.nl/~nieuwen
Download NeoPlanet at http://www.neoplanet.com
3. Re: Eu vs perl
Irv Mullins wrote:
>I found this posted on the perl.porters-gw newsgroup. The
>answer is by none other than Larry Wall himself. Anybody
>beg to differ with him?
*Raises hand.*
I'm responding in part because I *like* Euphoria,
but mostly because I think it's been given a really
bad presentation here...
>simon at brecon.co.uk writes:
>: As seen on today's Freshmeat:
>:
>: Euphoria Programming Language v2.2 for Linux, 32-bit Windows and
>: 32-bit extended DOS. It is simple, flexible, and easy to learn and
>: outperforms all popular interpreted languages.
>: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>--Begin Wall's reply:
>
>Primarily on sieve benchmarks, which of course are terribly representative
>of typical Perl processing. And I do mean terribly...
Hmmm... "primarily on sieve benchmarks". As in, not really
with other benchmarks, such as "typical Perl processing."
Well, since no code or example to support this was given,
I guess I'll have to take your word for it.
>(Of course, you have to expect some level of verbosity from a language
>with a name as long as that. The author of Euphoria obviously doesn't
>carry the gene for carpal tunnel...)
Forgive me, but this is almost pathetic. Let's ignore the fact
that the base for the comment (the length of 'Euphoria') is
just plain silly. Just because one language requires English-
like wording (with clear syntax that, for the most part,
builds on that concept) for its commands, that makes it bad?
You'd think we needed to type "ADD A-VAR TO B-VAR GIVING C-VAR"
to do a simple addition. This "reason" for disliking the
language sounds suspect to me, especially considering that
further on down you seem to want people to think more like
humans than computers (and we all know Perl is infinitely
more human-readable than Euphoria...)
>: but for an interpreted language, it's damned quick.
>
>It's quicker on that problem for several reasons. One, it has integer
>declarations. (You should try the perl with a "use integer".) Two, it
>doesn't really have any strings to speak of, just numeric arrays that
>it pretends are strings. (It's basically a toy language, as far as I'm
>concerned.)
??? Numeric arrays that it pretends are strings? Hmm...
lemme see... strings... numeric arrays... um, I take it
you don't do much C programming? (And just for the
record, since Euphoria manipulates text as sequences
rather than with optimized string routines, is this
really a point one should raise to try to explain away
the speed of the code?)
>Three, it cheats--it looks to me like it steals a bit from
>each integer cell for something else, perhaps to tell whether it's an
>object pointer instead. That'd be equivalent to us using one bit of an
>SV* to say that it's really an integer instead. (I'm guessing this
>from the documented range of integers, which is -1073741824 to
>+1073741823.)
While I can see why someone might prefer to use a full
32 bits and still get integer performance, how on earth
is this cheating? If anything, it's a credit to Rob's
particular implementation of the language (and the fact
that this can be done, without harming the data, says
a lot too.)
>Another reason their interpreter is fast is because it's tuned for
>one architecture.
Oh brother... you know, you could just write a Perl
interpreter optimized for Intels and compare against that.
If the user is using the Intel platform how is this a problem?
>There are a number of shortcomings in Euphoria from the Perl
>programmer's perspective, not the least of which is the traditional
>comp sci mindset of minimalism.
Traditional? Ooookay... (I suppose RISC chips are
traditional as well, just because they couldn't
cram 1000 instructions onto the first integrated
circuit...)
>Which leads to the attitude that
>programmers should think like computers, not like humans.
???!!! Ignoring the actual idea that Euphoria causes
this (addressed above), I'd like to ask how a
minimalist approach causes it?
Oh wait, I see... you must be a northern Native American.
You're equating human thought with the many synonyms in
human language, such as the dozens (hundreds?) of unique
names that you use for types of snow and shades of white.
Huh? What's that? You DON'T use dozens of words to mean
'snow' or 'white'? Oh, well then I guess the analogy is
shot...
>I'm not saying Euphoria isn't good at what it's good at, but
>it's just not good at much of anything that Perl is good at.
If by 'good' you only refer to comparable execution speed,
this statement has been rendered false by this entire example.
(This isn't to say Perl isn't 'better' at some things.
But again, you only seem to be refering to execution speed,
and even then the statement in it's broad sense is false.)
>it now runs 60% faster than your version, which means it should now
>outrun the Euphoria example. It's also a fifth the size, though of
>course the Euphoria example does globbing for you too. That might take
>another line of Perl. Oh, and I didn't put in the logic for a grand
>total at the end, but that's just another few lines. On the other
>hand, the Euphoria program has to pull in another 489 lines of include
>files to do what it does, so it's really a 598 line program.
??? I suppose when tallying the size of a C program,
you include the code in stdio.h...
(Psst: most people looking at this probably are only
concerned with lines *written*, not lines included in
a standard library or imbedded in the interpreter
binary.)
>Why do language designers persist in thinking that simple languages
>produce simple solutions?
Judging from this, I'd say you've completely misunderstood
the entire point of minimalism, and of many "simple
languages" in general.
> All it does is sweep the complexity of the
>problem under someone else's carpet. They're making the same mistake
>as the Rexx folks.
So, because Euphoria has no built-in (or standard library
function) to peform matrix multiplaction, or to download a
web page, or to send Aunt May an email, that indicates a
mistake?
Hey, maybe this APL idea should be pursued a bit further.
Did you design it? Maybe PL/1? No, come on, be honest.
>Their web page says, "Just say NO to complicated languages." I say, "Just
>say no to complicated solutions."
Well, if you want all your solutions pre-packaged, and the
applications using those pre-packaged functions to lack the
speed/readability/etc. benefits of Euphoria, more power to you.
It's all a trade off, although as Euphoria's platform base
diversifies, and certain 'kinks' are addressed, I think the
advantages will become overwhelming.
>: But no source.
>
>That is one of the biggest shortcomings. In fact, that's a killer.
>It would appear that for most people, Euphoria is just a temporary
>mental state.
Yeah, it's a killer... which is why all those closed-
source C compilers out there (ala Microsoft) are losing
market share so rapidly.
>P.P.S. I suppose we could make Perl run even faster if we do like
>Euphoria and only distribute binaries for Intel CPUs. Then we could
>write it all in 386 assembly...
Why don't you? My word, it sounds like you're trying
to make platform optimization a bad thing...
If you feel Perl is superior for certain needs, that's
great. Euphoria's not perfect; it has faults. But to
present Euphoria as an inferior alternative for all Perl
users, especially when such presentation only seems based
on a inadequate knowledge of the language and a personal
dislike of it and the principles it's based on, is just
plain dirty.
Rod Jackson
rodjackson at bigfoot.com
P.S. No, I don't mind having this forwarded....
4. Re: Eu vs perl
- Posted by Robert Craig <rds at ATTCANADA.NET>
Dec 05, 1999
-
Last edited Dec 06, 1999
> : ./lines bigwords 1.03s user 0.05s system 100%
> cpu 1.075 total
> : perl lines.pl bigwords 2.27s user 0.03s system 99%
> cpu 2.307 total
lines.ex took 1.075 total CPU time. The original
lines.pl took 2.307. That makes lines.ex 2.307/1.075=2.15
times faster, i.e. 115% faster.
> it now runs 60% faster than your version, which means
> it should now outrun the Euphoria example.
Huh? He speeded up the original by only 60%.
That's far short of the *115%* that he needs.
> On the other hand, the Euphoria program has to pull
> in another 489 lines of include files to do what it does,
> so it's really a 598 line program.
It's very reasonable to code some standard library
routines in Euphoria itself, because Euphoria code
is fast enough to do the job, and the Euphoria compiler
is fast enough to compile the code in a fraction of a second.
If Euphoria ran at the speed of Perl, people would demand
that I write all routines in C, and bury them in a large
monolithic executable file like Perl.
bin/lines.ex is probably the most "Perlish" of all the programs
in the Euphoria distribution. Perl was *specifically designed*
to scan text files, match patterns, and report results.
Euphoria is more general purpose, but can still beat
Perl on it's own turf.
I'm still waiting to see an action game in Perl.
> It's quicker on that problem for several reasons.
> One, it has integer declarations.
Wrong. You could remove all the integer declarations,
declare everything as atom or even object, and get
the same speed within 1%.
> Two, it doesn't really have any strings to speak of,
> just numeric arrays that it pretends are strings.
I consider that to be a important "feature" of Euphoria.
"Strings" are easily manipulated in Euphoria, and
the core language definition of Euphoria is about 10%
of the size of Perl. By the way, if strings are handled just like
*general* sequences, how would that make them any
faster in Euphoria?
> Three, it cheats--it looks to me like it steals a bit from
> each integer cell for something else, perhaps to tell
> whether it's an object pointer instead.
I guess one man's clever optimization is another man's "cheat".
Euphoria does not limit you to 31-bit integer values, unless
you ask it to. You can always use "atom".
> P.P.S. I suppose we could make Perl run even faster
> if we do like Euphoria and only distribute binaries
> for Intel CPUs. Then we could write it all in 386
> assembly...
Euphoria is written in C, just like Perl.
Assembly is only used in a few very isolated areas
having litte to do with performance.
Euphoria would be much faster than Perl on any CPU.
Euphoria is 34x faster on sieve, which is a pure
CPU burner. People with slow interpreters prefer
to look at benchmarks that:
a) are heavily I/O intensive. Even Euphoria can't make
the operating system run faster, or the disk drive
spin faster. Euphoria's time profiling shows
that (on DOS) 70% of this benchmark's time is
spent on I/O. (I didn't realize it would become a
benchmark when I wrote it.)
b) depend heavily on special features that are built-in to the
interpreter so as to avoid having to execute many
statements in the interpreted language itself.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
5. Re: Eu vs perl
I can answer one SHORT thing on this thread:
Take a lambda user.
give him Half an hour the euphoria documentation.
give him Half an hour to read the perl documentation.
ask him to write a program.
with euphoria he does the job.
with perl he gets out to drink a guinness.
Yes, I understood the meaning of "Rapid Deployment" when I really wrote a
test program.
Just half an hour.
Thats why I'd like to have euphoria on sparcstation/Solaris...
Riwal Raude
rauder at thmulti.com
> -----Original Message-----
> From: Robert Craig [SMTP:rds at ATTCANADA.NET]
> Sent: Monday, December 06, 1999 5:14 AM
> To: EUPHORIA at LISTSERV.MUOHIO.EDU
> Subject: Re: Eu vs perl
>
> > : ./lines bigwords 1.03s user 0.05s system 100%
> > cpu 1.075 total
> > : perl lines.pl bigwords 2.27s user 0.03s system 99%
> > cpu 2.307 total
>
> lines.ex took 1.075 total CPU time. The original
> lines.pl took 2.307. That makes lines.ex 2.307/1.075=2.15
> times faster, i.e. 115% faster.
>
> > it now runs 60% faster than your version, which means
> > it should now outrun the Euphoria example.
>
> Huh? He speeded up the original by only 60%.
> That's far short of the *115%* that he needs.
>
> > On the other hand, the Euphoria program has to pull
> > in another 489 lines of include files to do what it does,
> > so it's really a 598 line program.
>
> It's very reasonable to code some standard library
> routines in Euphoria itself, because Euphoria code
> is fast enough to do the job, and the Euphoria compiler
> is fast enough to compile the code in a fraction of a second.
> If Euphoria ran at the speed of Perl, people would demand
> that I write all routines in C, and bury them in a large
> monolithic executable file like Perl.
>
> bin/lines.ex is probably the most "Perlish" of all the programs
> in the Euphoria distribution. Perl was *specifically designed*
> to scan text files, match patterns, and report results.
> Euphoria is more general purpose, but can still beat
> Perl on it's own turf.
> I'm still waiting to see an action game in Perl.
>
> > It's quicker on that problem for several reasons.
> > One, it has integer declarations.
>
> Wrong. You could remove all the integer declarations,
> declare everything as atom or even object, and get
> the same speed within 1%.
>
> > Two, it doesn't really have any strings to speak of,
> > just numeric arrays that it pretends are strings.
>
> I consider that to be a important "feature" of Euphoria.
> "Strings" are easily manipulated in Euphoria, and
> the core language definition of Euphoria is about 10%
> of the size of Perl. By the way, if strings are handled just like
> *general* sequences, how would that make them any
> faster in Euphoria?
>
> > Three, it cheats--it looks to me like it steals a bit from
> > each integer cell for something else, perhaps to tell
> > whether it's an object pointer instead.
>
> I guess one man's clever optimization is another man's "cheat".
> Euphoria does not limit you to 31-bit integer values, unless
> you ask it to. You can always use "atom".
>
> > P.P.S. I suppose we could make Perl run even faster
> > if we do like Euphoria and only distribute binaries
> > for Intel CPUs. Then we could write it all in 386
> > assembly...
>
> Euphoria is written in C, just like Perl.
> Assembly is only used in a few very isolated areas
> having litte to do with performance.
> Euphoria would be much faster than Perl on any CPU.
> Euphoria is 34x faster on sieve, which is a pure
> CPU burner. People with slow interpreters prefer
> to look at benchmarks that:
>
> a) are heavily I/O intensive. Even Euphoria can't make
> the operating system run faster, or the disk drive
> spin faster. Euphoria's time profiling shows
> that (on DOS) 70% of this benchmark's time is
> spent on I/O. (I didn't realize it would become a
> benchmark when I wrote it.)
>
> b) depend heavily on special features that are built-in to the
> interpreter so as to avoid having to execute many
> statements in the interpreted language itself.
>
> Regards,
> Rob Craig
> Rapid Deployment Software
> http://www.RapidEuphoria.com
6. Re: Eu vs perl
From: Raude Riwal <RAUDER at THMULTI.COM>
> I can answer one SHORT thing on this thread:
> Take a lambda user.
> give him Half an hour the euphoria documentation.
> give him Half an hour to read the perl documentation.
> ask him to write a program.
> with euphoria he does the job.
> with perl he gets out to drink a guinness.
OK, I agree, Perl does have that _one_ advantage...
but the code only begins to make sense after 3 or 4 Guinnesses.
Irv
7. Re: Eu vs perl
Irv Mullins wrote:
>From: Raude Riwal <RAUDER at THMULTI.COM>
>
>> I can answer one SHORT thing on this thread:
>> Take a lambda user.
>> give him Half an hour the euphoria documentation.
>> give him Half an hour to read the perl documentation.
>> ask him to write a program.
>> with euphoria he does the job.
>> with perl he gets out to drink a guinness.
>
>OK, I agree, Perl does have that _one_ advantage...
>but the code only begins to make sense after 3 or 4 Guinnesses.
I suspect "Language Wars" might have a new enemy ship
once the DOS/Win version 2.2 releases...
Rod Jackson
8. Re: Eu vs perl
From: Roderick Jackson <rjackson at CSIWEB.COM>
Subject: Re: Eu vs perl
I forwarded Rob's rebuttal, along with my comments, to Mr. Wall.
He was nice enough to send me an e-mail in return, but unfortunately
didn't bother to address but one of the points brought up by Rob.
Since it's long winded, I'll just quote part here:
Quote:
"Incidentally, I rewrote the sieve benchmark in decent Perl, and it's
only 7.4 times slower. So don't believe all the Euphoria hype either
about Perl being 34 times slower than Euphoria."
He's actually proud of this. Sigh..... and again, he has his numbers wrong.
I read 44x
Quote:
"I've read all the archives of the Euphoria mailing list,
and there seems to be a persistent ignorance about the existence of
Perl's debugger. This tells me there is nobody in the Euphoria
community who knows Perl."
Hell, I, for one, know about perl -d. Pretty primitive, isn't it?
I had commented on the unreadability of Perl:
Quote:
"Good grief. Perl is extremely readable to at least a million people,
not just the language designer. Stop parroting your hypemeisters."
I thanked him for his reply and told him that, next time I have to write
an accounting program where the source must be audited, I'll be sure to use
Perl.:)
Mr. Wall seems awfully concerned about what he terms "a toy language",
doesn't
he?
Irv
9. Re: Eu vs perl
Irv Mullins wrote:
>From: Raude Riwal <RAUDER at THMULTI.COM>
>
>
>> I can answer one SHORT thing on this thread:
>> Take a lambda user.
>> give him Half an hour the euphoria documentation.
>> give him Half an hour to read the perl documentation.
>> ask him to write a program.
>> with euphoria he does the job.
>> with perl he gets out to drink a guinness.
>
>OK, I agree, Perl does have that _one_ advantage...
>but the code only begins to make sense after 3 or 4 Guinnesses.
>
>Irv
Which proves that the Perl coder had no taste to begin with...Guiness?!
The one thing that is made crystal clear by the examples offered is
that Euphoria is highly readable while performing at a similar level to
Perl. Any mildly experienced programmer could read the Euphoria
example without any reference to any documentation. If I am any
sample, the same cannot be said for the Perl code. The objection
about includes as opposed to compiler embed is a performance
issue at best and a complete canard at worst. The availability of
some of the functionality that Perl has by whatever means is
probably the only really valid issue here. Standard libraries for what
IMHO are standard functionalities in this modern world are not an
option, but a necessity. Clean calls to external functionality where
there are no standard libraries are a workable stand-in. Portability
taken as a whole is approaching necessity in this world of fragmenting
OS and hardware standards. Perl has met these requirements and so
has progressed despite it's manifest ugliness. I cannot believe that
given anything close to equal facilities that Euphoria would not swiftly
displace Perl or almost any other language that I have seen.
The one blind spot that would trip this little scenario is the doctrinaire,
silly attitude toward string functionality. As we approach a fully real-time,
interactive world, the strings that form the languages that we use for
normal, everyday interaction with each other will also become the
interface for our interaction with our machines. Any language that cannot
deal comfortably - naturally - intuitively with this reality will fall into
disuse. What is so almost amusing is that the language itself, Euphoria,
is most effective in providing understandable strings for the interface
between machine and programmer. If this approach could be extended
to string functionality in dealing with the data that is handled by these
programs, no limits would be found to the use of this language.
I am sure that any Euphorian solution to string handling will be in the
oh so delicate terms of Mr. Wall "verbose". But, with a little thought, this
can be kept to a minimum while retaining the readability and overall
efficiency of Euphoria. A little verbosity would be oh so preferrable to
the delimiter soup represented by Mr. Wall's Perl samples. For example,
a simple overloading of present operators can account quite effectively
for most of the simplest needs and is actually already in place if strings
were a recognized, enforced data type.
Everett L.(Rett) Williams
rett at gvtc.com
10. Re: Eu vs perl
Everett Williams wrote:
> The one blind spot that would trip this little scenario
> is the doctrinaire, silly attitude toward string functionality.
I've seen this comment appear a number of times, and I still can't grasp the
point you are trying to make here.
A Euphoria string behaves much like a C string, and allows the same sort of
operations. In fact, Euphoria strings have the additional benefit of not
being byte size, allowing you to (theoretically) work with non-byte
solutions, such as UNICODE.
I'm not trying to be a Euphoria bigot here - I really can't see what that is
missing from the language.
-- David Cuny
11. Re: Eu vs perl
- Posted by Everett Williams <rett at GVTC.COM>
Dec 07, 1999
-
Last edited Dec 08, 1999
On Tue, 7 Dec 1999 13:19:45 -0800, Cuny, David at DSS <David.Cuny at DSS.CA.GOV>
wrote:
>Everett Williams wrote:
>
>> The one blind spot that would trip this little scenario
>> is the doctrinaire, silly attitude toward string functionality.
>
>I've seen this comment appear a number of times, and I still can't grasp the
>point you are trying to make here.
>
>A Euphoria string behaves much like a C string, and allows the same sort of
>operations. In fact, Euphoria strings have the additional benefit of not
>being byte size, allowing you to (theoretically) work with non-byte
>solutions, such as UNICODE.
>
>I'm not trying to be a Euphoria bigot here - I really can't see what that is
>missing from the language.
>
>-- David Cuny
I have acted as checker and design consultant on C programs, but I do not,
and will not code in C. I don't care what size internal "thing" Euphoria uses
for it's purposes in handling string types. String types are determined by
the character set or standard on which they are based. For our current
purposes, text means the ASCII text standard. It could just as well be
the double byte international standard, or one of a dozen other less well
known, but sometimes more common symbol or character sets or
standards (the one that comes to mind as being the most extreme example
of that is EBCDIC).
Regardless, if it is represented by a type, no legal action that can be taken
on a string or one of it's elements should legally result in something that is
not a member of that type. The treatment of string elements in Euphoria is
completely contradictory. The "string" format implicitly indicates a string
type, but does in no way follow through on that implicit promise. Various
conversions from external text string format to Euphoria internal format are
built into the language without any explicit recognition of the fact. Since
we as humans cannot express ourselves on forums like this without the
strings that we call language, it is really inconsistent to declare that strings
are just sequences of numbers. By that logic, gold is just another metal...
and I'll be glad to exchange all my copper on a pound for pound basis with
your gold if you believe that.
Nothing about the "meaning" or "grammar" of sentences in any spoken
language is dependent on or even implicitly or explicitly aware of the
behaviors of the numbers that in Euphoria are represented as being fully
equivalent to the string elements. What is even more interesting is that
Euphoria itself is written in text strings that are most carefully parsed and
treated as ASCII strings stored four ASCII bytes to a 32 bit word. This
approaches a schizophrenic status. It is obvious that Euphoria could not be
made compatible with any other editor or programming tool if it was stored
by the rules that Euphoria follows for internal storage and handling of "string"
data.
I am in no way indicating that string problems are trivial or even simple.
Whole languages have been written to allow handling of strings in "logical"
manners. Regular expression evaluators cannot be made complete
without limiting the definition of what they handle. Delimiters represent
almost insoluble problems, at least theoretically. One only has to look
at what happens when consecutive regular expression evaluators have to
handle the same string that contains delimiters alternately "specially"
defined by one or the other of the evaluators. The reason that many
language designers avoid specific string handling routines is simply because
of the absolute complexity of deciding what is and isn't a valid, delimited
string. Typically, some not too draconian assumptions are made and
exceptions are handled by preconditioning strings where necessary. If
string handling weren't so vitally necessary, I would be very tempted to
take Rob's stance, wave the magic number wand, and make strings
go away.
Everett L.(Rett) Williams
rett at gvtc.com
12. Re: Eu vs perl
Everett Williams wrote:
<snip>
I understand your philisophical distaste for allowing non-char values into
'string' sequences, and the 32 bit internal implementation. But on a
practical matter, so what? I still don't see what practical issues it poses
to me, or anyone else, when writing code.
Perhaps an actual example might be in order? What exactly are you trying to
accomplish that Euphoria's implementation of strings won't allow?
-- David Cuny
13. Re: Eu vs perl
On Mon, 6 Dec 1999 17:45:02 -0800, David Cuny <dcuny at LANSET.COM> wrote:
>Everett Williams wrote:
>
><snip>
>
>I understand your philisophical distaste for allowing non-char values into
>'string' sequences, and the 32 bit internal implementation. But on a
>practical matter, so what? I still don't see what practical issues it poses
>to me, or anyone else, when writing code.
>
>Perhaps an actual example might be in order? What exactly are you trying to
>accomplish that Euphoria's implementation of strings won't allow?
>
>-- David Cuny
If an integer or atom misbehaved in a similar manner by failing to control for
type characteristics, all would be up in arms. Inertia justifies all.
Efficient detection of the intrusion of those non-char values into a "string"
sequence is one thing that I would like to have accomplished. Of course,
having that detection without error routines would not be much help.
Recognition of strings as a special type would require dealing with
environments where double bytes are the default string type. Portability.
Language translation for Euphoria where alphabets differ drastically...such
as in Russian. I will go on later as other circumstances come to mind.
Everett L.(Rett) Williams
rett at gvtc.com
14. Re: Eu vs perl
----- Original Message -----
From: Everett Williams <rett at GVTC.COM>
To: <EUPHORIA at LISTSERV.MUOHIO.EDU>
Sent: Wednesday, December 08, 1999 12:28 AM
Subject: Re: Eu vs perl
> Efficient detection of the intrusion of those non-char values into a
"string"
> sequence is one thing that I would like to have accomplished. >
Who decides which are valid chars?
Kat
15. Re: Eu vs perl
> Quote:
> "I've read all the archives of the Euphoria mailing list,
> and there seems to be a persistent ignorance about the existence of
> Perl's debugger. This tells me there is nobody in the Euphoria
> community who knows Perl."
>
Wow! all the archive! for such an active list! maybe he'll switch to
euphoria too...
And why should we discuss about a perl debugger on our list? and why
not
discuss about VEL on a perl list?
> Quote:
> "Good grief. Perl is extremely readable to at least a million people,
> not just the language designer. Stop parroting your hypemeisters."
>
Extremely?
Euphoria is much more readable to the same million, and also to the
others.
Riwal
16. Re: Eu vs perl
Everett sez:
>
> > Efficient detection of the intrusion of those non-char values into a
> "string"
> > sequence is one thing that I would like to have accomplished. >
>
Kat asks:
> Who decides which are valid chars?
>
Thanks, Kat. I was wondering when someone would finally ask that question.
Whoever answers it, please take into account Norm Goundry and his crew need
for somewhat more than the usual 256 characters for their Chinese strings -
21,000 last time I checked.
Regards,
Irv
17. Re: Eu vs perl
From: Raude Riwal <RAUDER at THMULTI.COM>
> > Quote:
> > "I've read all the archives of the Euphoria mailing list,
> > and there seems to be a persistent ignorance about the existence of
> > Perl's debugger. This tells me there is nobody in the Euphoria
> > community who knows Perl."
> >
> Wow! all the archive! for such an active list! maybe he'll switch to
> euphoria too...
> And why should we discuss about a perl debugger on our list? and why
> not discuss about VEL on a perl list?
A quick search of the Euphoria archives shows no mention of a perl debugger
except for my message yesterday and your reply. The fact that no one
considers
perl's primitive debugger worth emulating is probably why it hasn't been
discussed.
Since Mr. Wall seems unable to respond to actual challenges (i.e. the 44x)
without resorting to Clintonesque diversionary tactics, I have no further
interest in
his opinions.
By the way, speaking of lists, the Python newsgroup is much like this one,
filled with people trying to be helpful. It's a pleasant change from the
smoke
and flames on the perl groups, where the stock answer to any question seems
to be "RTFM you #\$\%" <-- note: this is either an insult or example perl
code,
I can't tell which :)
Irv
18. Re: Eu vs perl
Kat wrote:
>From: Everett Williams
>Subject: Re: Eu vs perl
>
>
>> Efficient detection of the intrusion of those non-char values into a
>"string"
>> sequence is one thing that I would like to have accomplished. >
>
>Who decides which are valid chars?
>
>Kat
Well let's see. If I am dealing with ASCII text characters, any value greater
than 255 would be a start. If I am dealing with double byte characters, any
value that won't fit into a double byte. The standards are published and
clear. What can I add to them?
You may have missed a post, but Eu is already paying a lot of attention to
the ASCII character set in every way but in explicit typing.
Everett L.(Rett) Williams
rett at gvtc.com
19. Re: Eu vs perl
Everett Williams wrote:
> Well let's see. If I am dealing with ASCII text characters, any value greater
> than 255 would be a start. If I am dealing with double byte characters, any
> value that won't fit into a double byte. The standards are published and
> clear. What can I add to them?
How about a real-world example of where this has caused a problem?
Irv
20. Re: Eu vs perl
----- Original Message -----
From: Irv Mullins <irv at ELLIJAY.COM>
To: <EUPHORIA at LISTSERV.MUOHIO.EDU>
Sent: Wednesday, December 08, 1999 11:24 AM
Subject: Re: Eu vs perl
> Everett Williams wrote:
>
> > Well let's see. If I am dealing with ASCII text characters, any value
greater
> > than 255 would be a start. If I am dealing with double byte characters,
any
> > value that won't fit into a double byte. The standards are published and
> > clear. What can I add to them?
>
> How about a real-world example of where this has caused a problem?
Actually, there is an example in the archives somewhere, or in the docs,
where hour was defined as a range of 0-24 ( 0 to 24 hours in a day ), and if
one attempted to hour = 25 , Eu faulted on not correct type or out of range.
But i don't remember atm where this was. So Everett, maybe you could use
this as string *typing*, but what i was after was more *functionality* in
string manipulation, like the working code examples i gave. I don't know how
you'd skip the ascii lowercase letters up to the ascii uppercase letters
this way either, i haven't tried it, maybe if you described UppercaseChars
and LowercaseChars, then joined them in the type definition, maybe?
Kat,
not so minimalist, but simplist(?).
21. Re: Eu vs perl
Everett Williams wrote:
> If an integer or atom misbehaved in a similar manner by
> failing to control for type characteristics, all would be up
> in arms. Inertia justifies all.
Why stop at strings? What about if I wanted an array of integers?
By the same logic, I shouldn't use a sequence to store an array of integers,
because Euphoria doesn't ensure that a non-integer won't intrude into the
sequence.
I'm not sure where all the rogue data values are coming from, but if you are
really concerned about keeping the data values in range, you can always
write:
s = and_bits( s, #FF )
and all your values are coerced into submission.
> Efficient detection of the intrusion of those non-char values
> into a "string" sequence is one thing that I would like to have
> accomplished.
The most efficient place to detect an 'intrusion' would be at the point
before the element was added to the "string". Imagine that Euphoria actually
did detect non-char elements in strings. Something along the lines of:
global type string( object o )
atom a
if not sequence( o ) then
return False
else
for i = 1 to length( o ) do
a = o[i]
if and_bits( a, #FF ) != a then
return False
end if
end for
end if
return True
end type
What happens when a non-char is detected? Euphoria generates an error and
shuts down. Not especially helpful.
> Language translation for Euphoria where alphabets
> differ drastically.
Actually, since Euphoria allows up to 32 bit values in sequences, it's even
more suited to handling wide character data than most languages with
'string' operators.
Have you encountered any real cases where Euphoria's handling of 'strings'
is problematic? So far, this 'flaw' still remains theoretical.
-- David Cuny
22. Re: Eu vs perl
Irv Mullins wrote:
>By the way, speaking of lists, the Python newsgroup is much like this one,
>filled with people trying to be helpful. It's a pleasant change from the
>smoke
>and flames on the perl groups, where the stock answer to any question seems
>to be "RTFM you #\$\%" <-- note: this is either an insult or example perl
>code,
>I can't tell which :)
>
>Irv
Thankyou Irv for my belly laugh of the day.
Everett L.(Rett) Williams
rett at gvtc.com
23. Re: Eu vs perl
On Wed, 8 Dec 1999 12:24:14 -0500, Irv Mullins <irv at ELLIJAY.COM> wrote:
> Everett Williams wrote:
>
>> Well let's see. If I am dealing with ASCII text characters, any value greater
>> than 255 would be a start. If I am dealing with double byte characters, any
>> value that won't fit into a double byte. The standards are published and
>> clear. What can I add to them?
>
>How about a real-world example of where this has caused a problem?
>
>Irv
Any corrupted or hybrid input string will cause troubles. Since Euphoria does
not easily lend itself to generalized text handling, there doesn't seem to
be much sample code for me to work from. I realize that those that have
been coding for a while in a language instinctively avoid situations where
such problems might occur. That doesn't mean that they can't, or won't
happen.
Remember that not all input strings come from IO, but from external
routines that return string values to Euphoria that are not checked by
any of Euphoria's oddly, partially string-sensitive IO routines.
Everett L.(Rett) Williams
rett at gvtc.com
24. Re: Eu vs perl
Kat wrote:
> Irv Mullins wrote
>Subject: Re: Eu vs perl
>
>> Everett Williams wrote:
>>
>> > Well let's see. If I am dealing with ASCII text characters, any value
>greater
>> > than 255 would be a start. If I am dealing with double byte characters,
>any
>> > value that won't fit into a double byte. The standards are published and
>> > clear. What can I add to them?
>>
>> How about a real-world example of where this has caused a problem?
>
>Actually, there is an example in the archives somewhere, or in the docs,
>where hour was defined as a range of 0-24 ( 0 to 24 hours in a day ), and if
>one attempted to hour = 25 , Eu faulted on not correct type or out of range.
>But i don't remember atm where this was. So Everett, maybe you could use
>this as string *typing*, but what i was after was more *functionality* in
>string manipulation, like the working code examples i gave. I don't know how
>you'd skip the ascii lowercase letters up to the ascii uppercase letters
>this way either, i haven't tried it, maybe if you described UppercaseChars
>and LowercaseChars, then joined them in the type definition, maybe?
>
>Kat,
>not so minimalist, but simplist(?).
The example you cite is in the online manual for 2.1 I really hate to use
ANYTHING that MS has as an example, but here we go. The whole code
page thing in MS triggers a cascading group of effects on strings,
alphabetizing, sorts in general, upper/lower case and so on. The subject
is complex, but really necessary unless you are going to limit yourself to
standard english. The issues still exist in standard english, but don't cause
the variations in code for handling. It is possible to limit a language to
english and survive in this Anglicized commercial world, but it isn't
necessarily desireable.
Everett L.(Rett) Williams
rett at gvtc.com
25. Re: Eu vs perl
David Cuny wrote:
>Everett Williams wrote:
>
>> If an integer or atom misbehaved in a similar manner by
>> failing to control for type characteristics, all would be up
>> in arms. Inertia justifies all.
>
>Why stop at strings? What about if I wanted an array of integers?
>
>By the same logic, I shouldn't use a sequence to store an array of integers,
>because Euphoria doesn't ensure that a non-integer won't intrude into the
>sequence.
Actually, you are correct. We don't really know that sequence elements are
any particular thing except that we really do...sort of... in some
circumstances. I love that sequences can contain anything. I don't love
that I can't really control what that something is. I can't name it, I can't
control it. It's kind of like that infinitely extendable sack that I always
wanted without anyway to really get to any particular thing in the sack
unless I remember which order I put the things into the sack. Even if the
darn thing had a name on it before it went in there, it got lost in the sack.
Grrr...
What's even worse is that some of your integers may turn into floats
without passing go or even asking me about it. And speaking of confusing...
the float part of this language really bamboozles me. All items are 32
bit unless Eu decides they are not. And they are integers until they need
to be floats that may be 64 bit. It turns out that you can't have your
integer array at all because all elements of sequences are either atoms or
sequences. Now, where in every other post I have gotten, I have been
encouraged to write "libraries" of procedures and functions to handle things
that I want, Euphoria has taken this one away from me and won't even
let me reasonably manage this area...go figure. Please let me type and
name sequence elements. Let those types and names move when
split by inserted elements. Better yet, let me declare some sequences as
non-dynamic. Should simplify the code to deal with them and allow some
really nice optimizations. If they are to be dynamic, let them only be
modified by nested structure occurrences...that is if we have nested
structures. Still should allow great optimization.
>I'm not sure where all the rogue data values are coming from, but if you are
>really concerned about keeping the data values in range, you can always
>write:
>
> s = and_bits( s, #FF )
>
>and all your values are coerced into submission.
>
>
>> Efficient detection of the intrusion of those non-char values
>> into a "string" sequence is one thing that I would like to have
>> accomplished.
>
>The most efficient place to detect an 'intrusion' would be at the point
>before the element was added to the "string". Imagine that Euphoria actually
>did detect non-char elements in strings. Something along the lines of:
>
> global type string( object o )
> atom a
> if not sequence( o ) then
> return False
> else
> for i = 1 to length( o ) do
> a = o[i]
> if and_bits( a, #FF ) != a then
> return False
> end if
> end for
> end if
> return True
> end type
>
>What happens when a non-char is detected? Euphoria generates an error and
>shuts down. Not especially helpful.
Well, you have this one right...as noted in another post, this one scans the
whole string, no matter what small part of it is affected. Only internal type
checking can deal with the pieces of a string as they are changed, inserted,
or deleted. It also does a nice job of pointing out the absolute need for
error routines where control of the input is not in the hands of the
programmer.
>> Language translation for Euphoria where alphabets
>> differ drastically.
>
>Actually, since Euphoria allows up to 32 bit values in sequences, it's even
>more suited to handling wide character data than most languages with
>'string' operators.
You're back to that string/number equivalence argument...ain't so. In actuality,
one of the other illnesses in this language, the constant, is another,
similar misunderstanding of that equivalence. Calling 5 "five" tries to
establish an equivalence between a number and a string based on the
meta-data meaning of that string except that number is not the data referred
to, it is the INDEX of the data referred to - complete loss of meaning. Not all
the king's horses and all the king's men can tie that mismatched pair together
on a permanent basis. As noted before, constants aren't necessary to a
minimalist interpreter. There only real use is to make the interpreter's
internal
job easier. They also are evidence of what the rest of us want with
structures...consistent naming of items in accordance with their meta-data
values. Structures, however, do not lead to the same paradoxes that
constants do.
>Have you encountered any real cases where Euphoria's handling of 'strings'
>is problematic? So far, this 'flaw' still remains theoretical.
>
>-- David Cuny
Ball's back in your court on this one.
26. Re: Eu vs perl
Everett Williams wrote:
>> Have you encountered any real cases where Euphoria's
>> handling of 'strings' is problematic? So far, this
>> 'flaw' still remains theoretical.
>
> Ball's back in your court on this one.
Can you actually show me a Real Life (tm) example of code proving your
point? I've yet to see any.
-- David Cuny
27. Re: Eu vs perl
- Posted by Everett Williams <rett at GVTC.COM>
Dec 08, 1999
-
Last edited Dec 09, 1999
David Cuny wrote:
>Everett Williams wrote:
>
>>> Have you encountered any real cases where Euphoria's
>>> handling of 'strings' is problematic? So far, this
>>> 'flaw' still remains theoretical.
>>
>> Ball's back in your court on this one.
>
>Can you actually show me a Real Life (tm) example of code proving your
>point? I've yet to see any.
>
>-- David Cuny
I have coded some examples of things that I have interests in discussing
on this list. I have no intention of spending more than token amounts of
time coding in Euphoria until some of the issues like name space are
dealt with. Until that time, Mr. Wall was only right on one part of his
statement. Euphoria is a toy language...that has the potential to grow
up into a bull-dozer. I picked name_space as an example, because it should
have almost zero effect on performance. Data structures are an allied and
IMO another area that should have almost zero negative effect on
performance with real potential for optimizations in fixed structures.
Without name spaces and structures and maybe some associated
modularity improvements, real multi-programmer cooperation on code
is made problematic at best...and I am at least knowledgeable on that
subject...having done a fairly complete redesign of a code management
product sold in a multi-platform market. Data structures provide somewhat
self-documenting interfaces, and name space separates coding efforts
without constant communication about "Did you use this procedure name?"
or variable name.
The problems with external data passed through the call interface for
things like Internet functionality are or should be obvious to someone with
your experience. Paradoxes in basic design will eventually come to
fruition in code problems. You can rag on me all you want, but it is not going
to
solve the problems that are extant. And the offer still stands to help
in any way that I can on your common GUI emulation. That is a move in the
right direction. Hopefully, RDS will provide us with some of the facilities to
leverage that effort.
Everett L.(Rett) Williams
rett at gvtc.com
28. Re: Eu vs perl
- Posted by David Cuny <dcuny at LANSET.COM>
Dec 07, 1999
-
Last edited Dec 08, 1999
Everett Williams wrote:
> I have coded some examples of things that I have
> interests in discussing on this list. I have no intention
> of spending more than token amounts of time coding
> in Euphoria until some of the issues like name space are
> dealt with.
It seems the most effective way to get change to write code that pushes the
boundaries of the existing system.
Plenty of large C projects seem to get along just fine without namespace, by
using naming conventions. I'd adding prefixes the my routine names and
constants; for example:
wmCreateWindow() -- function name
WM_DialogWindow -- constant
> You can rag on me all you want, but it is not going to
> solve the problems that are extant.
My intent isn't to 'rag' on you; I've been working with Euphoria for some
time now, and I've yet to encounter the sort of problems you describe.
> And the offer still stands to help in any way that I can on
> your common GUI emulation. That is a move in the
> right direction.
Thanks; I'll take you up on your offer.
-- David Cuny
29. Re: Eu vs perl
David Cuny wrote:
snip
>It seems the most effective way to get change to write code that pushes the
>boundaries of the existing system.
That would be an area that you are a better judge of than I. You certainly
have pushed the boundaries, and I mean that in the most complimentary way.
>Plenty of large C projects seem to get along just fine without namespace, by
>using naming conventions. I'd adding prefixes the my routine names and
>constants; for example:
>
> wmCreateWindow() -- function name
> WM_DialogWindow -- constant
The problem with programmer added prefixes is that they are static and do
not allow for multiple occurrences. If I have a structure that describes a
file, I may have three files with the same structure open at the same time.
Do I recode the structure three times with a different prefix every time.
Seems silly and wasteful to me as well as not really answering to the
problem. I may have a variable number of files open with the same structure.
How do I deal with that situation without variable prefixing...oops...probably
should ask for one thing at a time. If I get prefixing, I'll figure out the
rest...
though one could wish! Constants with or without manual or automatic
prefixes are an abomination when they are used for indexing. They are
barely tolerable when they directly represent meta-data such as:
constant five = 5
Umptee -Umpth repetition. Constants are not necessary in a "minimalist"
language.
>> You can rag on me all you want, but it is not going to
>> solve the problems that are extant.
>
>My intent isn't to 'rag' on you; I've been working with Euphoria for some
>time now, and I've yet to encounter the sort of problems you describe.
And I shouldn't accuse. I share some of Jiri's irritation with the "way" that
the libs you have written are headed, but I also recognize that this
language would be sitting virtually unused if it wasn't for that very work.
It irritates me to see such effort put into code that may not easily be
portable between major versions of the same operating system, much
less between OS's and machines. That is not your fault. It is the result of
the tools at hand. The portablility efforts you are making suffer from the
same problems for the same reasons, but certainly should require less
"trimming" than previous efforts.
I'm not quite as irritable as Jiri, but after the third demand for code I got a
little crotchety. I will say that I have looked at many of the things that you
have done and liked most, but I have not seen much generic string
handling done in your programs...and program editors don't count, since
they are completely structured by the grammar of the language and have
strict definitions of the set of possible strings to be handled. That could
be about a million miles wrong, since you obviously write a lot of code...but
it was an impression.
Try to do human language parsing to establish structure, much less meaning
and intent, and you will swiftly run into the type of paradoxes built into
human language. Having paradoxical constructs in the language that you
are trying to use to do the analysis is no help at all. Both libraries and some
native constructs would be helpful for tasks that deal with these complexities.
Streams of input data from places like the internet will also trigger these
kinds
of needs.
Everett L.(Rett) Williams
rett at gvtc.com
30. Re: Eu vs perl
Everett Williams wrote:
> The problem with programmer added prefixes is that they
> are static and do not allow for multiple occurrences. If I have
> a structure that describes a file, I may have three files with
> the same structure open at the same time.
I've used two different ways to deal with this. I can create a 'generic'
sequence to hold everything:
sequence the
the = {}
The data structure describing objects:
constant
Name = 1,
SSN = 2
And a routine to create new objects:
function newItem()
the = append( the, repeat( 0, 100 )
return length( the )
end function
Here's a generic 'set' and 'get' function:
procedure Set( integer self, integer attribute, object value )
the[self][attribute] = value
end procedure
function Get( integer self, integer attribute )
return the[self][attribute]
end procedure
I can then create new objects:
constant Fred = newItem()
constant Joe = newItem()
and assign and modify them:
Set( Fred, Name, "Fred" )
Set( Fred, SSN, "000-00-0000" )
Set( Joe, Name, "Joe" )
Set( Joe, SSN, "111-11-1111" )
Which is the same as:
the[Fred][Name] = "Fred"
the[Fred][SSN] = "000-00-0000"
the[Joe][Name] = "Joe"
the[Joe][SSN] = "111-11-1111"
Not entirely elegant, but it gets the job done. That's the approach Llama
took. The double indexing is expensive, and using Get/Set makes it more so.
Llama was rightly criticized as having a lot of overhead in the data
structures.
In my new toolkit, I take a slightly different approach:
sequence name, ssn
name = {}
ssn = {}
function newItem()
name = append( name, "" )
ssn = append( ssn, "" )
return length( name )
end function
Working with objects is now:
constant Fred = newItem()
constant Joe = newItem()
name[Fred] = "Fred"
ssn[Fred] = "000-00-0000"
name[Joe] = "Joe"
ssn[Joe] = "111-11-1111"
> Constants are not necessary in a "minimalist"
> language.
I don't share this dislike of constants. Writing:
the[SSN]
makes a lot more sense than:
the[3]
> And I shouldn't accuse. I share some of Jiri's irritation with
> the "way" that the libs you have written are headed ...
I assume by 'the "way"', you are referring to GUI applications, as opposed
to DOS applications. Jiri's complaints seem to be less that I'm writing GUI
code, and more that a "DOS" forum is constantly polluted with Windows code.
> but I also recognize that this language would be sitting
> virtually unused if it wasn't for that very work.
Looking at the huge number of DOS contributions on the Euphoria web page,
I'd have to disagree.
> I'm not quite as irritable as Jiri, but after the third demand
> for code I got a little crotchety.
But I don't think it's an unreasonable demand. If you can't show me an
example of code that demonstrates your claim, then it's difficult for me to
believe there's an issue.
> but I have not seen much generic string
> handling done in your programs...
I'm not sure what you mean by 'generic string handling'. I've posted several
programs with fairly complex parsers. eBasic converts QBasic code into
Euphoria using an LL(1) grammar. PP is a pre-processor for Euphoria that
'enhances' the language with a number of interesting constructs. Eu parses
and executes Euphoria code. On a smaller scale, Fix functions much the same
as Euphoria's Shroud routine, but correctly handles routine_id, and Res
creates resource files by parsing source files. I've posted a couple generic
pattern matching routines as well.
-- David Cuny
31. Re: Eu vs perl
On Wed, 08 Dec 1999, you wrote:
> David Cuny wrote:
>
> >Everett Williams wrote:
> >
> >>> Have you encountered any real cases where Euphoria's
> >>> handling of 'strings' is problematic? So far, this
> >>> 'flaw' still remains theoretical.
> >>
> >> Ball's back in your court on this one.
> >
> >Can you actually show me a Real Life (tm) example of code proving your
> >point? I've yet to see any.
> >
> >-- David Cuny
>
> I have coded some examples of things that I have interests in discussing
> on this list. I have no intention of spending more than token amounts of
> time coding in Euphoria until some of the issues like name space are
> dealt with...
<snip here, as the Everett express has switched tracks again>
We're talking about 3 or 4 lines of code, here. I thought I might find some
examples in some of my working programs, as most of them read and write data
files created by dBase, Pascal, or VB programs. There are a lot of lines that
deal with conversion between VB and Pascal integers/reals/doubles and Euphoria
integers/atoms, but nowhere can I find anything that indicates any difficulty
reading, writing or converting strings.
So we have to wait for your example.
Irv
32. Re: Eu vs perl
On Thu, 09 Dec 1999, Everett Williams wrote:
> I'm not quite as irritable as Jiri, but after the third demand for code I got
> a
> little crotchety. I will say that I have looked at many of the things that you
> have done and liked most, but I have not seen much generic string
> handling done in your programs...and program editors don't count, since
> they are completely structured by the grammar of the language and have
> strict definitions of the set of possible strings to be handled. That could
> be about a million miles wrong, since you obviously write a lot of code...but
> it was an impression.
It seems we aren't going to get an example from Everett, so I went looking thru
some of my own code, especially those which read and write files created by
dBase, VB, and Pascal programs. Nowhere could I find any code that
demonstrates any difficulty with strings. Conversions between VB
Doubles and Euphoria atoms, yes. Between Pascal 6-byte reals and atoms, yes.
Nothing out of the ordinary to do with strings, however.
It may be that your applications are far more sophisticated than mine, so that
you have special needs. If so, please describe in concrete terms what those
needs might be.
Regards,
Irv
33. Re: Eu vs perl
David Cuny wrote:
>Everett Williams wrote:
>
>> The problem with programmer added prefixes is that they
>> are static and do not allow for multiple occurrences. If I have
>> a structure that describes a file, I may have three files with
>> the same structure open at the same time.
>
>I've used two different ways to deal with this. I can create a 'generic'
>sequence to hold everything:
snip
>
>Not entirely elegant, but it gets the job done. That's the approach Llama
>took. The double indexing is expensive, and using Get/Set makes it more so.
>Llama was rightly criticized as having a lot of overhead in the data
>structures.
>
>In my new toolkit, I take a slightly different approach:
>
> sequence name, ssn
> name = {}
> ssn = {}
>
> function newItem()
> name = append( name, "" )
> ssn = append( ssn, "" )
> return length( name )
> end function
>
>Working with objects is now:
>
> constant Fred = newItem()
> constant Joe = newItem()
>
> name[Fred] = "Fred"
> ssn[Fred] = "000-00-0000"
>
> name[Joe] = "Joe"
> ssn[Joe] = "111-11-1111"
A beautifully elegant way to be stuck at another static level. I must declare
a constant for each occurrence of the structure. The use of one sequence
per "field" is certainly a solution to the reference problem. Now, when I
wish to assemble the structure for IO, I must do just that...assemble it
one piece at a time.
>> Constants are not necessary in a "minimalist"
>> language.
>
>I don't share this dislike of constants. Writing:
>
> the[SSN]
>
>makes a lot more sense than:
>
> the[3]
Absolutely...anything that puts a name in place of a number where the
number is not directly indicative of relative occurrence is a positive. It still
is deceptive and causes much unneeded overhead. Now, there is the
germ of an idea here. If I could declare structures and have constants
implicitly assigned to the elements, I could use the[SSN] as a
substitute for prefixing in referencing fields. I'd still have to build "the" up
manually, but that is not overly difficult. If that were joined with my
null structures with initialization, It would produce less violence to the
current syntax. I don't see how it would deal with the namespace problem
and the collision of namespaces from various includes. So far, only
prefixes seem to answer that question. If prefixes are required there, then
there seems to be little problem in using them elsewhere. I'm open to
ideas...and I hope RDS is too...if we out here can come up with a
common set of proposals.
>> And I shouldn't accuse. I share some of Jiri's irritation with
>> the "way" that the libs you have written are headed ...
>
>I assume by 'the "way"', you are referring to GUI applications, as opposed
>to DOS applications. Jiri's complaints seem to be less that I'm writing GUI
>code, and more that a "DOS" forum is constantly polluted with Windows code.
>
>
>> but I also recognize that this language would be sitting
>> virtually unused if it wasn't for that very work.
>
>Looking at the huge number of DOS contributions on the Euphoria web page,
>I'd have to disagree.
I meant at the Windows application level. DOS is a self-limiting environment.
>> I'm not quite as irritable as Jiri, but after the third demand
>> for code I got a little crotchety.
I can't speak for Jiri, but one thing that we appear to share in common is
the inability to make it clear when we are passing out a back-handed
compliment.
>But I don't think it's an unreasonable demand. If you can't show me an
>example of code that demonstrates your claim, then it's difficult for me to
>believe there's an issue.
If the lengths to which you have gone in the code samples above is not
evidence of an issue, what poor samples that I would be capable of at
this point would suffice? You appear to be in the mode that I have spoken
of before..."to the man with a hammer, everything looks like a nail". You
have chosen to view everything from the position of existing coding
capabilities. I find what you have done above to be an elegant, but
questionably useful method of trying to get around a major hole in the
language. It works for you, but is not particularly intuitive or flexible IMO.
That is not a knock on you or your coding techniques. It merely shows
that one of the best coders in Euphoria still can't get past the inherent
problems.
>> but I have not seen much generic string
>> handling done in your programs...
>
>I'm not sure what you mean by 'generic string handling'. I've posted several
>programs with fairly complex parsers. eBasic converts QBasic code into
>Euphoria using an LL(1) grammar. PP is a pre-processor for Euphoria that
>'enhances' the language with a number of interesting constructs. Eu parses
>and executes Euphoria code. On a smaller scale, Fix functions much the same
>as Euphoria's Shroud routine, but correctly handles routine_id, and Res
>creates resource files by parsing source files. I've posted a couple generic
>pattern matching routines as well.
>
>-- David Cuny
I thought that I specifically excluded source code as generic text because of
it's inherently deterministic structure and grammar. Not that any of those
are easy or unimportant. They just don't represent generic text as symbol
system for spoken or written language, a particularly non-deterministic
grammar and structure. I will, however, look at those for further instruction.
Everett L.(Rett) Williams
rett at gvtc.com
34. Re: Eu vs perl
- Posted by Ad Rienks <kwibus at ZONNET.NL>
Dec 09, 1999
-
Last edited Dec 10, 1999
Everett wrote:
> snip <
> of before..."to the man with a hammer, everything looks like a nail". You
> snip <
The man with the hammer can build quite nice things for the Euphoria
community.
The other man obviously hasn't got a hammer or doesn't know how to use it!
35. Re: Eu vs perl
This whole Eu Vs Perl debate is taking over the message board. To be
honest, if Euphoria were to include a String type it would be a step
backwards from the power of the Sequence. Euphoria is so simple and
flexible because of the Sequence... its the most powerful data type in the
language, and as far as I know, in any language. This is not a bad thing...
I repeat NOT a bad thing... Strings are rigid, force you to use them in
certain ways (i.e. you have to DIM arrays in most Basics before you can use
them) and too restrictive... too eighties (hehe).
36. Re: Eu vs perl
Everett Williams wrote:
> I can't speak for Jiri, but one thing that we appear
> to share in common is the inability to make it clear
> when we are passing out a back-handed compliment.
A 'back handed compliment' is an insult disguised as a compliment.
>> I'm not quite as irritable as Jiri, but after the third demand
>> for code I got a little crotchety.
Jiri's post deal with specific code examples: how things can be optimized,
made faster, properly benchmarked.
> If the lengths to which you have gone in
> the code samples above is not evidence of
> an issue, what poor samples that I would
> be capable of at this point would suffice?
> You appear to be in the mode that I have spoken
> of before..."to the man with a hammer, everything
> looks like a nail".
What sort of "lengths" are we talking about here - coding in Euphoria? How
foolish of me. And on a Euphoria mailing list, at that!
> The use of one sequence per "field" is certainly
> a solution to the reference problem.
> ...
> That is not a knock on you or your coding
> techniques. It merely shows that one of the
> best coders in Euphoria still can't get past
> the inherent problems.
On one hand, you admit that it's a viable solution, and then claim that it's
not. That's a neat trick.
> I thought that I specifically excluded source code
> as generic text because of it's inherently deterministic
> structure and grammar.
How you made the leap from constraining sequences to character elements to
NLP is beyond me.
As far as tokenizing and parsing in NLP, string handling turns out to be the
trivial part. The construction of the parse tree, internal data structure
and other complex structures that you allude to typically have little or
nothing to do with string handling. Not suprisingly, it's something to which
Euphoria's sequences are admirably suited.
*sigh*
I tire of this flamebait.
-- David Cuny
37. Re: Eu vs perl
Irv Mullins wrote:
> Nowhere could I find any code that
>demonstrates any difficulty with strings. Conversions between VB
>Doubles and Euphoria atoms, yes. Between Pascal 6-byte reals and atoms, yes.
>Nothing out of the ordinary to do with strings, however.
>
>It may be that your applications are far more sophisticated than mine, so that
>you have special needs. If so, please describe in concrete terms what those
>needs might be.
>
>Regards,
>Irv
Let us not be coy. I have in the past coded things as sophisticated as any
particular item that I have seen on this list or in the archives. The sheer
volume and ingenuity of that code as a body, however, overshadows any
individual. I am not sure at this point in my life that I either can or wish
to code at that level again. Most of what I did was done with tools far
blunter than those available to the most casual programmer today. What
I wish to do in my coding life today is create clear, intuitive programs that
accomplish particular goals that I have in mind. Where a tool such as
Euphoria has clear paradoxes or misunderstandings embedded in the
language, I know that those paradoxes and misunderstandings will lead to
unclear or difficult code. FOR example, read Mr. Cuny's previous post and
my reply to that post. Nothing could have made my point in a clearer
manner than that. Mr. Cuny's code took a five mile trip to accomplish what
should have been simply and straightforwardly coded with data structures
and prefixes or some similar solution. FOR example, the conceit that
strings are nothing but strings of numbers leads to the addition of
a sequence of #20's to a sequence/string to go from upper to lower case.
That only works for 8 bit ASCII text strings. EBCDIC will require different
arithmetic as will each of the many possible double-byte string
representations. Of course, it also ignores any display numbers in the string
The only consistent method of accomplishing the goal is to provide
corresponding sets of upper and lower case characters and do a
substitution. Numbers can be used as underlying logic to tie together the
sets, but are not an explicit part of the change or the meaning of the
change. A way to view a text letter on a computer is as a box with the
letter's name on it and a number inside the box that is subject to arbitrary
change depending on varying standards or the whim of the programmer.
I have pointed out a group of problems that will cause difficulties for the
present methods. I have even put out a specific code sequence, such
as the adding of large numbers to text items supposedly limited in range to
0-255. I have pointed to possible corruption in input strings coming from
called sources rather than from the curiously text string sensitive IO
routines of Euphoria. This is a large and fairly obvious set of problems
that has not been attempted to my knowledge in Euphoria...and I think for
fairly obvious reasons. If your imagination and knowledge cannot take you
from there, you will have to breathlessly await the point where I have
time and energy to create some simple and clear examples for posting.
I still owe Mr. Boehme a sample of how I think peek and poke can be
gotten rid of. I know what I want, but am straining to express it in a way
that will be clear enough to induce some other response than ... say what?
Everett L.(Rett) Williams
rett at gvtc.com
38. Re: Eu vs perl
Ad Rienks wrote:
>Everett wrote:
>
>> snip <
>> of before..."to the man with a hammer, everything looks like a nail". You
>> snip <
>
>The man with the hammer can build quite nice things for the Euphoria
>community.
>The other man obviously hasn't got a hammer or doesn't know how to use it!
The short answer is B.S. ... the slightly longer answer is that everybody has
the level of what they will put up with. Euphoria has not reached that level
for me for doing any kind of major project. Theoretical discussions are the
long term basis for practical advancement that is stable and useful. And, as
you may have noted if you get out of your foxhole every once in a while,
Einstein didn't design or build the bomb or the reactor, he just set the basis
and noted the probability that they would come to pass. Obviously, I am
not Einstein, but just as obviously, the theoretical problems that I note have
practical implications.
I have done my best on this forum to challenge technically without becoming
personal. When I have felt that direct contact would prevent flame wars, I
have stepped off line. Where I could, I have tried to defuse such flame wars
as I have seen. If you would like for me to alter that approach, you are
bordering on it. I can and will return a personal challenge if repeated too
often.
Is that sufficiently clear for you? If not, I can elucidate.
Everett L.(Rett) Williams
rett at gvtc.com
39. Re: Eu vs perl
On Thu, 9 Dec 1999 17:10:45 -0500, Pete King, Spectre Software <pete at
THEKING29.FREESERVE.CO.UK> wrote:
>This whole Eu Vs Perl debate is taking over the message board. To be
>honest, if Euphoria were to include a String type it would be a step
>backwards from the power of the Sequence. Euphoria is so simple and
>flexible because of the Sequence... its the most powerful data type in the
>language, and as far as I know, in any language. This is not a bad thing...
>I repeat NOT a bad thing... Strings are rigid, force you to use them in
>certain ways (i.e. you have to DIM arrays in most Basics before you can use
>them) and too restrictive... too eighties (hehe).
Strings are sequences as are most other possible data forms that I have
seen. What Euphoria lacks is the ability to control cleanly any particular
subset of that global entity. Strings are what they are. They have particular
properties, all of which are a subset of the available sequence properties.
Structures are another clean subset of sequences that offer a huge number
of optimizations when used. They can and do happen to represent a high
percent of the available, formatted data on this planet. With care, we can
have these subsets, select the properties they need and optimize both our
code and the interpreter(look at XML and you will see what I mean).
As for the takeover, this too shall pass. At the moment, I'm just answering the
mail as they say. If you've got something else to talk about, let's hear it.
Everett L.(Rett) Williams
rett at gvtc.com
40. Re: Eu vs perl
----- Original Message -----
From: Pete King, Spectre Software <pete at THEKING29.FREESERVE.CO.UK>
To: <EUPHORIA at LISTSERV.MUOHIO.EDU>
Sent: Thursday, December 09, 1999 4:10 PM
Subject: Re: Eu vs perl
> This whole Eu Vs Perl debate is taking over the message board. To be
> honest, if Euphoria were to include a String type it would be a step
> backwards from the power of the Sequence. Euphoria is so simple and
> flexible because of the Sequence... its the most powerful data type in the
> language, and as far as I know, in any language. This is not a bad
thing...
> I repeat NOT a bad thing... Strings are rigid, force you to use them in
> certain ways (i.e. you have to DIM arrays in most Basics before you can
use
> them) and too restrictive... too eighties (hehe).
Strings are just another way to interface to the sequences, not a
replacement for them. Calling a sequence a string, or typing it as such,
doesn't mean it can't hold certain values unless you specify that. It also
doesn't mean it needs to be dim'd first. Heck, i am putting commands in
strings in the mirc-Eu connection, and mirc then executes the string. The
recent storm of sequence handlers which occured off the listserv recently
have been exellent examples that sequences *can* be used as strings,
without breaking them, without typing them, and without building something
the native Eu code can't use.
As for Basic, or any other language, Eu needn't implement exactly what they
do. Since Eu is interpreted, what the machine code really does is hidden
anyways. Eu script might as well be passed thru a pre-processor who's output
is hidden to us. Which means to me that a goto can be added to Eu and make
no difference to the internal Eu engine. But, please, lets not discuss that
on the listserv again, i mention it only as an example.
----- Original Message -----
From: Cuny, David at DSS <David.Cuny at DSS.CA.GOV>
To: <EUPHORIA at LISTSERV.MUOHIO.EDU>
Sent: Thursday, December 09, 1999 4:32 PM
Subject: Re: Eu vs perl
> As far as tokenizing and parsing in NLP, string handling turns out to be
the
> trivial part. The construction of the parse tree, internal data structure
> and other complex structures that you allude to typically have little or
> nothing to do with string handling. Not suprisingly, it's something to
which
> Euphoria's sequences are admirably suited.
I whole-heartedly agree. But making sure you don't step in a error of some
sort with the code Eu supplies for sequence handling is difficult. It looked
to me as tho i was trading time in memory management of Turbo Pascal or C
with time in sequence code "features" of Eu. However, there are 4 people
here who have each coded versions of a string *interface* to sequences, as
include files, so the same object can be played with as a sequence or as a
string. In my opinion, any one of these include files make Eu the best
language for NLP/bots/AI work. You can pick at will how the string/sequence
looks to you. That's freedom. Now can we could get native multithreading
with an api too?
> *sigh*
>
> I tire of this flamebait.
Some of the language is getting out of hand. I thank those who sat down and
fixed (imho) the string handling deficits (imho) in native Eu code. Maybe
they will all post what they did to the archives when it's throughly tested.
Kat,
happily testing.
41. Re: Eu vs perl
- Posted by Everett Williams <rett at GVTC.COM>
Dec 09, 1999
-
Last edited Dec 10, 1999
Kat wrote:
>Strings are just another way to interface to the sequences, not a
>replacement for them. Calling a sequence a string, or typing it as such,
>doesn't mean it can't hold certain values unless you specify that. It also
>doesn't mean it needs to be dim'd first. Heck, i am putting commands in
>strings in the mirc-Eu connection, and mirc then executes the string. The
>recent storm of sequence handlers which occured off the listserv recently
>have been exellent examples that sequences *can* be used as strings,
>without breaking them, without typing them, and without building something
>the native Eu code can't use.
>
>As for Basic, or any other language, Eu needn't implement exactly what they
>do. Since Eu is interpreted, what the machine code really does is hidden
>anyways. Eu script might as well be passed thru a pre-processor who's output
>is hidden to us.
A sensible response without the challenges and territory protection.
Thankyou, Kat.
>> As far as tokenizing and parsing in NLP, string handling turns out to be
>the
>> trivial part. The construction of the parse tree, internal data structure
>> and other complex structures that you allude to typically have little or
>> nothing to do with string handling. Not suprisingly, it's something to
>which
>> Euphoria's sequences are admirably suited.
>
>I whole-heartedly agree. But making sure you don't step in a error of some
>sort with the code Eu supplies for sequence handling is difficult. It looked
>to me as tho i was trading time in memory management of Turbo Pascal or C
>with time in sequence code "features" of Eu. However, there are 4 people
>here who have each coded versions of a string *interface* to sequences, as
>include files, so the same object can be played with as a sequence or as a
>string. In my opinion, any one of these include files make Eu the best
>language for NLP/bots/AI work. You can pick at will how the string/sequence
>looks to you. That's freedom. Now can we could get native multithreading
>with an api too?
>
Any ideas for constructs that would easily allow communication between
threads or thread synchronization. Seems this leads back to some of the
earlier modularity discussions in the process.
>
>Some of the language is getting out of hand. I thank those who sat down and
>fixed (imho) the string handling deficits (imho) in native Eu code. Maybe
>they will all post what they did to the archives when it's throughly tested.
>
>Kat,
>happily testing.
I would hope for the same. Something like that with several of the type check
routines that were proposed in previous posts used VERY judiciously would
answer most of the sequence issues that I have. I will be watching for the
post of the code.
Everett L.(Rett) Williams
rett at gvtc.com
42. Re: Eu vs perl
> From: Everett Williams
> What Euphoria lacks is the ability to control cleanly
> any particular
> subset of that global entity. Strings are what they are. They
> have particular
> properties, all of which are a subset of the available
> sequence properties.
OK, I've been following this whole thread, and trying to understand what
you've been saying here, Everett, but unfortunately (for your argument, at
least), I find myself agreeing with Irv or Dave. Maybe I just missed it or
didn't understand, but I'd like to know what types of tools you'd like to
see. If you could describe the way it's done somewhere else that solves the
'problems' you're talking about, that might make it easier to understand.
> Structures are another clean subset of sequences that offer a
> huge number
> of optimizations when used. They can and do happen to represent a high
> percent of the available, formatted data on this planet. With
> care, we can
> have these subsets, select the properties they need and
> optimize both our
> code and the interpreter(look at XML and you will see what I mean).
I can definitely see advantages in terms of optimization to knowing what
sort of data you're getting, but now you seem to be wanting to introduce
more 'contradictions' into Euphoria (vs keeping data types few and simple).
Another issue....I think you referenced the possibility of not getting clean
data (ASCII, NL, etc.). I guess I really didn't follow you here. Wouldn't
Euphoria be BETTER able to handle these sorts of things (especially if
you're not sure what you're getting yet) than a rigidly defined data
structure?
[From another post] You also talked about the advantages of theorectical
discussions. I completely agree about that. However, no one seems to be
able to grasp what's bothering you (at least well enough to understand why
there might be a problem). So I have to conclude one of four things:
1. It's at a theoretical level above my head.
2. We have totally different perspectives about the 'problems/shortcomings'
of strings in Euphoria.
3. I'm wrong.
4. You're wrong.
I can't come anywhere near 3 or 4 yet, but I think a little more concrete
example would help determine 1 and/or two, and might resolve the whole thing
(to some degree, of course). Look, I understand you don't want to invest
too much into Euphoria right now, but I don't think this is too much to ask
for, and IMHO you're really only hurting your case by staying 'too
theoretical.'
--
Matt Lewis
"It's so simple a four year old could understand it....go get me a four year
old."
--Grouco Marx
43. Re: Eu vs perl
Matthew Lewis wrote:
>> From: Everett Williams
>
>> What Euphoria lacks is the ability to control cleanly
>> any particular
>> subset of that global entity. Strings are what they are. They
>> have particular
>> properties, all of which are a subset of the available
>> sequence properties.
>
>OK, I've been following this whole thread, and trying to understand what
>you've been saying here, Everett, but unfortunately (for your argument, at
>least), I find myself agreeing with Irv or Dave. Maybe I just missed it or
>didn't understand, but I'd like to know what types of tools you'd like to
>see. If you could describe the way it's done somewhere else that solves the
>'problems' you're talking about, that might make it easier to understand.
I am in full retreat on this one in favor of Gabriel's and Kat's posts. I
believe
that they have answered my objections quite adequately. Minor grumblings
remain, but I will live.
>> Structures are another clean subset of sequences that offer a
>> huge number
>> of optimizations when used. They can and do happen to represent a high
>> percent of the available, formatted data on this planet. With
>> care, we can
>> have these subsets, select the properties they need and
>> optimize both our
>> code and the interpreter(look at XML and you will see what I mean).
>
>I can definitely see advantages in terms of optimization to knowing what
>sort of data you're getting, but now you seem to be wanting to introduce
>more 'contradictions' into Euphoria (vs keeping data types few and simple).
Guess what, a structure is not a data type any more than a sequence is,
it is a syntactical construct that allows us easy use of whatever data types
that we finally decide that we have. I would like to see more specific data
types in Eu if only in isolated IO routines with scope local to the procedure
in which they are used. Lacking that, a templated call procedure that allows
specified access to that world of external data structures would suffice.
Despite calumnies to the contrary, I really am an admirer of the Eu data
types.
snip
>[From another post] You also talked about the advantages of theorectical
>discussions. I completely agree about that. However, no one seems to be
>able to grasp what's bothering you (at least well enough to understand why
>there might be a problem). So I have to conclude one of four things:
>
>1. It's at a theoretical level above my head.
>2. We have totally different perspectives about the 'problems/shortcomings'
>of strings in Euphoria.
>3. I'm wrong.
>4. You're wrong.
>
>I can't come anywhere near 3 or 4 yet, but I think a little more concrete
>example would help determine 1 and/or two, and might resolve the whole thing
>(to some degree, of course). Look, I understand you don't want to invest
>too much into Euphoria right now, but I don't think this is too much to ask
>for, and IMHO you're really only hurting your case by staying 'too
>theoretical.'
>
>--
>Matt Lewis
>
>"It's so simple a four year old could understand it....go get me a four year
>old."
> --Grouco Marx
I'll go for Groucho here. I hope this selection wasn't entirely random as it is
so apropos. Where I can, I will. Simple, understandable examples that
clearly demonstrate non-trivial points are not necessarily easy to come by.
At least, not for me. Let me quote a thing that I said to Mr. Cuny in a private
post.
"One of the reasons that I do not bandy code samples on the list is that
the first reaction is a small code storm with fascinating, useful, but
increasingly unintuitive code samples. With careful examination and some
reference internally to my experience, I can usually recognize what
is attempted and why. Many years ago I learned to avoid such constructs
without piles of documentation. I do my best to code straightforwardly
except where absolutely required by circumstances to use "tricks" or
"bypasses" or whatever you would like to call such techniques."
I prefer to leave optimization to the compiler/interpreter where humanly
possible.
As for your list.
>1. It's at a theoretical level above my head.
I don't think so. Background differences and 2 below account for most.
>2. We have totally different perspectives about the 'problems/shortcomings'
>of strings in Euphoria.
Probably, but I will try to make mine clear if you will do the same.
>3. I'm wrong.
Well, it is easier than thinking that I screwed up.
>4. You're wrong
I was wrong once, about twenty years ago, but I got over it
Seriously, your points are well taken and I do occasionally give ground, if
grudgingly. Note the current "progress" in the sequence discussion.
Everett L.(Rett) Williams
rett at gvtc.com
