Menu
▾
▴
rapideuphoria-develop
|
From: Jeremy C. <je...@co...> - 2011-08-29 15:27:22
|
Any chance that maps could be moved to the backend for 4.1 along with an easier way to use them? Maps have become an essential in most programming languages.
map a
a[“name”] = “John Doe”
a[“age”] = 102
printf(1, “%s is %d years old\n”, { a[“name”], a[“age”] })
A function interface could still exist to do more advanced operations such as append, add, ...
Jeremy |
|
From: Matt L. <mat...@gm...> - 2011-08-29 16:00:00
|
On Mon, Aug 29, 2011 at 11:26 AM, Jeremy Cowgar <je...@co...> wrote: > Any chance that maps could be moved to the backend for 4.1 along with an > easier way to use them? Maps have become an essential in most programming > languages. Are you volunteering? :-) Personally, I was hoping to get 4.1 out roughly a year after 4.0. We'll see how that goes. I suspect that 64-bit and memory structures are likely to take most of my development time. -- Matt Lewis |
|
From: Derek <ddp...@bi...> - 2011-08-29 21:36:22
|
On Tue, 30 Aug 2011 01:59:54 +1000, Matt Lewis <mat...@gm...> wrote: > On Mon, Aug 29, 2011 at 11:26 AM, Jeremy Cowgar <je...@co...> > wrote: >> Any chance that maps could be moved to the backend for 4.1 along with an >> easier way to use them? Maps have become an essential in most >> programming >> languages. > > Are you volunteering? :-) > > Personally, I was hoping to get 4.1 out roughly a year after 4.0. > We'll see how that goes. I suspect that 64-bit and memory structures > are likely to take most of my development time. I wouldn't mind trying to implement back-end maps into the language. I have an interest in the field. -- Derek |
|
From: Matt L. <mat...@gm...> - 2011-08-29 21:39:13
|
On Mon, Aug 29, 2011 at 5:34 PM, Derek <ddp...@bi...> wrote: > On Tue, 30 Aug 2011 01:59:54 +1000, Matt Lewis > <mat...@gm...> wrote: > >> On Mon, Aug 29, 2011 at 11:26 AM, Jeremy Cowgar <je...@co...> >> wrote: >>> Any chance that maps could be moved to the backend for 4.1 along with an >>> easier way to use them? Maps have become an essential in most >>> programming >>> languages. >> >> Are you volunteering? :-) >> >> Personally, I was hoping to get 4.1 out roughly a year after 4.0. >> We'll see how that goes. I suspect that 64-bit and memory structures >> are likely to take most of my development time. > > I wouldn't mind trying to implement back-end maps into the language. I > have an interest in the field. Great! So long as it's in its own branch, we can decide whether to include it in 4.1 or to wait for 4.2 as we go. -- Matt Lewis |
|
From: Shawn P. <sha...@gm...> - 2011-08-30 02:57:22
|
On 29/08/2011 12:26 PM, Jeremy Cowgar wrote:
> Any chance that maps could be moved to the backend for 4.1 along with
> an easier way to use them? Maps have become an essential in most
> programming languages.
> map a
> a[“name”] = “John Doe”
> a[“age”] = 102
> printf(1, “%s is %d years old\n”, { a[“name”], a[“age”] })
> A function interface could still exist to do more advanced operations
> such as append, add, ...
> Jeremy
>
Will this mean doing away with std/map.e?
Shawn
|
|
From: Derek P. <ddp...@bi...> - 2011-08-30 07:40:53
|
On Tue, 30 Aug 2011 12:57:24 +1000, Shawn Pringle
<sha...@gm...> wrote:
> On 29/08/2011 12:26 PM, Jeremy Cowgar wrote:
>> Any chance that maps could be moved to the backend for 4.1 along with
>> an easier way to use them? Maps have become an essential in most
>> programming languages.
>> map a
>> a[“name”] = “John Doe”
>> a[“age”] = 102
>> printf(1, “%s is %d years old\n”, { a[“name”], a[“age”] })
>> A function interface could still exist to do more advanced operations
>> such as append, add, ...
>> Jeremy
>>
> Will this mean doing away with std/map.e?
No. It will still do the higher-level functionality but use the low-level
built-in mapping.
I'll post some syntax ideas for us to kick around first. For example,
maybe we should write it as ...
map a
a[[“name”]] = “John Doe”
a[[“age”]] = 102
printf(1, “%s is %d years old\n”, { a[[“name”]], a[[“age”]] })
so that the 'index' does not have to be a sequence but can be any Euphoria
object. We need to syntactically differentiate between ...
a[2] -- sequence indexing ('a' is a sequence)
and
a[[2]] -- map indexing ('a' is a map)
These are first thoughts but we need to think carefully about the syntax
and semantic implications.
--
Derek
|
|
From: Jeremy C. <je...@co...> - 2011-08-30 11:37:07
|
Could the [] operator not just look at the variable type? i.e.
map m
m[1] = "John"
[] would see m is a map and treat it accordingly.
sequence a = { 1, 2, 3 }
a[1] = 100
[] would see a is a sequence and treat it accordingly.
That would allow you to do
map m
m[{10,20}] = 30
m[{30,30}] = 60
or any other complex sequence and keep a simple syntax that is immediately
apparent to anyone who has done programming in the past. A language that
varies too much from the norm is a language that typically isn't adopted.
Vary from the norm when there is a good language design reason but I don't
think the lack of the ability of making the parser understand a single
syntax for multiple types is a good design reason?
Jeremy
-----Original Message-----
From: Derek Parnell
Sent: Tuesday, August 30, 2011 1:38 AM
To: rap...@li...
Subject: Re: [Rapideuphoria-develop] Maps in 4.1?
On Tue, 30 Aug 2011 12:57:24 +1000, Shawn Pringle
<sha...@gm...> wrote:
> On 29/08/2011 12:26 PM, Jeremy Cowgar wrote:
>> Any chance that maps could be moved to the backend for 4.1 along with
>> an easier way to use them? Maps have become an essential in most
>> programming languages.
>> map a
>> a[“name”] = “John Doe”
>> a[“age”] = 102
>> printf(1, “%s is %d years old\n”, { a[“name”], a[“age”] })
>> A function interface could still exist to do more advanced operations
>> such as append, add, ...
>> Jeremy
>>
> Will this mean doing away with std/map.e?
No. It will still do the higher-level functionality but use the low-level
built-in mapping.
I'll post some syntax ideas for us to kick around first. For example,
maybe we should write it as ...
map a
a[[“name”]] = “John Doe”
a[[“age”]] = 102
printf(1, “%s is %d years old\n”, { a[[“name”]], a[[“age”]] })
so that the 'index' does not have to be a sequence but can be any Euphoria
object. We need to syntactically differentiate between ...
a[2] -- sequence indexing ('a' is a sequence)
and
a[[2]] -- map indexing ('a' is a map)
These are first thoughts but we need to think carefully about the syntax
and semantic implications.
--
Derek
------------------------------------------------------------------------------
Special Offer -- Download ArcSight Logger for FREE!
Finally, a world-class log management solution at an even better
price-free! And you'll get a free "Love Thy Logs" t-shirt when you
download Logger. Secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsisghtdev2dev
_______________________________________________
Rapideuphoria-develop mailing list
Rap...@li...
https://lists.sourceforge.net/lists/listinfo/rapideuphoria-develop
|
|
From: Matt L. <mat...@gm...> - 2011-08-30 16:53:42
|
On Tue, Aug 30, 2011 at 7:36 AM, Jeremy Cowgar <je...@co...> wrote:
> Could the [] operator not just look at the variable type? i.e.
>
> map m
> m[1] = "John"
>
> [] would see m is a map and treat it accordingly.
>
> sequence a = { 1, 2, 3 }
> a[1] = 100
>
> [] would see a is a sequence and treat it accordingly.
This is not nearly as simple as it sounds. What about stuff like:
sequence s = { "maps!", map:new() }
? s[1][2]
? s[2][2]
I've gone a ways down the road of static typing with eu, and it's not
pretty. This is why I adopted my current syntax for memstructs (i.e.,
including the memstruct name as part of the access method).
--
Matt Lewis
|
|
From: Derek <ddp...@bi...> - 2011-08-30 16:58:26
|
On Tue, 30 Aug 2011 21:36:02 +1000, Jeremy Cowgar <je...@co...>
wrote:
> Could the [] operator not just look at the variable type? i.e.
Yes, but a cost to run-time performance. This is due to the dynamic data
typing aspect of Euphoria.
Consider this library routine ...
public procedure Proc( object x)
x[1] = "John"
x["id"] = "JJ"
. . .
end procedure
It is not possible for the parser to know if the argument to Proc is a map
or not, so therefore it must add runtime checks into the IL to ensure that
the correct type of indexing happens when Proc is called.
In fact, currently the parser does not static type checking in a number of
situations and leaves this up to run-time type checking. As you know, each
of the low-level data types (integer, atom and sequence) are coded into
the run-time data of the object so that run-time type checking can occur.
If we add 'map' as a new sort low-level data type we would have to add a
new bit-tag for data objects and this would then force additional run-time
checking for many fundamental operations. This is the same issue we have
seen before when people have suggested such things as native strings vs
sequences.
If however, we instead introduce 'map' as a specialized type of sequence,
and force the coder to specify mapping clues in their code for the parser,
it will not have a noticeable effect on run-time performance.
To keep consistency we would want Euphoria to be able to assign a map to
an object, and that implies that run-time checking for map data types
would also be possible. However that does not make it necessary for a
'map' to be a low-level data type.
>
> map m
> m[1] = "John"
>
> [] would see m is a map and treat it accordingly.
The parser is not currently that sophisticated. For example ...
integer x
x[1] = 1
x["abc"] = 2
Is perfectly valid SYNTAX to the parser. Of course it generates run-time
errors, but not any parse-time errors.
> sequence a = { 1, 2, 3 }
> a[1] = 100
>
> [] would see a is a sequence and treat it accordingly.
>
> That would allow you to do
>
> map m
> m[{10,20}] = 30
> m[{30,30}] = 60
>
> or any other complex sequence and keep a simple syntax that is
> immediately
> apparent to anyone who has done programming in the past. A language that
> varies too much from the norm is a language that typically isn't adopted.
> Vary from the norm when there is a good language design reason but I
> don't
> think the lack of the ability of making the parser understand a single
> syntax for multiple types is a good design reason?
A reasonable argument ... however Euphoria already does "vary from the
norm".
if "abc" > "de" then
is quite normal for many languages, but not Euphoria (or C/C++ either for
that matter).
--
Derek
|
|
From: Shawn P. <sha...@gm...> - 2011-08-30 19:01:06
|
On 30/08/2011 1:56 PM, Derek wrote:
> On Tue, 30 Aug 2011 21:36:02 +1000, Jeremy Cowgar<je...@co...>
> wrote:
>
>> Could the [] operator not just look at the variable type? i.e.
> Yes, but a cost to run-time performance. This is due to the dynamic data
> typing aspect of Euphoria.
>
> Consider this library routine ...
>
> public procedure Proc( object x)
> x[1] = "John"
> x["id"] = "JJ"
> . . .
> end procedure
>
> It is not possible for the parser to know if the argument to Proc is a map
> or not, so therefore it must add runtime checks into the IL to ensure that
> the correct type of indexing happens when Proc is called.
>
> In fact, currently the parser does not static type checking in a number of
> situations and leaves this up to run-time type checking. As you know, each
> of the low-level data types (integer, atom and sequence) are coded into
> the run-time data of the object so that run-time type checking can occur.
> If we add 'map' as a new sort low-level data type we would have to add a
> new bit-tag for data objects and this would then force additional run-time
> checking for many fundamental operations. This is the same issue we have
> seen before when people have suggested such things as native strings vs
> sequences.
>
> If however, we instead introduce 'map' as a specialized type of sequence,
> and force the coder to specify mapping clues in their code for the parser,
> it will not have a noticeable effect on run-time performance.
>
> To keep consistency we would want Euphoria to be able to assign a map to
> an object, and that implies that run-time checking for map data types
> would also be possible. However that does not make it necessary for a
> 'map' to be a low-level data type.
>
>> map m
>> m[1] = "John"
>>
>> [] would see m is a map and treat it accordingly.
> The parser is not currently that sophisticated. For example ...
>
> integer x
> x[1] = 1
> x["abc"] = 2
>
> Is perfectly valid SYNTAX to the parser. Of course it generates run-time
> errors, but not any parse-time errors.
>
>
>> sequence a = { 1, 2, 3 }
>> a[1] = 100
>>
>> [] would see a is a sequence and treat it accordingly.
>>
>> That would allow you to do
>>
>> map m
>> m[{10,20}] = 30
>> m[{30,30}] = 60
>>
>> or any other complex sequence and keep a simple syntax that is
>> immediately
>> apparent to anyone who has done programming in the past. A language that
>> varies too much from the norm is a language that typically isn't adopted.
>> Vary from the norm when there is a good language design reason but I
>> don't
>> think the lack of the ability of making the parser understand a single
>> syntax for multiple types is a good design reason?
>
> A reasonable argument ... however Euphoria already does "vary from the
> norm".
>
> if "abc"> "de" then
>
> is quite normal for many languages, but not Euphoria (or C/C++ either for
> that matter).
>
>
I don't understand the need to put this (and several other things) into
the 'backend' (which for now also means into C)
Notable also are regular expressions, then sockets and now maps. Though
successful with regular expressions and sockets. I think we could have
avoided many bugs (like the non-INT_ATOM integers problem in sockets,
the breaking of Windows 9x builds) and there were many cases where the
regular expressions would crash when I started documenting them. If
you consider the same EUPHORIA developer will produce fewer bugs using
EUPHORIA than in C, and consider that maps in EUPHORIA are, already
done. It is like going east to get from France to the UK. You can do
it, but it is not the most efficient way. What ever syntax is chosen it
would be a easier to make the parser convert something like m[ foo ]
into map:get( m, foo ).
Shawn
|
|
From: Derek <ddp...@bi...> - 2011-08-30 19:08:22
|
On Wed, 31 Aug 2011 05:01:07 +1000, Shawn Pringle <sha...@gm...> wrote: > I don't understand the need to put this (and several other things) into > the 'backend' (which for now also means into C) To dramatically improve performance. Currently, maps are fairly slow when compared to implementations in other languages. -- Derek |
|
From: Jeremy C. <je...@co...> - 2011-08-31 07:32:49
|
There is a difference between the Euphoria language and programming in Euphoria. Even those skilled at Euphoria may find the actual language implementation difficult to grasp, maintain and add to (I do). There are two groups of people in the Euphoria community. Those who use Euphoria and those who develop Euphoria. Those who develop Euphoria must know Euphoria and C. There is no escaping it. The regex implementation was FAR easier by using an already existing, powerful, industry standard regular expression library such as PCRE. We gain years of bug testing and design by doing so in addition to an automatic +10 developers doing work for us. With sockets the codebase actually was cut in 1/3 by moving to the backend because we could simply use the correct include files and not have an ifdef for every new platform that we supported. Thus, it's future proof and more stable. For example, if someone ports to a new OS/platform they do not have to also port the socket library (such as ARM). That comes automatic. And not just for new platforms but for existing OS changes from version to version. We shouldn't be scared of C nor the backend. There are things that C does much better than Euphoria and as designers and maintainers of the Euphoria language when something comes about that is easier, more efficient or will make maintaining the language easier by doing it in C it should automatically be done in C. Jeremy -----Original Message----- From: Shawn Pringle Sent: Tuesday, August 30, 2011 3:01 PM To: rap...@li... Subject: Re: [Rapideuphoria-develop] Maps in 4.1? I don't understand the need to put this (and several other things) into the 'backend' (which for now also means into C) Notable also are regular expressions, then sockets and now maps. Though successful with regular expressions and sockets. I think we could have avoided many bugs (like the non-INT_ATOM integers problem in sockets, the breaking of Windows 9x builds) and there were many cases where the regular expressions would crash when I started documenting them. If you consider the same EUPHORIA developer will produce fewer bugs using EUPHORIA than in C, and consider that maps in EUPHORIA are, already done. It is like going east to get from France to the UK. You can do it, but it is not the most efficient way. What ever syntax is chosen it would be a easier to make the parser convert something like m[ foo ] into map:get( m, foo ). |
|
From: Shawn P. <sha...@gm...> - 2011-08-31 14:18:48
|
I want you all to know it wasn't my idea that we should have re-implemented the PCRE library itself in EUPHORIA. It was more an argument on how we can wrap things in. On the other hand, since most free code out there probably is C there must also be a free library for maps. The C++ Standard Template Library comes to mind. Something that has been maintained for years bug tracked. Maybe Donald Knuth has an implementation. Other languages restrict what you can put into the keys of a map. I don't know why you would normally want to map arbitrary object keys (except maybe in replacing SymTab structure in the parser for EUPHORIA). Most of the time we want to map strings to something. Something optimized for this will keep most people happy. Shawn On 31/08/2011 4:32 AM, Jeremy Cowgar wrote: > There is a difference between the Euphoria language and programming in > Euphoria. Even those skilled at Euphoria may find the actual language > implementation difficult to grasp, maintain and add to (I do). There are two > groups of people in the Euphoria community. Those who use Euphoria and those > who develop Euphoria. Those who develop Euphoria must know Euphoria and C. > There is no escaping it. The regex implementation was FAR easier by using an > already existing, powerful, industry standard regular expression library > such as PCRE. We gain years of bug testing and design by doing so in > addition to an automatic +10 developers doing work for us. With sockets the > codebase actually was cut in 1/3 by moving to the backend because we could > simply use the correct include files and not have an ifdef for every new > platform that we supported. Thus, it's future proof and more stable. For > example, if someone ports to a new OS/platform they do not have to also port > the socket library (such as ARM). That comes automatic. And not just for new > platforms but for existing OS changes from version to version. > > We shouldn't be scared of C nor the backend. There are things that C does > much better than Euphoria and as designers and maintainers of the Euphoria > language when something comes about that is easier, more efficient or will > make maintaining the language easier by doing it in C it should > automatically be done in C. > > Jeremy > > -----Original Message----- > From: Shawn Pringle > Sent: Tuesday, August 30, 2011 3:01 PM > To: rap...@li... > Subject: Re: [Rapideuphoria-develop] Maps in 4.1? > > I don't understand the need to put this (and several other things) into > the 'backend' (which for now also means into C) > Notable also are regular expressions, then sockets and now maps. Though > successful with regular expressions and sockets. I think we could have > avoided many bugs (like the non-INT_ATOM integers problem in sockets, > the breaking of Windows 9x builds) and there were many cases where the > regular expressions would crash when I started documenting them. If > you consider the same EUPHORIA developer will produce fewer bugs using > EUPHORIA than in C, and consider that maps in EUPHORIA are, already > done. It is like going east to get from France to the UK. You can do > it, but it is not the most efficient way. What ever syntax is chosen it > would be a easier to make the parser convert something like m[ foo ] > into map:get( m, foo ). > > > ------------------------------------------------------------------------------ > Special Offer -- Download ArcSight Logger for FREE! > Finally, a world-class log management solution at an even better > price-free! And you'll get a free "Love Thy Logs" t-shirt when you > download Logger. Secure your free ArcSight Logger TODAY! > http://p.sf.net/sfu/arcsisghtdev2dev > _______________________________________________ > Rapideuphoria-develop mailing list > Rap...@li... > https://lists.sourceforge.net/lists/listinfo/rapideuphoria-develop |
|
From: Jeremy C. <je...@co...> - 2011-08-31 07:37:49
|
Just to kick around a few other ideas... these are only ideas, not sure any
of them are even good or mediocre ideas but with such an important language
design, we should have a few. Best way to have a good idea is to have many,
right?
@ symbol
my_map@"name" = "John"
my_map@{10,20} = 30
my_map @ {30, 40} = 70 -- spacing shouldn't matter
printf(1, "Hello, %s\n", { my_map@"name" })
# symbol
my_map#"name" = "John
my_map#{10,20} = 30
my_map # {30, 40} = 70 -- spacing shouldn't matter
printf(1, "Hello, %s\n", { my_map#"name" })
@ symbol inside brackets
my_map[@"name"] = "John"
my_map[@{10,20}] = 30
my_map[@ {30, 40}] = 70 -- spacing shouldn't matter
printf(1, "Hello, %s\n", { my_map[@"name"] })
# symbol inside brackets
my_map[#"name"] = "John"
my_map[#{10,20}] = 30
my_map[# {30, 40}] = 70 -- spacing shouldn't matter
printf(1, "Hello, %s\n", { my_map[#"name"] })
Jeremy
-----Original Message-----
From: Derek Parnell
Sent: Tuesday, August 30, 2011 1:38 AM
To: rap...@li...
Subject: Re: [Rapideuphoria-develop] Maps in 4.1?
map a
a[[“name”]] = “John Doe”
a[[“age”]] = 102
printf(1, “%s is %d years old\n”, { a[[“name”]], a[[“age”]] })
so that the 'index' does not have to be a sequence but can be any Euphoria
object. We need to syntactically differentiate between ...
a[2] -- sequence indexing ('a' is a sequence)
and
a[[2]] -- map indexing ('a' is a map)
These are first thoughts but we need to think carefully about the syntax
and semantic implications.
--
Derek
------------------------------------------------------------------------------
Special Offer -- Download ArcSight Logger for FREE!
Finally, a world-class log management solution at an even better
price-free! And you'll get a free "Love Thy Logs" t-shirt when you
download Logger. Secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsisghtdev2dev
_______________________________________________
Rapideuphoria-develop mailing list
Rap...@li...
https://lists.sourceforge.net/lists/listinfo/rapideuphoria-develop
|
|
From: Shawn P. <sha...@gm...> - 2011-08-31 13:43:22
|
On 31/08/2011 4:37 AM, Jeremy Cowgar wrote: > Just to kick around a few other ideas... these are only ideas, not sure any > of them are even good or mediocre ideas but with such an important language > design, we should have a few. Best way to have a good idea is to have many, > right? > How about this: value = map:get( this_map, mykey ) set( this_map, mykey, new_value ) You could have two implementations of maps in the same program. Whereas one might be faster for some kind of data the other might be better for the other. This is a fundamental reason to reuse function names. Imagine it might be used like this: include std/map.e as country_names -- map of country_names (using the 4.0 front end version) include std/bemap.e as stmap -- map for students (using the backend) include std/bemap.e as pmap -- map of parents In this example, the maps involving students use stmap namespace for all of its operations and those using country_names use the country_names namespace. What might be faster in some situations can be and often is slower in others. The user (programmer) can choose which implementation before, during and after writing his code using the maps when the interface is reused over. You can use the so called "machine" interface as with regex.e rather than builtins. I don't think we should add this to the default namespace. It is better to allow a user to include it or not include it. Shawn |
|
From: Jeremy C. <je...@co...> - 2011-08-31 13:55:50
|
Maps are as essential to a programming language as the the array. Would you want to program like: array:set_element(my_array, 1, "John") value = array:get_element(my_array, 1) instead of my_array[1] = "John" value = my_array[1] Why are you so against enhancing the language for common use patterns? Enhancing the language for situations that never occur should be avoided like the plague. Jeremy -----Original Message----- From: Shawn Pringle Sent: Wednesday, August 31, 2011 9:43 AM To: rap...@li... Subject: [Rapideuphoria-develop] Map Interfface Ideas: Maps in 4.1? How about this: value = map:get( this_map, mykey ) set( this_map, mykey, new_value ) You could have two implementations of maps in the same program. Whereas one might be faster for some kind of data the other might be better for the other. This is a fundamental reason to reuse function names. Imagine it might be used like this: include std/map.e as country_names -- map of country_names (using the 4.0 front end version) include std/bemap.e as stmap -- map for students (using the backend) include std/bemap.e as pmap -- map of parents In this example, the maps involving students use stmap namespace for all of its operations and those using country_names use the country_names namespace. What might be faster in some situations can be and often is slower in others. The user (programmer) can choose which implementation before, during and after writing his code using the maps when the interface is reused over. You can use the so called "machine" interface as with regex.e rather than builtins. I don't think we should add this to the default namespace. It is better to allow a user to include it or not include it. Shawn ------------------------------------------------------------------------------ Special Offer -- Download ArcSight Logger for FREE! Finally, a world-class log management solution at an even better price-free! And you'll get a free "Love Thy Logs" t-shirt when you download Logger. Secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsisghtdev2dev _______________________________________________ Rapideuphoria-develop mailing list Rap...@li... https://lists.sourceforge.net/lists/listinfo/rapideuphoria-develop |
|
From: Matt L. <mat...@gm...> - 2011-08-30 19:11:24
|
On Tue, Aug 30, 2011 at 3:01 PM, Shawn Pringle <sha...@gm...> wrote: > > I don't understand the need to put this (and several other things) into > the 'backend' (which for now also means into C) > Notable also are regular expressions, then sockets and now maps. Though > successful with regular expressions and sockets. I think we could have > avoided many bugs (like the non-INT_ATOM integers problem in sockets, > the breaking of Windows 9x builds) and there were many cases where the > regular expressions would crash when I started documenting them. Yes, any development will lead to bugs. I think a backend regex solution was really the only viable way to go. There was no reasonable euphoria implementation of regexes, and was never likely to be one. It's difficult, and the C implementation we used is pretty mature and effectively a standard. I'm less knowledgeable about sockets, but my understanding is that putting them in the backend made cross platform issues a lot easier to deal with. > If > you consider the same EUPHORIA developer will produce fewer bugs using > EUPHORIA than in C, and consider that maps in EUPHORIA are, already > done. It is like going east to get from France to the UK. You can do > it, but it is not the most efficient way. What ever syntax is chosen it > would be a easier to make the parser convert something like m[ foo ] > into map:get( m, foo ). We've always wanted a C implementation of maps for speed purposes. Benchmarking shows that our euphoria implementation of maps is a lot slower than what you get in other languages, so there's a big opportunity for improvement in this area. We'll see how much improvement we can realize. -- Matt Lewis |
|
From: Matt L. <mat...@gm...> - 2011-08-31 14:03:58
|
On Wed, Aug 31, 2011 at 9:55 AM, Jeremy Cowgar <je...@co...> wrote: > Maps are as essential to a programming language as the the array. Maybe, but so in I/O, and we use routines for most of that. Frankly, I've thought that using map.e as a thin wrapper (we could move the current map.e to eumap.e or something) would be the easiest way to transition and implement. And we don't have to come up with stuff like slightly different notation for using nested maps, either. While some dynamic languages have bulit-in dictionary / hash / map-like support built-in, there are also a lot of languages that use dedicated classes or built-in methods (e.g., Java, C/C++/C#). There's also an argument that using routines is more expressive, and easier to substitute different implementations if desired. For instance, a btree vs a hashmap (or whatever makes more sense for your data). -- Matt Lewis |
|
From: Jeremy C. <je...@co...> - 2011-08-31 14:20:21
|
I guess my end thoughts on how things would go was to keep the map.e interface. Put the stuff in C that is causing us our slow down. Then add syntax sugar for the most common operations such as assign/retrieve. I didn't think we were getting rid of map.e. Jeremy -----Original Message----- From: Matt Lewis Sent: Wednesday, August 31, 2011 10:03 AM To: rap...@li... Subject: Re: [Rapideuphoria-develop] Map Interfface Ideas: Maps in 4.1? On Wed, Aug 31, 2011 at 9:55 AM, Jeremy Cowgar <je...@co...> wrote: > Maps are as essential to a programming language as the the array. Maybe, but so in I/O, and we use routines for most of that. Frankly, I've thought that using map.e as a thin wrapper (we could move the current map.e to eumap.e or something) would be the easiest way to transition and implement. And we don't have to come up with stuff like slightly different notation for using nested maps, either. While some dynamic languages have bulit-in dictionary / hash / map-like support built-in, there are also a lot of languages that use dedicated classes or built-in methods (e.g., Java, C/C++/C#). There's also an argument that using routines is more expressive, and easier to substitute different implementations if desired. For instance, a btree vs a hashmap (or whatever makes more sense for your data). -- Matt Lewis ------------------------------------------------------------------------------ Special Offer -- Download ArcSight Logger for FREE! Finally, a world-class log management solution at an even better price-free! And you'll get a free "Love Thy Logs" t-shirt when you download Logger. Secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsisghtdev2dev _______________________________________________ Rapideuphoria-develop mailing list Rap...@li... https://lists.sourceforge.net/lists/listinfo/rapideuphoria-develop |
|
From: Jim C. B. <jbr...@li...> - 2011-08-31 14:20:49
|
On Wed, Aug 31, 2011 at 10:03:52AM -0400, Matt Lewis wrote: > On Wed, Aug 31, 2011 at 9:55 AM, Jeremy Cowgar <je...@co...> wrote: > > Maps are as essential to a programming language as the the array. Agreed. > > Maybe, but so in I/O, and we use routines for most of that. Frankly, > I've thought that using map.e as a thin wrapper (we could move the > current map.e to eumap.e or something) would be the easiest way to > transition and implement. This gets kind of weird if we add maps as a new type altogether. We dobn't really have anything like that right now (the closest would be regexes but those are really just atoms). > And we don't have to come up with stuff > like slightly different notation for using nested maps, either. Huh? > > While some dynamic languages have bulit-in dictionary / hash / > map-like support built-in, there are also a lot of languages that use > dedicated classes or built-in methods (e.g., Java, C/C++/C#). Both C# and C++ use the array bracket map[string] syntax. Additionally, I wouldn't be suprised to find out that either C# or Java (or both) implement maps in the EE/VM instead of writing an implementation in the source language. (Well, the example I have for C++ is from Visual Studio. http://www.codeguru.com/forum/showthread.php?t=315286 Another from the STL http://www.sgi.com/tech/stl/hash_map.html ) > > There's also an argument that using routines is more expressive, and > easier to substitute different implementations if desired. For > instance, a btree vs a hashmap (or whatever makes more sense for your > data). That's a really good point. I find myself agreeing with this. However, and like the names of the builtin IO routines that are very commonly used, if we go this route we should make sure to keep the names of the routines short. (add(), get(), put(), and so on.) > > -- > Matt Lewis > > ------------------------------------------------------------------------------ > Special Offer -- Download ArcSight Logger for FREE! > Finally, a world-class log management solution at an even better > price-free! And you'll get a free "Love Thy Logs" t-shirt when you > download Logger. Secure your free ArcSight Logger TODAY! > http://p.sf.net/sfu/arcsisghtdev2dev > _______________________________________________ > Rapideuphoria-develop mailing list > Rap...@li... > https://lists.sourceforge.net/lists/listinfo/rapideuphoria-develop -- Infinite complexity begets infinite beauty. Infinite precision begets infinite perfection. |
|
From: Matt L. <mat...@gm...> - 2011-08-31 14:33:15
|
On Wed, Aug 31, 2011 at 10:20 AM, Jim C. Brown <jbr...@li...> wrote: > On Wed, Aug 31, 2011 at 10:03:52AM -0400, Matt Lewis wrote: >> >> Maybe, but so in I/O, and we use routines for most of that. Frankly, >> I've thought that using map.e as a thin wrapper (we could move the >> current map.e to eumap.e or something) would be the easiest way to >> transition and implement. > > This gets kind of weird if we add maps as a new type altogether. We > dobn't really have anything like that right now (the closest would be regexes > but those are really just atoms). I definitely disagree with a fundamental new type. I'd say that they should essentially be what they are now (from the user's point of view): opaque handles represented as atoms that cause their backing data to be freed when they are ultimately garbage collected via a zero reference count. In short, I'd have the actual map structure be entirely in the backend, which solves a lot of performance problems with worrying about reference counting of the sequence we currently use to store maps. Derek may have other ideas, but that's where I'd start. >> And we don't have to come up with stuff >> like slightly different notation for using nested maps, either. > Huh? I'm referring to nested_get/put. Basically, how do you make this easy to do and efficient? You can't simply pass a sequence of keys, since that's a valid key itself. Possibly it would look like additional subscripting (assuming that's the direction we go) or something. My point is just that if we add new notation, we're complicating euphoria code for IMHO not a whole lot of benefit. >> While some dynamic languages have bulit-in dictionary / hash / >> map-like support built-in, there are also a lot of languages that use >> dedicated classes or built-in methods (e.g., Java, C/C++/C#). > > Both C# and C++ use the array bracket map[string] syntax. Additionally, > I wouldn't be suprised to find out that either C# or Java (or both) > implement maps in the EE/VM instead of writing an implementation in the > source language. OK, true. I tend to use the actual STL methods (find, insert, etc) in C++. C++ and its overloading of operators is a monster in its own right. >> >> There's also an argument that using routines is more expressive, and >> easier to substitute different implementations if desired. For >> instance, a btree vs a hashmap (or whatever makes more sense for your >> data). > > That's a really good point. I find myself agreeing with this. However, > and like the names of the builtin IO routines that are very commonly > used, if we go this route we should make sure to keep the names of the > routines short. (add(), get(), put(), and so on.) Yes, I'd stick with exactly what we have in map.e, so as to make it easy to switch between our current implementation and an optimized backend implementation. -- Matt Lewis |
|
From: Jim C. B. <jbr...@li...> - 2011-08-31 14:49:34
|
On Wed, Aug 31, 2011 at 10:33:09AM -0400, Matt Lewis wrote: > On Wed, Aug 31, 2011 at 10:20 AM, Jim C. Brown > <jbr...@li...> wrote: > > > >> And we don't have to come up with stuff > >> like slightly different notation for using nested maps, either. > > Huh? > > I'm referring to nested_get/put. Basically, how do you make this easy > to do and efficient? You can't simply pass a sequence of keys, since > that's a valid key itself. Possibly it would look like additional > subscripting (assuming that's the direction we go) or something. My > point is just that if we add new notation, we're complicating euphoria > code for IMHO not a whole lot of benefit. I think I understand. Nested maps are easy to deal with. Just: topmap[@key][@keyofsubmap] or topmap#key#keyofsubmap nested_get/put should be provided by map.e and done the way it is now - pass in a sequence of keys. Each key can itself be a sequence - even one that looks like a sequence of keys - but there's no confusion whether or not a given sequence is being used as a set of keys or as a single key. Is there something I'm missing? > >> There's also an argument that using routines is more expressive, and > >> easier to substitute different implementations if desired. For > >> instance, a btree vs a hashmap (or whatever makes more sense for your > >> data). > > > > That's a really good point. I find myself agreeing with this. However, > > and like the names of the builtin IO routines that are very commonly > > used, if we go this route we should make sure to keep the names of the > > routines short. (add(), get(), put(), and so on.) > > Yes, I'd stick with exactly what we have in map.e, so as to make it > easy to switch between our current implementation and an optimized > backend implementation. If we don't add any syntax sugar, then I think this is the best way to go as well. > > -- > Matt Lewis > > ------------------------------------------------------------------------------ > Special Offer -- Download ArcSight Logger for FREE! > Finally, a world-class log management solution at an even better > price-free! And you'll get a free "Love Thy Logs" t-shirt when you > download Logger. Secure your free ArcSight Logger TODAY! > http://p.sf.net/sfu/arcsisghtdev2dev > _______________________________________________ > Rapideuphoria-develop mailing list > Rap...@li... > https://lists.sourceforge.net/lists/listinfo/rapideuphoria-develop -- Infinite complexity begets infinite beauty. Infinite precision begets infinite perfection. |
Thanks for helping keep SourceForge clean.
X