OpenEuphoria

2. Re: Changes in the ESL papers

• Posted by Jason Gade <jaygade at gmail.com> Jul 22, 2005
• 564 views

Juergen Luethje wrote:
> 
> 
> Hi all,
> 
> I have recently "tweaked" the existing HTML files, and added several new
> ones. The new files mainly contain suggestions from Derek (Newhall), and
> a few from me. The name of the "discussion paper" has changed, it is now
> 'road_map.htm'. However the main page still is -- and will always be
> (as long as the papers are on my website):
>    http://home.arcor.de/luethje/esl/index.htm
> 
> I made some cosmetic changes, and tried to write some things clearer. I
> also introduced several notes that will always show the status of the
> regarding topic. In the 'General Guidelines' section, I added a
> sentence that says:
> "The style of code and documentation shall in general be close to the
> style of the material contained in the official Euphoria release."
>    I think we agree on that, but it was not contained in the paper
> before in this form.
> 
> In the file 'index.htm' there is a new section "Modules proposed for
> later releases". This allows us to note modules (so that we won't forget
> them) that we consider important, but not urgent.
> 
> In the file 'road_map.htm' there is a new section "Specific guidelines
> for documentation". I moved some points from other sections there, and
> added the following:
> - Something like "... works like function x in language y" as the only
>   description is not considered a valid documentation, because it should
>   not be required to know /other/ languages in order to understand
>   /Euphoria/ related docs.
> 
> In the section "Specific coding guidelines" I added:
> - Do not use neither lowercase nor uppercase character O as variable
>   name, because both are easily confused with zero. Also don't use
>   lowercase letter l, because it will often be confused with the number
>   one.

Wow, Juergen.  You're moving along quite well with this. Thanks!

> I still have (at least) the following questions:
> - With what Eu versions should the library be compatible?
I want to say 2.4 and up, but with a simple tool to remove [$] we might 
be able to have a 2.4 and a 2.5 library.

> - Should the library have a global error handling function?
>   If so, it would probably be the best to implement it for the
>   first version.
Yes, if possible.

> - What shall functions return in case of an error?
It would be nice to have an exception mechanism as said above. Otherwise 
maybe the largest positive or negative atom (not INF) used by Euphoria? 
I remember another library uses that as a flag value but I don't 
remember which one.

> - Should we have one file that contains (almost) all global types
>   (I vote for this), or should the global types be included in the
>   respective modules?
Both.

> - Is it sufficient that 1 person checks whether the code meets the
>   specification, or should that be double-checked by an additional
>   person?
I think the code review should be done by all participants. I think most 
discussion should be done on the main EUforum so that other opinions can 
be heard but perhaps we can have an area on 
http://uboard.proboards32.com for code review and internal discussions.

Suggestions:
in math.e I think that add_all() should be called sum().  I don't know 
if multiply_all() should be called product(). It should be consistent 
either way though.


> 
> 
> Regards,
>    Juergen
> 


-- 
==============================
Too many freaks, not enough circuses.
j.

4. Re: Changes in the ESL papers

• Posted by D. Newhall <derek_newhall at yahoo.com> Jul 22, 2005
• 570 views

Jason Gade wrote:
> 
big snip

> > - Should we have one file that contains (almost) all global types
> >   (I vote for this), or should the global types be included in the
> >   respective modules?
> Both.
But if we have the same global types in two files and you use both in a file
you'd have namespace problems.

'nother snip

> Suggestions:
> in math.e I think that add_all() should be called sum().  I don't know 
> if multiply_all() should be called product(). It should be consistent 
> either way though.
It should definitely be consistent. With sum() and product() I was worried that
the names weren't descriptive enough (the sum and product of what?). I'm fine
with either name though or even something like sum_elements()?

6. Re: Changes in the ESL papers

• Posted by Jason Gade <jaygade at yahoo.com> Jul 22, 2005
• 556 views

D. Newhall wrote:
> 
> Juergen Luethje wrote:
> > - Should the library have a global error handling function?
> >   If so, it would probably be the best to implement it for the
> >   first version.
> I was thinking about this too and I'd say that it's not necessary.
> Theoretically, the
> library shouldn't have to call any error routines since each function would
> return
> an error value instead. Error handling routines would probably be nice but
> different
> platforms, libraries, and applications would each handle them differently.
> 
> > - What shall functions return in case of an error?
> Depends, but usually 0 or -1. If you look at match() and find() they return 0
> on failure
> because those aren't valid return values but open() returns -1 for failure
> (since 0
> means standard input I'm guessing). Also, stuff like get() and value() can
> return 0
> as a valid result so they return a sequence starting with an error code
> declared as
> a constant. I think this is a case-by-case issue for the most part.

As long as routines don't return a sequence or an atom based on *whether* there
is an error.  This is a behavior of Euphoria standard routines that I hate --
users shouldn't have to declare variables as object in order to differentiate
between a valid return and an error.

=====================================
Too many freaks, not enough circuses.

j.

8. Re: Changes in the ESL papers

• Posted by Jason Gade <jaygade at yahoo.com> Jul 22, 2005
• 549 views

D. Newhall wrote:
> 
> Jason Gade wrote:
> > 
> big snip
> 
> > > - Should we have one file that contains (almost) all global types
> > >   (I vote for this), or should the global types be included in the
> > >   respective modules?
> > Both.
> But if we have the same global types in two files and you use both in a file
> you'd
> have namespace problems.

With Euphoria's behavior of including a file by name only once, this shouldn't
be a problem.  Separate the types by function into their own files and have
types.e include all of those files.  Respective modules can include the type
file(s) they need. This is what I meant.

> 
> 'nother snip
> 
> > Suggestions:
> > in math.e I think that add_all() should be called sum().  I don't know 
> > if multiply_all() should be called product(). It should be consistent 
> > either way though.
> It should definitely be consistent. With sum() and product() I was worried
> that the
> names weren't descriptive enough (the sum and product of what?). I'm fine with
> either
> name though or even something like sum_elements()?
> 


=====================================
Too many freaks, not enough circuses.

j.

10. Re: Changes in the ESL papers

• Posted by Derek Parnell <ddparnell at bigpond.com> Jul 22, 2005
• 570 views

Jason Gade wrote:
> 
> D. Newhall wrote:
> > 
> > Juergen Luethje wrote:
> > > - Should the library have a global error handling function?
> > >   If so, it would probably be the best to implement it for the
> > >   first version.
> > I was thinking about this too and I'd say that it's not necessary.
> > Theoretically, the
> > library shouldn't have to call any error routines since each function would
> > return
> > an error value instead. Error handling routines would probably be nice but
> > different
> > platforms, libraries, and applications would each handle them differently.
> > 
> > > - What shall functions return in case of an error?
> > Depends, but usually 0 or -1. If you look at match() and find() they return
> > 0 on failure
> > because those aren't valid return values but open() returns -1 for failure
> > (since 0
> > means standard input I'm guessing). Also, stuff like get() and value() can
> > return 0
> > as a valid result so they return a sequence starting with an error code
> > declared as
> > a constant. I think this is a case-by-case issue for the most part.
> 
> As long as routines don't return a sequence or an atom based on *whether*
> there is
> an error.  This is a behavior of Euphoria standard routines that I hate --
> users shouldn't
> have to declare variables as object in order to differentiate between a valid
> return
> and an error.

For what it's worth, I've tended to adopt the convention of *always* returning a
sequence. The first element is either 0 (an error) or 1 (a success), and the
second is the ancillary data. In the case of an error, it is something that helps
users know what sort of error occurred, and in the case of success, it is the
returned data from the function.

This keeps code consistant and extensible. It also encourages (forces?) coders
to take notice of error codes because it is no longer possible to do ...

   if func() = 0 then ...

Instead you must do ...

   rc = func()
   if rc[1] = 0 then ...

However, I guess most coders won't bother to adopt this discipline. It is
similar to the RDS value() function's return.

-- 
Derek Parnell
Melbourne, Australia
Skype name: derek.j.parnell

12. Re: Changes in the ESL papers

• Posted by Gordon Webster <gwalias-bb at yahoo.com> Jul 22, 2005
• 594 views

Way to go Juergen!

For math.e, I would suggest that the rounding down function (i.e. the
rounding down equivalent of 'ceil') be called 'floor'.

How about 'sum_sequence' and 'product_sequence' for the 2 math sequence
functions?

Are we going to make each module/function self-documenting - maybe I
missed it but I never saw an answer to this question (with the caveat
that we work with the official RDS Eu syntax, since it would be (IMHO)
a mistake to support other syntax-variant Eu flavors)

Consistent error handling is tricky, since 0 or -1 might be valid
return values for some functions. Rather than standardizing error handling
pe se (since different error contexts may call for different handling),
we could define a standard library error type as a sequence with an
distinctive flag as its first element. The subsequent elements of the
sequence could then be anything the coder required for the particular
error handling they had in mind - error messages, routine ids where the
crash occurred, routine ids to go to after a crash, diagnostics etc. etc.

The advantage of this would be to provide both a standardized way of
telling an error had occurred by testing the returned object (is it a 
sequence and is its first element the error flag?) and providing a 
flexible storage element for the coder to use for whatever eror handling 
he/she has in mind. It could work like this ...

constant STANDARD_LIBRARY_ERROR = ".standard.library.error." -- or whatever

global function is_error(object s)
-- start-eudocs
-- function to test returned values for error status
-- end-eudocs
    if not sequence(s) then
        return false
    else
        if not length(s) > 0 then
            return false
        end if
    end if
    if equal(s[1],STANDARD_LIBRARY_ERROR) then
        return true
    else
        return false
    end if
end function

Now my functions can return something like this in the case of an error...

function demo_function(integer num)
  ...
  <some code here>
  ...
  if not integer(result) then
    return {STANDARD_LIBRARY_ERROR,"Result not an integer","demo_function"}
  end if
  ...
end function

So the way of flagging errors and storing the error handling parameters is
standardized, but the error handling is still flexible enough for any
occasion and doesn't impose an error handling ideology on all users under
all circumstances.

Comments?

Best

Gordon

14. Re: Changes in the ESL papers

• Posted by "Juergen Luethje" <j.lue at gmx.de> Jul 22, 2005
• 572 views

Pete Lomax wrote:

> On Fri, 22 Jul 2005 00:05:39 +0200, Juergen Luethje wrote:
>
>> I have recently "tweaked" the existing HTML files, and added several new
> Looking good.

Thanks. 

> <snip>
>>  lowercase letter l,
> At first I misread that.

I deliberately had written so in order to demonstrate the ambiguity (for
human eyes) of the character 'l' ... 

> It should be "uppercase letter i or lowercase letter L which can both
> be confused with 1."

Oooops.. I completely forgot the uppercase letter i. I'll use your
sentence above in the paper now, thanks!

>> I still have (at least) the following questions:

<snip>

>> - Should the library have a global error handling function?
>>   If so, it would probably be the best to implement it for the
>>  first version.
> A standard library should never offer user dialog (and as you said,
> the standard library should not have any GUI components).

In the MSDN library, we often can read a sentence like this:
"If the function fails, the return value is zero. To get extended error
information, call GetLastError."
I was thinking of something along these lines.

>> - What shall functions return in case of an error?
> I think that has to be a guideline at most. Failing to open (or copy)
> a file might be an error in some applications, or just an indication
> that it is time to create it in others. Where possible, I prefer to
> use boolean values of 0 and 1 to indicate success or failure, but
> there are many cases where that is not appropriate.

I also think that it's not easy to give a general rule here.
For instance, I like the way gets() works, i.e. returning -1 rather than
a sequence to indicate EOF. But if very many functions that normally
return a sequence will return an atom in case of an error (or vice versa),
that would mean that we would have to declare very many variables as
objects, which is not desirable IMHO ...

>> - Should we have one file that contains (almost) all global types
>>   (I vote for this), or should the global types be included in the
>>  respective modules?
> Decentralize where you can.
> The complex type, for example, is probably only needed in/if you use
> maths.e. If you can write maths.e such that it does not need to
> include types.e, without duplicating anything, then you should.
> Otoh, a boolean, is probably needed most places, so you need types.e

Sounds very reasonable.

> I don't think this is a particularly critical point, though.

OK.

>> - Is it sufficient that 1 person checks whether the code meets the
>>   specification, or should that be double-checked by an additional
>>  person?
> I think it is sufficient; one person writes the docs, code, and tests
> suggested while writing the code (which should be kept!). A second
> person reviews the docs and writes some more tests from that, then
> reviews the code and where appropriate writes a few more tests.
>
> I assume each routine will have a list, by date, of who has approved
> it and any mods made, so it is clear if any mods have been made after
> approval, plus where the test script can be found?

I'll add this to the discussion paper.
Thanks for all the good suggestions!

Regards,
   Juergen

16. Re: Changes in the ESL papers

• Posted by "Christian Cuvier" <christian.cuvier at agriculture.gouv.fr> Jul 22, 2005
• 564 views

> Date: Fri, 22 Jul 2005 00:05:39 +0200
> From: "Juergen Luethje" <j.lue at gmx.de>
> Subject: Changes in the ESL papers
> 
> 
> Hi all,
> 
> I have recently "tweaked" the existing HTML files, and added several new
> ones. The new files mainly contain suggestions from Derek (Newhall), and
> a few from me. The name of the "discussion paper" has changed, it is now
> 'road_map.htm'. However the main page still is -- and will always be
> (as long as the papers are on my website):
>    http://home.arcor.de/luethje/esl/index.htm
> 
> I made some cosmetic changes, and tried to write some things clearer. I
> also introduced several notes that will always show the status of the
> regarding topic. In the 'General Guidelines' section, I added a
> sentence that says:
> "The style of code and documentation shall in general be close to the
> style of the material contained in the official Euphoria release."
>    I think we agree on that, but it was not contained in the paper
> before in this form.
> 
> In the file 'index.htm' there is a new section "Modules proposed for
> later releases". This allows us to note modules (so that we won't forget
> them) that we consider important, but not urgent.
> 
> In the file 'road_map.htm' there is a new section "Specific guidelines
> for documentation". I moved some points from other sections there, and
> added the following:
> - Something like "... works like function x in language y" as the only
>   description is not considered a valid documentation, because it should
>   not be required to know /other/ languages in order to understand
>   /Euphoria/ related docs.
> 

Good move. Adding the reference may help people migrating from other 
languages (so that the remark may deserve to be there), but indeed there 
must be a self-contained description.

> In the section "Specific coding guidelines" I added:
> - Do not use neither lowercase nor uppercase character O as variable
>   name, because both are easily confused with zero. Also don't use
>   lowercase letter l, because it will often be confused with the number
>   one.
> 
> 
> I still have (at least) the following questions:
> - With what Eu versions should the library be compatible?

2.4 minimum. Versions optimized for later releases of Eu would be good too.

> - Should the library have a global error handling function?

Handling? Not sure. Display and report? Definitely. Consider the non 
public lib Chris Bensler wrote as a good sttarting point.

>   If so, it would probably be the best to implement it for the
>   first version.
> - What shall functions return in case of an error?

Nothing, because illegal values vastly vary. I'd suggest using a 
separate structure to hold completion status.

> - Should we have one file that contains (almost) all global types
>   (I vote for this), or should the global types be included in the
>   respective modules?
> - Is it sufficient that 1 person checks whether the code meets the
>   specification, or should that be double-checked by an additional
>   person?

Double checking is always better, but how many people will be available?
CChris
> 
> 
> Regards,
>    Juergen
> 
> -- Have you read a good program lately?

18. Re: Changes in the ESL papers

• Posted by "Christian Cuvier" <christian.cuvier at agriculture.gouv.fr> Jul 22, 2005
• 549 views

> Date: Fri, 22 Jul 2005 10:52:22 +0200
> From: "Juergen Luethje" <j.lue at gmx.de>
> Subject: Re: Changes in the ESL papers
> 
> 
> Pete Lomax wrote:
> 
> 
>>> On Fri, 22 Jul 2005 01:58:15 +0100, Pete Lomax wrote:
>>>
>>
>>>>> If timing tests indicate no difference, make it compatible with 2.4.
>>>>> I personally still use 2.4 more than 2.5, so if necessary/possible I
>>>>> would like a seqops24.e as well as the main seqops.e (assuming there
>>>>> is some code difference), but I don't think backward compatibility is
>>>>> a good reason to slow anyone down, nor do I think the library authors
>>>>> should start worrying about a[i]+= etc which have since been fixed.
>>>>>
>>>>> Maybe if there is a seqops24.e it would be "not officially supported".
>>
>>> I retract that. Code it for 2.5 and have a utility to convert to 2.4.
> 
> 
> OK.
> 
> Regards,
>    Juergen
>

Please don't.
s[legth(s)] and s[$] evaluate in different times. Converting 2.5 
optimized code to 2.4 will work, but will lower efficiency. 2.4 
optimized code will track the length of an ever expanding sequence to 
scrape a few microseconds here and there. 2.5 optimized code won't. And 
I don't know a converter smart enough to perform this change of 
implementation.

CChris

> 
> 
> -------------------

20. Re: Changes in the ESL papers

• Posted by Pete Lomax <petelomax at blueyonder.co.uk> Jul 22, 2005
• 555 views

I think the best way to handle errors consistently is:

result=f(x,y,z)
	if error then
		...

	p(x,y,z)
	if error then
		...

Where result should be the correct type rather than an object, 
and error is a global boolean (just the one for the whole of the 
standard library), reset at the start of every [global] routine.
If error is set the value of result is meaningless. You can equally
have a separate global object errorDetails if need be, the contents of
which are routine-specific. 

Regards,
Pete
PS Another thought: All dates used in comments in the standard library
should be unambiguous, eg 6 JUL 2005, since 6/7/05 may be read as
June 7th 2005 by some. Not sure if that was mentioned.

22. Re: Changes in the ESL papers

• Posted by "Juergen Luethje" <j.lue at gmx.de> Jul 22, 2005
• 578 views

Jason Gade wrote:

> Juergen Luethje wrote:

<snip>

>>    http://home.arcor.de/luethje/esl/index.htm

<snip>

> Wow, Juergen.  You're moving along quite well with this. Thanks!

Thanks. 
Well, I'm trying to summarize the regarding discussions here on EUforum
as good as I can. This is not always easy, especially when there are
many posts, and I don't have much time.
So please forgive me ( in advance  ) if there is something missing in
the "papers". Just tell me again please (maybe by private e-mail) that
you want me to include this or that.
Of course I have personal opinions of several topics, but I'm actually
trying not to mix them up with my "job" to maintain the papers. So if
there is something missing in the papers, this is *not* because I
personally don't like it. I'll include it in the papers first, and then
argue about it here. 

>> I still have (at least) the following questions:
>> - With what Eu versions should the library be compatible?
> I want to say 2.4 and up, but with a simple tool to remove [$] we might
> be able to have a 2.4 and a 2.5 library.
>
>> - Should the library have a global error handling function?
>>   If so, it would probably be the best to implement it for the
>>   first version.
> Yes, if possible.
>
>> - What shall functions return in case of an error?
> It would be nice to have an exception mechanism as said above. Otherwise
> maybe the largest positive or negative atom (not INF) used by Euphoria?
> I remember another library uses that as a flag value but I don't
> remember which one.
>
>> - Should we have one file that contains (almost) all global types
>>   (I vote for this), or should the global types be included in the
>>   respective modules?
> Both.
>
>> - Is it sufficient that 1 person checks whether the code meets the
>>   specification, or should that be double-checked by an additional
>>   person?
> I think the code review should be done by all participants. I think most
> discussion should be done on the main EUforum so that other opinions can
> be heard but perhaps we can have an area on
> http://uboard.proboards32.com for code review and internal discussions.

I added this suggestion to
    http://home.arcor.de/luethje/esl/index.htm

and also added my personal suggestion, that we can use e-mail for
internal discussions, too. 

( Using any web forum -- this is not limited  to a specific forum -- is
for me personally about 5 to 10 times more complicated than using
e-mail. And so it takes much longer for me, and I really don't like web
forums. )

> Suggestions:
> in math.e I think that add_all() should be called sum().  I don't know
> if multiply_all() should be called product(). It should be consistent
> either way though.

I added all your suggestions to the papers.
There are now "stamps" in the papers such as [new] and [changed].

Regards,
   Juergen

24. Re: Changes in the ESL papers

• Posted by "Juergen Luethje" <j.lue at gmx.de> Jul 22, 2005
• 557 views

Gordon Webster wrote:

> Way to go Juergen!

Thanks. 

> For math.e, I would suggest that the rounding down function (i.e. the
> rounding down equivalent of 'ceil') be called 'floor'.

Euphoria has a built-in floor() function. 

> How about 'sum_sequence' and 'product_sequence' for the 2 math sequence
> functions?

Added to the paper ('math.htm').

> Are we going to make each module/function self-documenting - maybe I
> missed it but I never saw an answer to this question (with the caveat
> that we work with the official RDS Eu syntax, since it would be (IMHO)
> a mistake to support other syntax-variant Eu flavors)

I'm not sure what you exactly mean.
However, at the day Topica started working again, I got IIRC 90+ mails,
and I didn't have much time this week. I know there was some discussion
about documentation, of course I still have the mails, but I hadn't read
then thoroughly so far. I'm currently working and replying by using the
LIFO principle ( which might not be a good idea  ).

> Consistent error handling is tricky, since 0 or -1 might be valid
> return values for some functions. Rather than standardizing error handling
> pe se (since different error contexts may call for different handling),
> we could define a standard library error type as a sequence with an
> distinctive flag as its first element. The subsequent elements of the
> sequence could then be anything the coder required for the particular
> error handling they had in mind - error messages, routine ids where the
> crash occurred, routine ids to go to after a crash, diagnostics etc. etc.
>
> The advantage of this would be to provide both a standardized way of
> telling an error had occurred by testing the returned object (is it a
> sequence and is its first element the error flag?) and providing a
> flexible storage element for the coder to use for whatever eror handling
> he/she has in mind. It could work like this ...
>
> }}}
<eucode>
> constant STANDARD_LIBRARY_ERROR = ".standard.library.error." -- or whatever
>
> global function is_error(object s)
> -- start-eudocs
> -- function to test returned values for error status
> -- end-eudocs
>     if not sequence(s) then
>         return false
>     else
>         if not length(s) > 0 then
>             return false
>         end if
>     end if
>     if equal(s[1],STANDARD_LIBRARY_ERROR) then
>         return true
>     else
>         return false
>     end if
> end function
> </eucode>
{{{

>
> Now my functions can return something like this in the case of an error...
>
> function demo_function(integer num)
>   ...
>   <some code here>
>   ...
>   if not integer(result) then
>     return {STANDARD_LIBRARY_ERROR,"Result not an integer","demo_function"}
>   end if
>   ...
> end function
>
> So the way of flagging errors and storing the error handling parameters is
> standardized, but the error handling is still flexible enough for any
> occasion and doesn't impose an error handling ideology on all users under
> all circumstances.
>
> Comments?

This looks very well designed to me. But if I understood it correctly,
then there probably will be one problem: A variable that holds a return
value of demo_function() -- or any other function that is written that
way -- cannot be declared as atom. No problem if the legal return values
of the function are sequences anyway. But if the legal return values are
atoms, we must then declare all those variables as objects ...

Regards,
   Juergen

26. Re: Changes in the ESL papers

• Posted by Pete Lomax <petelomax at blueyonder.co.uk> Jul 22, 2005
• 545 views

On 22 Jul 2005 13:26:45 +0200, Christian Cuvier
<Christian.CUVIER at agriculture.gouv.fr> wrote:

>> Pete Lomax wrote:
>>>> I retract that. Code it for 2.5 and have a utility to convert to 2.4.

>Please don't.
>s[legth(s)] and s[$] evaluate in different times. Converting 2.5 
>optimized code to 2.4 will work, but will lower efficiency. 2.4 
>optimized code will track the length of an ever expanding sequence to 
>scrape a few microseconds here and there. 2.5 optimized code won't.
This sounds like trading performance on 2.5 for performance on 2.4.
Matt's post shows that $ offers a real gain on 2.5, and there is no
excuse for those of us who still prefer 2.4 to penalise 2.5 users.

I ran some tests, and using $ can gain 26.4% over optimised 2.4. One
case actually showed the full 40% hit mentioned by Matt, when running
naive substitution of $ with length. My test results are based on the
extreme $-abuse nonsense code which is:

sequence a
		 a={{0,{9,{8,7}}},{6,{5,4}},{3,2},1}

function f14()
	return a[$]+a[$-1][$]+a[$-2][$][$]+a[$-3][$][$][$]
end function

sequence b
		 b={{{{5,4},3},2},1}

function f6()
	return b[$]+b[$-1][$]+b[$-1][$-1][$]
end function

You might have more luck than me hand optimising that in 2.4, and you
might have a better real-world example.

Conversely, the best optimised 2.4 code I could come up showed a 26.1%
gain over naive substitution of the above. The smallest performance
hit recorded (20%) was between 2.4 optimised and naive substitution.

Hence I conclude two things:
 1) that no one code style is good for both 2.4 and 2.5, any code you 
      can write (that makes extensive use of subscripting based on
      the sequence length) will be at least 20% slower than it needs
      to be on at least one of them.
 2) the rule "don't use $" leads to the biggest hit, not only in the 
      naive case but also the most carefully hand-optimised code.

However, I offer the suggestion below.

>I don't know a converter smart enough to perform this change of 
>implementation.

You could place conversion markers in the source. Hopefully, this will
not be required all that often, so the sources will not get too messy.

--2.4:
--integer lt
--0.0:

	--2.5:
	while t[$] do
	--2.4:
	--lt=length(t)
	--while t[lt] do
	--0.0:

Where 0.0 indicates to the converter that following lines are valid on
all versions, 2.5 instructs the converter to start commenting out
lines, and 2.4 instructs the converter to start uncommenting lines.
The lack of a space after the "--" indicates it is code, not comments.

If it starts to get fiddly, and readability is compromised, wrap
entire routines:

--2.5:
function replace_all(..)
end function
--2.4:
--function replace_all(..)
--end function
--0.0:

Regards,
Pete

28. Re: Changes in the ESL papers

• Posted by Vincent <darkvincentdude at yahoo.com> Jul 22, 2005
• 563 views

Matt Lewis wrote:
> 
> Christian Cuvier wrote:
> > 
> > > Pete Lomax wrote:
> > > 
> > >>> I retract that. Code it for 2.5 and have a utility to convert to 2.4.
> > > 
> > 
> > Please don't.
> > s[legth(s)] and s[$] evaluate in different times. Converting 2.5 
> > optimized code to 2.4 will work, but will lower efficiency. 2.4 
> > optimized code will track the length of an ever expanding sequence to 
> > scrape a few microseconds here and there. 2.5 optimized code won't. And 
> > I don't know a converter smart enough to perform this change of 
> > implementation.
> > 
> 
> For the trivial case, the code is identical.  I used the disassembler that
> is part of ooeu to generate the following.  I created a sequence:
> }}}
<eucode>
> sequence s
> s = repeat( repeat( 0, 10 ), 10 )
> 
> ? s[$]
> <font color="#330033"></eucode>
{{{
...produces this </font><font
> color="#0000FF">for </font><font color="#330033">il code:</font>
>     15: 042 107 110        # LENGTH: [s:107] => [_temp_:110]
>     18: 025 107 110 110    # RHS_SUBS: [s:107] sub [_temp_:110] =>
>     [_temp_:110]
>     22: 036 111 110        # QPRINT: [_temp_:110]
> }}}
<eucode>
> ? s[length(s)]
> <font color="#330033"></eucode>
{{{
...produces identical code:</font>
>     65: 042 107 113        # LENGTH: [s:107] => [_temp_:113]
>     68: 025 107 113 113    # RHS_SUBS: [s:107] sub [_temp_:113] =>
>     [_temp_:113]
>     72: 036 111 113        # QPRINT: [_temp_:113]
> 
> Now consider a more interesting, but still simple case:
> }}}
<eucode>
> ? s[$][$]
> <font color="#330033"></eucode>
{{{
...</font><font color="#0000FF">and
> </font><font color="#330033">we get:</font>
>     27: 042 107 110        # LENGTH: [s:107] => [_temp_:110]
>     30: 025 107 110 110    # RHS_SUBS: [s:107] sub [_temp_:110] =>
>     [_temp_:110]
>     34: 042 110 112        # LENGTH: [_temp_:110] => [_temp_:112]
>     37: 092 110 112 112    # RHS_SUBS_CHECK: [_temp_:110] sub [_temp_:112] 
>                            #     => [_temp_:112]
>     41: 036 111 112        # QPRINT: [_temp_:112]
> 
> Two calls to length, plus two RHS Subscripts.  A simple, straightforward
> converter might change that to:
> }}}
<eucode>
> ? s[length(s)][length(s[length(s)])]
> <font color="#330033"></eucode>
{{{
...which would look like:</font>
>     77: 042 107 113        # LENGTH: [s:107] => [_temp_:113]
>     80: 025 107 113 113    # RHS_SUBS: [s:107] sub [_temp_:113] =>
>     [_temp_:113]
>     84: 042 107 112        # LENGTH: [s:107] => [_temp_:112]
>     87: 025 107 112 112    # RHS_SUBS: [s:107] sub [_temp_:112] =>
>     [_temp_:112]
>     91: 042 112 112        # LENGTH: [_temp_:112] => [_temp_:112]
>     94: 092 113 112 113    # RHS_SUBS_CHECK: [_temp_:113] sub [_temp_:112] 
>                            #     => [_temp_:113]
>     98: 036 111 113        # QPRINT: [_temp_:113]
> 
> Three lengths, and three RHS subscripts.  A 40% less efficient solution.
> We could help things out by precalculating length(s):
> }}}
<eucode>
> integer len
> len = length(s)
> ? s[len][length(s[len])]
> <font color="#330033"></eucode>
{{{
...</font><font color="#0000FF">and
> </font><font color="#330033">get:</font>
>    103: 042 107 115        # LENGTH: [s:107] => [len:115]
>    106: 087 115            # DISPLAY_VAR: [len:115] 
>    108: 058 14             # STARTLINE: 14 <<? s[len][length(s[len])]>>
>    110: 025 107 115 113    # RHS_SUBS: [s:107] sub [len:115] => [_temp_:113]
>    114: 025 107 115 112    # RHS_SUBS: [s:107] sub [len:115] => [_temp_:112]
>    118: 042 112 112        # LENGTH: [_temp_:112] => [_temp_:112]
>    121: 092 113 112 113    # RHS_SUBS_CHECK: [_temp_:113] sub [_temp_:112] 
>                            #     => [_temp_:113]
>    125: 036 111 113        # QPRINT: [_temp_:113]
> 
> Two lengths and three RHS subscripts (the DISPLAY_VAR and STARTLINE are 
> artifacts of "with trace," so they can be ignored for this discussion).
> That's only a 20% loss of efficiency.  Ah, but what if we do:
> }}}
<eucode>
> sequence slen
> slen = s[len]
> ? slen[length(slen)]
> <font color="#330033"></eucode>
{{{
...now we get:</font>
>    103: 042 107 115        # LENGTH: [s:107] => [len:115]
>    128: 058 17             # STARTLINE: 17 <<slen = s[len]>>
>    130: 025 107 115 116    # RHS_SUBS: [s:107] sub [len:115] => [slen:116]
>    134: 097 116            # SEQUENCE_CHECK: [slen:116]
>    140: 042 116 113        # LENGTH: [slen:116] => [_temp_:113]
>    143: 025 116 113 113    # RHS_SUBS: [slen:116] sub [_temp_:113] => 
>                            #     [_temp_:113]
>    147: 036 111 113        # QPRINT: [_temp_:113]
> 
> We got rid of the subscript, but added a sequence type check.  That's 
> probably less expensive than a subscript, so it probably saved some,
> but it's still more expensive than using $'s.  
> 
> So the end result is that for writing more complicated code, you've made
> the code less efficient than it could be.  I think the libary should be
> coded to the current version of Euphoria, which is currently 2.5.  
> Especially for the $, since it does offer a bit more than syntactic 
> sugar.
> 
> Matt Lewis
> 

Yea and also because of crash_routine() {Error handling?}. I'm sure most of the
people who are still using v2.4, are using it because v2.5 parses the whole file
and any includes before execution + the the fact that the frontend was translated
to C from Euphoria. But execution speed in v2.5 is the fastest yet. I'm guessing
Rob will do even more optimizations, and loading & execution speed will become
slighty faster in v3.0. Afterall, he rather do bug fixes and optimzations rather
than give us new features .


Regards,
Vincent

----------------------------------------------
     ___	      __________      ___
    /__/\            /__________\    |\ _\
    \::\'\          //::::::::::\\   |'|::|
     \::\'\        //:::_::::_:::\\  |'|::|
      \::\'\      //::/  |::|  \::\\ |'|::|
       \::\'\    //::/   |::|   \::\\|'|::|
        \::\'\__//::/    |::|    \::\|'|::|
         \::\','/::/     |::|     \::\\|::|
          \::\_/::/      |::|      \::\|::|
           \::,::/       |::|       \:::::|
            \___/        |__|        \____|

 	                 .``.
		         ',,'

30. Re: Changes in the ESL papers

• Posted by Pete Lomax <petelomax at blueyonder.co.uk> Jul 22, 2005
• 573 views
• Last edited Jul 23, 2005

On Fri, 22 Jul 2005 21:20:10 +0200, Juergen Luethje <j.lue at gmx.de>
wrote:

>> We should require that all files (both documentation and code) have
>> 8.3 file names (8 characters a '.' then the 3 character extention) so
>> that the files remain readable on DOS machines.
>
>This is often possible without pain (eg. math.e, string.e, cgi.e), but
>maybe sometimes only with considerable pain? I'm not sure.
>People could use my contribution 'Lfn.zip' to get full long filename
>support for their Euphoria DOS programs. 

The best way I know of to create a .zip file using a .bat script under
windows is to use pkzip 2.04g, which does not handle long filenames.
Unfortunately, I cannot change pkzip 2.04g to use lfn.zip )
I'm not sure what/when/where you imagine this considerable pain, but I
can tell you that building releases of applications when the standard
library does not use 8.3 filenames will be harder to automate.

Regards,
Pete
PS Actually, I have a freeware copy of the commandline pkzipc (2.5?,
4.0?, it's hard to tell, even pkware don't seem to know) which does
handle long filenames, but only on 95, 98, & Me, not on NT, 2000, or
XP. It seems it went payware.

32. Re: Changes in the ESL papers

• Posted by "Juergen Luethje" <j.lue at gmx.de> Jul 24, 2005
• 574 views

Pete Lomax wrote:

> I think the best way to handle errors consistently is:
> }}}
<eucode>
> 	result=f(x,y,z)
> 	if error then
> 		...
>
> 	p(x,y,z)
> 	if error then
> 		...
>
> </eucode>
{{{

> Where result should be the correct type rather than an object,
> and error is a global boolean (just the one for the whole of the
> standard library), reset at the start of every [global] routine.
> If error is set the value of result is meaningless. You can equally
> have a separate global object errorDetails if need be, the contents of
> which are routine-specific.

I vote for this one! Very cool! 
But currently it seems to be hard to get an agreement regarding this
point.

> Regards,
> Pete
> PS Another thought: All dates used in comments in the standard library
> should be unambiguous, eg 6 JUL 2005, since 6/7/05 may be read as
> June 7th 2005 by some. Not sure if that was mentioned.

Well, kind of, but not that clearly. In the General Guidelines in
'road_map.htm' we already had:

"For all things that are handled differently in different countries
(like the date format), our code [and documentation] follows generally
accepted international recommendations, mainly ISO and the RFCs, as far
as internet communication is concerned."

I added "and documentation" in the above paragraph, and also added the
following:

"Although e.g. the date 2005-07-06 /is/ unambiguous according to ISO,
some people might not realize that this is ISO format, or might not know
the ISO rules, and so it may be read erraneously as June 7th 2005 by
some. In order to express dates unambiguously, all dates used in
comments and documentation should preferably use the /name/ of the month
rather than its number."

Thanks,
   Juergen

34. Re: Changes in the ESL papers

• Posted by "Christian Cuvier" <christian.cuvier at agriculture.gouv.fr> Jul 25, 2005
• 565 views

> Date: Fri, 22 Jul 2005 16:48:47 +0100
> From: Pete Lomax <petelomax at blueyonder.co.uk>
> Subject: Re: Changes in the ESL papers
> 
> 
> On 22 Jul 2005 13:26:45 +0200, Christian Cuvier
> <Christian.CUVIER at agriculture.gouv.fr> wrote:
> 
> 
>>>>> Pete Lomax wrote:
>>>
>>>>>>>>> I retract that. Code it for 2.5 and have a utility to convert to 2.4.
> 
> 
>>>Please don't.
>>>s[legth(s)] and s[$] evaluate in different times. Converting 2.5 
>>>optimized code to 2.4 will work, but will lower efficiency. 2.4 
>>>optimized code will track the length of an ever expanding sequence to 
>>>scrape a few microseconds here and there. 2.5 optimized code won't.
> 
> This sounds like trading performance on 2.5 for performance on 2.4.
> Matt's post shows that $ offers a real gain on 2.5, and there is no
> excuse for those of us who still prefer 2.4 to penalise 2.5 users.
> 

Definitely not what I meant.
2.5 penalizes those of us who have problems with the high load time and 
the break in compatibility induced by the current impossibility to have 
dynamic include files.

My idea was to release separate files for each version of Euphoria, 
starting at 2.4, not 2.5 as was suggested. Thus, nobody gets penalised 
in any way.

> I ran some tests, and using $ can gain 26.4% over optimised 2.4. One
> case actually showed the full 40% hit mentioned by Matt, when running
> naive substitution of $ with length. My test results are based on the
> extreme $-abuse nonsense code which is:
> }}}
<eucode>
> sequence a
> 		 a={{0,{9,{8,7}}},{6,{5,4}},{3,2},1}
> 
> function f14()
> 	return a[$]+a[$-1][$]+a[$-2][$][$]+a[$-3][$][$][$]
> end function
> 
> sequence b
> 		 b={{{{5,4},3},2},1}
> 
> function f6()
> 	return b[$]+b[$-1][$]+b[$-1][$-1][$]
> end function
> </eucode>
{{{

> You might have more luck than me hand optimising that in 2.4, and you
> might have a better real-world example.
> 
> Conversely, the best optimised 2.4 code I could come up showed a 26.1%
> gain over naive substitution of the above. The smallest performance
> hit recorded (20%) was between 2.4 optimised and naive substitution.
> 
> Hence I conclude two things:
>  1) that no one code style is good for both 2.4 and 2.5, any code you 
>       can write (that makes extensive use of subscripting based on
>       the sequence length) will be at least 20% slower than it needs
>       to be on at least one of them.
>  2) the rule "don't use $" leads to the biggest hit, not only in the 
>       naive case but also the most carefully hand-optimised code.
> 
> However, I offer the suggestion below.
> 
> 
>>>I don't know a converter smart enough to perform this change of 
>>>implementation.
> 
> 
> You could place conversion markers in the source. Hopefully, this will
> not be required all that often, so the sources will not get too messy.
> }}}
<eucode>
> --2.4:
> --integer lt
> --0.0:
> 
> 	--2.5:
> 	while t[$] do
> 	--2.4:
> 	--lt=length(t)
> 	--while t[lt] do
> 	--0.0:
> </eucode>
{{{

> Where 0.0 indicates to the converter that following lines are valid on
> all versions, 2.5 instructs the converter to start commenting out
> lines, and 2.4 instructs the converter to start uncommenting lines.
> The lack of a space after the "--" indicates it is code, not comments.
> 
> If it starts to get fiddly, and readability is compromised, wrap
> entire routines:
> }}}
<eucode>
> --2.5:
> function replace_all(..)
> end function
> --2.4:
> --function replace_all(..)
> --end function
> --0.0:
> </eucode>
{{{

> 

Ok, could be an option, but this will confuse more people than plain 
Eu-version dependant sets of files imho.

CChris
> Regards,
> Pete
> 
> 
> --------------

36. Re: Changes in the ESL papers

• Posted by Matt Lewis <matthewwalkerlewis at gmail.com> Jul 25, 2005
• 569 views

Pete Lomax wrote:
> 
> Maybe "Who uses batch files to package their applications and has or
> would have to resort to payware to support long filenames", however if
> someone can confirm that infozip works (as NOT advertised!) on NT /
> 2000 / XP then my objection goes away.

Have you looked at 7zip? http://www.7-zip.org/

I don't usually use the command line version, but it's a really handy
open source archive package that can handle just about any archive format
out there.

Matt Lewis

38. Re: Changes in the ESL papers

• Posted by "Juergen Luethje" <j.lue at gmx.de> Jul 25, 2005
• 570 views

Sorry for the delay in replying.

Christian Cuvier wrote:

>> From: "Juergen Luethje"

<snip>

>> In the file 'road_map.htm' there is a new section "Specific guidelines
>> for documentation". I moved some points from other sections there, and
>> added the following:
>> - Something like "... works like function x in language y" as the only
>>   description is not considered a valid documentation, because it should
>>   not be required to know /other/ languages in order to understand
>>   /Euphoria/ related docs.
>
>
> Good move. Adding the reference may help people migrating from other
> languages (so that the remark may deserve to be there),

I agree.

> but indeed there must be a self-contained description.
>
>> In the section "Specific coding guidelines" I added:
>> - Do not use neither lowercase nor uppercase character O as variable
>>   name, because both are easily confused with zero. Also don't use
>>   lowercase letter l, because it will often be confused with the number
>>   one.
>>
>>
>> I still have (at least) the following questions:
>> - With what Eu versions should the library be compatible?
>
> 2.4 minimum. Versions optimized for later releases of Eu would be good too.

There seems to be no agreement currently. 

>> - Should the library have a global error handling function?
>
> Handling? Not sure. Display and report? Definitely. Consider the non
> public lib Chris Bensler wrote as a good sttarting point.

Same with this point.

>>   If so, it would probably be the best to implement it for the
>>   first version.
>> - What shall functions return in case of an error?
>
> Nothing, because illegal values vastly vary. I'd suggest using a
> separate structure to hold completion status.

Same here.

>> - Should we have one file that contains (almost) all global types
>>   (I vote for this), or should the global types be included in the
>>   respective modules?
>> - Is it sufficient that 1 person checks whether the code meets the
>>   specification, or should that be double-checked by an additional
>>   person?
>
> Double checking is always better, but how many people will be available?

I don't know.
When I set up the ESL papers, I tried to recall who recently wrote
something like "I want to participate.", and who didn't do so. Then
I made the list on <http://home.arcor.de/luethje.de.vu/esl/index.htm>.

At least so far neither someone who is on the list nor someone who is
not on the list has complained. 

Maybe we should build a table like the following?

Name      | What s/he wants to do
----------+----------------------
John Doe  | coding
Peter Pan | coding
...       | ...

If then for instance all people want to do nothing else but coding,
we'll realize that we have a problem.

Regards,
   Juergen