1. Collections module for ESL
I would like to suggest a 'collections.e' module for the ESL.
I think it would be extremely useful to have hash tables, sets,
record tables etc.
Hash tables would be implemented as sets of key/value pairs e.g. ...
{"name","age","eye color",{"Joe Bloggs",54,"blue"))
Sets would be sequences that could not contain duplicate values and
would ignore attempts to 'append', 'prepend' or otherwise insert any
duplicates values
Record tables would be for large 'arrays' of identical records whose
fields are designated by their position in the record (I use this
kind of functionality very often, when a full DB solution would be
overkill). They could look like this ...
{"name","age","eye color",{{"Joe Bloggs",54,"blue"),{"Fred X",41,"green"} ... }
Gordon
2. Re: Collections module for ESL
Gordon Webster wrote:
>
> I would like to suggest a 'collections.e' module for the ESL.
>
> I think it would be extremely useful to have hash tables, sets,
> record tables etc.
>
> Hash tables would be implemented as sets of key/value pairs e.g. ...
> {"name","age","eye color",{"Joe Bloggs",54,"blue"))
>
> Sets would be sequences that could not contain duplicate values and
> would ignore attempts to 'append', 'prepend' or otherwise insert any
> duplicates values
>
> Record tables would be for large 'arrays' of identical records whose
> fields are designated by their position in the record (I use this
> kind of functionality very often, when a full DB solution would be
> overkill). They could look like this ...
> {"name","age","eye color",{{"Joe Bloggs",54,"blue"),{"Fred X",41,"green"} ...
> }
>
> Gordon
>
We'll definitely have all or most of those but maybe we should put them all in
different files.
I expect that we'll have a few advanced data type modules for the standard
variety of structures that most programmers use.
So how about:
queue.e
stack.e
hash.e
set.e
record.e
Personally, for record I prefer to have an n-length sequence record where the
first is a list of field names and the second is the data for each field.
{ {"name","age","eye color"},
{"Joe Bloggs",54,"blue"}
{"Fred X",41,"green"},
... }
So to get the value for "name" from everyone you just do a find(s[1], "name")
and use the result in all the sequences after the first.
3. Re: Collections module for ESL
D. Newhall wrote:
snipped stuff by Gordon
> We'll definitely have all or most of those but maybe we should put them all in
> different
> files.
>
> I expect that we'll have a few advanced data type modules for the standard
> variety
> of structures that most programmers use.
>
> So how about:
> queue.e
> stack.e
> hash.e
> set.e
> record.e
Also, I already have a stack.e, a queue.e, and a set.e file that I wrote for my
own use that I'd be glad to submit to the ESL.
stack.e defines x=pop(), push(x), and x=peek().
queue.e defines enqueue(x), x=dequeue(), x=front() (looks at first element), and
x=last() (looks at last element)
set.e defines union(s,s), intersect(s,s), compelement(s,s), b=subset(s,s),
b=superset(s,s) and some other stuff (will probably need to be
modified/rewritten).
4. Re: Collections module for ESL
D. Newhall wrote:
> Gordon Webster wrote:
>>
>> I would like to suggest a 'collections.e' module for the ESL.
>>
>> I think it would be extremely useful to have hash tables, sets,
>> record tables etc.
>>
>> Hash tables would be implemented as sets of key/value pairs e.g. ...
>> {"name","age","eye color",{"Joe Bloggs",54,"blue"))
>>
>> Sets would be sequences that could not contain duplicate values and
>> would ignore attempts to 'append', 'prepend' or otherwise insert any
>> duplicates values
>>
>> Record tables would be for large 'arrays' of identical records whose
>> fields are designated by their position in the record (I use this
>> kind of functionality very often, when a full DB solution would be
>> overkill). They could look like this ...
>> {"name","age","eye color",{{"Joe Bloggs",54,"blue"),{"Fred X",41,"green"} ...
>> }
>>
>> Gordon
>>
> We'll definitely have all or most of those
Yes, please. 
> but maybe we should put them all in different files.
>
> I expect that we'll have a few advanced data type modules for the
> standard variety of structures that most programmers use.
>
> So how about:
> queue.e
> stack.e
> hash.e
> set.e
> record.e
>
> Personally, for record I prefer to have an n-length sequence record
> where the first is a list of field names and the second is the data
> for each field.
>
> { {"name","age","eye color"},
> {"Joe Bloggs",54,"blue"}
> {"Fred X",41,"green"},
> ... }
>
> So to get the value for "name" from everyone you just do a find(s[1],
> "name") and use the result in all the sequences after the first.
So what shall I add to the papers?
Regards,
Juergen
5. Re: Collections module for ESL
Juergen Luethje wrote:
>
snip
> > I expect that we'll have a few advanced data type modules for the
> > standard variety of structures that most programmers use.
> >
> > So how about:
> > queue.e
> > stack.e
> > hash.e
> > set.e
> > record.e
Another snip
>
> So what shall I add to the papers?
For now you should say that files with those names have been proposed and each
is used for implementing the structure that's in its name.
Question for everyone: Should we implement the structures using types or hidden
sequences and have them referenced by ids? Both have their downsides. I vote for
the "hidden sequence" style with ids.
Example:
-- type example
stack s
object x
-- pop() would have to return the stack and the object
s = push(s, x)
x = pop(s)
s = x[1]
x = x[2]
-- "hidden sequence" example
integer stack_id
object x
-- "hidden sequence" style would need to initialize the stack first
stack_id = create_stack()
push(stack_id, x)
x = pop(stack_id, x)
6. Re: Collections module for ESL
On Mon, 25 Jul 2005 09:56:09 -0700, "D. Newhall"
<guest at RapidEuphoria.com> wrote:
>Question for everyone: Should we implement the structures using types or hidden
>sequences and have them referenced by ids?
>I vote for the "hidden sequence" style with ids.
I agree.
>Both have their downsides.
I believe the important thing when using ids (and huge stacks) is eg:
global procedure push(integer id, object x)
sequence onestack
onestack=stacks[id]
stacks[id]=0
onestack=append(onestack,x)
stacks[id]=onestack
end procedure
rather than:
global procedure push2(integer id, object x)
stacks[id]=append(stacks[id],x)
end procedure
Because the append is fully optimised only for simple variables.
A simple test:
atom t, t1, t2
t=time()
for i=1 to 10000 do
push(1,i)
end for
t1=time()-t
stacks={{}}
t=time()
for i=1 to 10000 do
push2(1,i)
end for
t2=time()-t
?{t1,t2}
shows the latter performing 700 times slower. So, with a little care
and attention, this approach is fine. You could probably optimise this
even further by having a parallel array of used extents and extending
each stacks[i] by say 32 elements as needed, instead of using append.
The functions I would like to see are:
push - add to end of stack
pop - remove from end of stack
pull - remove from start of stack
and possibly:
pump - insert at start of stack
peep - return false if stack is empty
push/pop implements a lifo stack, and
push/pull implements a fifo queue.
Regards,
Pete
7. Re: Collections module for ESL
- Posted by "Juergen Luethje" <j.lue at gmx.de>
Jul 25, 2005
-
Last edited Jul 26, 2005
D. Newhall wrote:
> Juergen Luethje wrote:
>>
> snip
>
>>> I expect that we'll have a few advanced data type modules for the
>>> standard variety of structures that most programmers use.
>>>
>>> So how about:
>>> queue.e
>>> stack.e
>>> hash.e
>>> set.e
>>> record.e
> Another snip
>
>>
>> So what shall I add to the papers?
>
> For now you should say that files with those names have been proposed
> and each is used for implementing the structure that's in its name.
I put them in the category "Modules proposed for later releases".
Or were they meant to be in the first release?
<snip>
Regards,
Juergen
