1. Suggestions for ESL (was: Euphoria Standard Library on UBoard)

Tommy Carlier wrote:

<snip>

> Here are some more suggestions I have for ESL:
> - the constants TRUE and FALSE

Yep, we have them already. smile

> - bitwise functions

I agree, but I vote for including them in a later version, not in the
first one. IMHO we should keep the first version rather small, so
that it will be released rather soon.
There are still enough decisions on general principles to do anyway.
In the OpenEU group, people discussed and discussed, ... and never
producecd a working release. My greatest fear concerning the ESL project
is, that the same happens to it.
And I will not believe that we are successful, until we actually do the
first release. That's why I would like to do it pretty soon.

> - a mechanism to ignore return-values of functions. Some options:
>   -> a global variable VOID: VOID = functionToIgnore(...) (like Win32Lib)
>   -> a procedure ignore that does nothing: ignore(functionToIgnore()) (like
>   Win4Eu)

I like both suggestions. Hard to say which one is "better".

> - an enumeration-mechanism: here's how it was done in Win4Eu:
>   }}}
<eucode>
>   constant DAY_OF_WEEK = enum()
>   constant MONDAY = next(DAY_OF_WEEK),
>            TUESDAY = next(DAY_OF_WEEK),
>            WEDNESDAY = next(DAY_OF_WEEK),
>            THURSDAY = next(DAY_OF_WEEK),
>            FRIDAY = next(DAY_OF_WEEK),
>            SATURDAY = next(DAY_OF_WEEK),
>            SUNDAY = next(DAY_OF_WEEK)
>   </eucode>
{{{


Sorry, I don't understand.
Should the function next() be in the library, and the code above is in
the user's program? Or should all the code above be in the library?

> - advanced C/API-interface functionality (WIN32/LINUX)

What exactly do you mean?

Regards,
   Juergen

new topic     » topic index » view message » categorize

2. Re: Suggestions for ESL (was: Euphoria Standard Library on UBoard)

Juergen Luethje wrote:
> > - a mechanism to ignore return-values of functions. Some options:
> >   -> a global variable VOID: VOID = functionToIgnore(...) (like Win32Lib)
> >   -> a procedure ignore that does nothing: ignore(functionToIgnore()) (like
> >   Win4Eu)
> I like both suggestions. Hard to say which one is "better".

I like the ignore-procedure, because it can only be used for ignoring stuff.
The global variable VOID can be used for storing temporary data and can be
passed to other routines, and that's not its purpose. I also think it reads
better. The code just says what it does: it calls a function and 'ignores'
the return value.

> > - an enumeration-mechanism: here's how it was done in Win4Eu:
> >   }}}
<eucode>
> >   constant DAY_OF_WEEK = enum()
> >   constant MONDAY = next(DAY_OF_WEEK),
> >            TUESDAY = next(DAY_OF_WEEK),
> >            WEDNESDAY = next(DAY_OF_WEEK),
> >            THURSDAY = next(DAY_OF_WEEK),
> >            FRIDAY = next(DAY_OF_WEEK),
> >            SATURDAY = next(DAY_OF_WEEK),
> >            SUNDAY = next(DAY_OF_WEEK)
> </eucode>
{{{
</font>
> 
> Sorry, I don't understand.
> Should the function next() be in the library, and the code above is in
> the user's program? Or should all the code above be in the library?

I'm talking about the enum- and next-function. The code above is just an
example of how to use it. It's a higher-level alternative for this:
constant MONDAY = 1,
         TUESDAY = 2,
         WEDNESDAY = 3,
         THURSDAY = 4,
         FRIDAY = 5,
         SATURDAY = 6,
         SUNDAY = 7

The advantage of using enum, is that you can later insert extra values
without having to renumber the existing ones.

> > - advanced C/API-interface functionality (WIN32/LINUX)
> What exactly do you mean?

Euphoria has some basic mechanisms for interfacing with C-code,
(DLL- and SO-files). ESL could contain some more advanced mechanisms
for this. I've seen this kind of functionality implemented in different
libraries, like Win32Lib.

--
The Internet combines the excitement of typing 
with the reliability of anonymous hearsay.

tommy online: http://users.telenet.be/tommycarlier
tommy.blog: http://tommycarlier.blogspot.com

new topic     » goto parent     » topic index » view message » categorize

3. Re: Suggestions for ESL (was: Euphoria Standard Library on UBoard)

On Sun, 24 Jul 2005 08:45:05 -0700, Tommy Carlier
<guest at RapidEuphoria.com> wrote:

>> >   }}}
<eucode>
>> >   constant DAY_OF_WEEK = enum()
>> >   constant MONDAY = next(DAY_OF_WEEK),
>> </eucode>
{{{
</font>

FWIW I'd prefer
constant DAY_OF_WEEK = create_enum()
constant MONDAY = enum(DAY_OF_WEEK)


Regards,
Pete

new topic     » goto parent     » topic index » view message » categorize

4. Re: Suggestions for ESL (was: Euphoria Standard Library on UBoard)

Pete Lomax wrote:
> 
> On Sun, 24 Jul 2005 08:45:05 -0700, Tommy Carlier
> <guest at RapidEuphoria.com> wrote:
> 
> >> >   }}}
<eucode>
> >> >   constant DAY_OF_WEEK = enum()
> >> >   constant MONDAY = next(DAY_OF_WEEK),
> <font color="#330033">>> </eucode>
{{{
</font></font>
> 
> FWIW I'd prefer
> }}}
<eucode>
> constant DAY_OF_WEEK = create_enum()
> constant MONDAY = enum(DAY_OF_WEEK)
> <font color="#330033"></eucode>
{{{
</font>
I prefer Pete's version over Tommy's however I think enum_begin(start_value,
step_value) and enum() is better because you're not so much creating an enum but
instead starting one.

new topic     » goto parent     » topic index » view message » categorize

5. Re: Suggestions for ESL (was: Euphoria Standard Library on UBoard)

D. Newhall wrote:
> 
> Pete Lomax wrote:
> > 
> > On Sun, 24 Jul 2005 08:45:05 -0700, Tommy Carlier
> > <guest at RapidEuphoria.com> wrote:
> > 
> > >> >   }}}
<eucode>
> > >> >   constant DAY_OF_WEEK = enum()
> > >> >   constant MONDAY = next(DAY_OF_WEEK),
> <font color="#330033">> <font color=</font><font
> color="#00A033">"#330033"</font><font color="#330033">>>>
> </eucode>
{{{
</font></font></font>
> > 
> > FWIW I'd prefer
> > }}}
<eucode>
> > constant DAY_OF_WEEK = create_enum()
> > constant MONDAY = enum(DAY_OF_WEEK)
> <font color="#330033">> <font color=</font><font
> color="#00A033">"#330033"</font><font color="#330033">></eucode>
{{{
</font></font>
> I prefer Pete's version over Tommy's however I think enum_begin(start_value,
> step_value)
> and enum() is better because you're not so much creating an enum but instead
> starting
> one.
> 


global atom enumerate
global function enum(atom a)
  if a then
    enumerate = a
    retun a
  else  
    return enumerate += 1
  end if
end function

-- set initial value
enumerate = 0

constant
  const1 = enum(0), -- increment by one
  const1 = enum(0),
  const1 = enum(0),
  const1 = enum(10), -- skip 4-9 set enumerate to 10
  const1 = enum(0)   -- now 11


Bernie

My files in archive:
w32engin.ew mixedlib.e eu_engin.e win32eru.exw

Can be downloaded here:
http://www.rapideuphoria.com/cgi-bin/asearch.exu?dos=on&win=on&lnx=on&gen=on&keywords=bernie+ryan

new topic     » goto parent     » topic index » view message » categorize

6. Re: Suggestions for ESL (was: Euphoria Standard Library on UBoard)

D. Newhall wrote:
> I prefer Pete's version over Tommy's however I think enum_begin(start_value,
> step_value)
> and enum() is better because you're not so much creating an enum but instead
> starting
> one.

Let me explain why I used 'enum' and 'next'.
In languages like C#, that have built-in support for enum-types, it looks
like this:
enum DayOfWeek
{
    Monday,
    Tuesday,
    Wednesday,
    Thursday,
    Friday,
    Saturday,
    Sunday
}

So 'DayOfWeek' is the enum-type, and Monday..Sunday are the possible values.
With 'enum' and 'next', you could interpret it like this:
constant
    DAY_OF_WEEK = enum(), -- define the enum DAY_OF_WEEK
    MONDAY  = next(DAY_OF_WEEK), -- MONDAY is the next DAY_OF_WEEK value
    TUESDAY = next(DAY_OF_WEEK), -- TUESDAY is the next DAY_OF_WEEK value
...


To demonstrate how simple this concept is, here's the code from Win4Eu
that implements the enum-system:
--- ENUMERATORS ---

sequence enums
enums = {}

global function enum()
    -- Creates a new enumerator-type
    enums &= 0
    return length(enums)
end function

global function next(integer enumType)
    -- Returns the next value in an enumerator
    integer next_
    next_ = enums[enumType] + 1
    enums[enumType] = next_
    return next_
end function


--
The Internet combines the excitement of typing 
with the reliability of anonymous hearsay.

tommy online: http://users.telenet.be/tommycarlier
tommy.blog: http://tommycarlier.blogspot.com

new topic     » goto parent     » topic index » view message » categorize

7. Re: Suggestions for ESL (was: Euphoria Standard Library on UBoard)

On Sun, 24 Jul 2005 10:32:49 -0700, Bernie Ryan
<guest at RapidEuphoria.com> wrote:

>  const1 = enum(10), -- skip 4-9 set enumerate to 10

Why don't you just set it directly to 10? Besides, using an arbitrary
value like this is suspect anyway - your program will come a cropper
if you insert enough new items in the lower segment to cross over with
the high order segment, and your code is littered with meaningless
10's. It is better to enumerate a separating constant, eg
constant Kand=enum(),
		...
		Klast=enum(),
		Batom=enum().
		...
	if x<Klast then	-- handle keywords
	elsif x>Klast then	-- handle builtins


Pete

new topic     » goto parent     » topic index » view message » categorize

8. Re: Suggestions for ESL (was: Euphoria Standard Library on UBoard)

As far as a naming convention for enum stuff goes, whatever is chosen should
reflect what the task is related to.

next() is very vague as far as a function name goes, whereas enum_next() would
make more sense.

enum() or enum_begin() are ok and tell the reader what the function relates to.

just my 2 pence worth :)

Dave

. .. : :: = == == = :: : .. .
Server-Side DB driven web sites,
Software Development
(and part-time games developer)

contact dave_p at purpletiger dot com
or probert.dave at gmail dot com
. .. : :: = == == = :: : .. .

new topic     » goto parent     » topic index » view message » categorize

9. Re: Suggestions for ESL (was: Euphoria Standard Library on UBoard)

On Sun, 24 Jul 2005 11:06:42 -0700, Tommy Carlier
<guest at RapidEuphoria.com> wrote:

>In languages like C#, that have built-in support for enum-types, it looks
<snip>
Hmm, no mixed enums there. Let's see:
constant DAY=enum(),
		 MONTH=enum(),
		Apr=next(MONTH),
		Aug=next(MONTH),
		Dec=next(MONTH),
		Feb=next(MONTH),
		Friday=next(DAY),
		Jan=next(MONTH),
		Jul=next(MONTH),
		Jun=next(MONTH),
		Mar=next(MONTH),
		Monday=next(DAY),
		Nov=next(MONTH),
		Oct=next(MONTH),
		Saturday=next(DAY),
		Sep=next(MONTH),
		Sunday=next(DAY),
		Thursday=next(DAY),
		Tuesday=next(DAY),
		Wednesday=next(DAY),


Does that look sensible to you?
Do you have any example of using mixed enums?

>To demonstrate how simple this concept is,
<snip>
Actually, in my last post I was not even suggesting changing that
functionality, just the names. But now I see even that simple code as
quite unnecessarily over complicated.

Pete

new topic     » goto parent     » topic index » view message » categorize

10. Re: Suggestions for ESL (was: Euphoria Standard Library on UBoard)

Dave Probert wrote:

> As far as a naming convention for enum stuff goes, whatever is chosen
> should reflect what the task is related to.
>
> next() is very vague as far as a function name goes,

Generally speaking, I agree. However I find it tempting to be able to
write code like (quoting Tommy):
constant
    DAY_OF_WEEK = enum(),        -- define the enum DAY_OF_WEEK
    MONDAY  = next(DAY_OF_WEEK), -- MONDAY is the next DAY_OF_WEEK value
    TUESDAY = next(DAY_OF_WEEK), -- TUESDAY is the next DAY_OF_WEEK value
...


> whereas enum_next() would make more sense.

But
constant
    DAY_OF_WEEK = enum(),        -- define the enum DAY_OF_WEEK
    MONDAY  = enum_next(DAY_OF_WEEK),
    TUESDAY = enum_next(DAY_OF_WEEK),
...

doesn't read so nice.

How about the following:
constant
    DAY_OF_WEEK = the_enum(),        -- define the enum DAY_OF_WEEK
    MONDAY  = the_next(DAY_OF_WEEK), -- MONDAY is the next DAY_OF_WEEK value
    TUESDAY = the_next(DAY_OF_WEEK), -- TUESDAY is the next DAY_OF_WEEK value
...


It still reads nice, and because both functions start with 'the_', it's
(more or less) obvious that they belong together. Or is that too crazy?

<snip>

Just an idea,
   Juergen

new topic     » goto parent     » topic index » view message » categorize

11. Re: Suggestions for ESL (was: Euphoria Standard Library on UBoard)

Juergen Luethje wrote:
> 
> Dave Probert wrote:
> 
> > As far as a naming convention for enum stuff goes, whatever is chosen
> > should reflect what the task is related to.
> >
> > next() is very vague as far as a function name goes,
> 
> Generally speaking, I agree. However I find it tempting to be able to
> write code like (quoting Tommy):
> }}}
<eucode>
> constant
>     DAY_OF_WEEK = enum(),        -- define the enum DAY_OF_WEEK
>     MONDAY  = next(DAY_OF_WEEK), -- MONDAY is the next DAY_OF_WEEK value
>     TUESDAY = next(DAY_OF_WEEK), -- TUESDAY is the next DAY_OF_WEEK value
> ...
> <font color="#330033"></eucode>
{{{
</font>
> 
> > whereas enum_next() would make more sense.
> 
> But
> }}}
<eucode>
> constant
>     DAY_OF_WEEK = enum(),        -- define the enum DAY_OF_WEEK
>     MONDAY  = enum_next(DAY_OF_WEEK),
>     TUESDAY = enum_next(DAY_OF_WEEK),
> ...
> <font color="#330033"></eucode>
{{{
</font>
> doesn't read so nice.
> 
> How about the following:
> }}}
<eucode>
> constant
>     DAY_OF_WEEK = the_enum(),        -- define the enum DAY_OF_WEEK
>     MONDAY  = the_next(DAY_OF_WEEK), -- MONDAY is the next DAY_OF_WEEK value
>     TUESDAY = the_next(DAY_OF_WEEK), -- TUESDAY is the next DAY_OF_WEEK value
> ...
> <font color="#330033"></eucode>
{{{
</font>
> 
> It still reads nice, and because both functions start with 'the_', it's
> (more or less) obvious that they belong together. Or is that too crazy?
> 
> <snip>
> 
> Just an idea,
>    Juergen

Too crazy. :) I don't think that many people would want to put "the_" infront of
anything really.


My $0.02 for if we want to make enum a type:

constant DAYS =  create_enumerator(1),
         SUNDAY = enumerate(DAYS),
         MONDAY = enumerate(DAYS),
         -- etc.

constant MULTIPLES_OF_TEN = create_enumerator({10,   -- start value
                                               10})  -- step value
         TEN = enumerate(MULIPLES_OF_TEN),
         TWENTY = enumerate(MULIPLES_OF_TEN),
         -- etc

It is more work but more descriptive. Kinda like how we use "integer" instead of
"int". We also need to make sure there's a way to specify step value.

The other option is without an explicit enum type.

begin_enumeration({10, 10})
constant TEN = enumerate(),
         TWENTY = enumerate(),
         -- etc.

constant TEN = begin_enumeration({10, 10}),
         TWENTY = enumerate(),
         -- etc.

Again, just throwing ideas around here.

new topic     » goto parent     » topic index » view message » categorize

12. Re: Suggestions for ESL (was: Euphoria Standard Library on UBoard)

D. Newhall wrote:
> 
> Juergen Luethje wrote:
> > 
> > Dave Probert wrote:
> > 
> > > As far as a naming convention for enum stuff goes, whatever is chosen
> > > should reflect what the task is related to.
> > >
> > > next() is very vague as far as a function name goes,
> > 
<snip>
> 
> Too crazy. :) I don't think that many people would want to put "the_" infront
> of anything
> really.

Sorry to say, but I must agree - imagine someone trying to guess what the_next()
means in documentation or code.  Sounds like a new age pop group!!!

Also have you considered this:

for a = 1 to 10 do
 ...
next

For old-skool basic programmers coming across to Euphoria they will get very
confused by the phrase 'next'.  It's just too short and meaningless as a word.

> My $0.02 for if we want to make enum a type:
> 
> constant DAYS =  create_enumerator(1),
>          SUNDAY = enumerate(DAYS),
>          MONDAY = enumerate(DAYS),
>          -- etc.
> 
<snip>

This is far more understandable in code - maybe not so 'readable' (ie short
names!), but definately much more sensible naming.
I realise that C# uses next(), but we're not trying to write C# in Euphoria!  
This is to be a Standard Library with certain conventions - one of which should
be meaningful naming conventions. Try not to look at the function names as only
appearing in test code fragments, but as someone who didn't design the function
but wants to use it and will be searching/scanning through the documentation for
it.  If it doesn't say what it does then there is the immediate chance of
confusion.

BTW, I'm all for the ESL.  In fact when I first came to use Euphoria it was one
of the things I was trying to get people to think about, but everybody just said
it would never happen.  It's nice to see so many people involved or making
comments about it.

Once the ESL gets underway at code level then I'm sure I have a few useful
functions that we can add :)

Cheers,

Dave

. .. : :: = == == = :: : .. .
Server-Side DB driven web sites,
Software Development
(and part-time games developer)

contact dave_p at purpletiger dot com
or probert.dave at gmail dot com
. .. : :: = == == = :: : .. .

new topic     » goto parent     » topic index » view message » categorize

13. Re: Suggestions for ESL (was: Euphoria Standard Library on UBoard)

Pete Lomax wrote:
> 
> 
> On Sun, 24 Jul 2005 11:06:42 -0700, Tommy Carlier
> <guest at RapidEuphoria.com> wrote:
> 
> 
>>In languages like C#, that have built-in support for enum-types, it looks
> 
> <snip>
> Hmm, no mixed enums there. Let's see:
> }}}
<eucode>
> constant DAY=enum(),
> 		 MONTH=enum(),
> 		Apr=next(MONTH),
> 		Aug=next(MONTH),
> 		Dec=next(MONTH),
> 		Feb=next(MONTH),
> 		Friday=next(DAY),
> 		Jan=next(MONTH),
> 		Jul=next(MONTH),
> 		Jun=next(MONTH),
> 		Mar=next(MONTH),
> 		Monday=next(DAY),
> 		Nov=next(MONTH),
> 		Oct=next(MONTH),
> 		Saturday=next(DAY),
> 		Sep=next(MONTH),
> 		Sunday=next(DAY),
> 		Thursday=next(DAY),
> 		Tuesday=next(DAY),
> 		Wednesday=next(DAY),
> </eucode>
{{{

> 
> Does that look sensible to you?
> Do you have any example of using mixed enums?
> 
> 
>>To demonstrate how simple this concept is,
> 
> <snip>
> Actually, in my last post I was not even suggesting changing that
> functionality, just the names. But now I see even that simple code as
> quite unnecessarily over complicated.
> 
> Pete

You would have to have a routine last_enum() or end_enum() or some such 
in order to restart the count.  Other libraries have similar mechanisms.

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

new topic     » goto parent     » topic index » view message » categorize

Search



Quick Links

User menu

Not signed in.

Misc Menu