1. named array
- Posted by TheresNoTime Sep 02, 2013
- 2375 views
I need a structure similar to map. But standard Euphoria's maps does not suit me because of side effects. Advise how to do something like the symbols in Ruby or atoms in Erlang.
2. Re: named array
- Posted by BRyan Sep 02, 2013
- 2334 views
I need a structure similar to map. But standard Euphoria's maps does not suit me because of side effects. Advise how to do something like the symbols in Ruby or atoms in Erlang.
Because this forum is not a Ruby or Erlang forum; you will have to describe what you are trying to accomplish in Euphoria.
If you are trying to use maps a developer maybe able to help you.
You can not just say Euphoria's maps don't suit me because of side effects and not explain what you mean by that statement.
3. Re: named array
- Posted by TheresNoTime Sep 02, 2013
- 2301 views
Because this forum is not a Ruby or Erlang forum; you will have to describe what you are trying to accomplish in Euphoria.
Rubinish way: object = { :x => 100, :y => -200, :z => 300 } puts object[ :z ]
Erlanger way: Object = [ {x, 100}, {y, -200}, {z, 300} ]
In both cases x, y and z are not strings or numbers. It is special symbols. Internally it is numbers, but it dosn't matter. Practically it is "names".
Euphoric (the most ugly and inflexible) way:
enum X, Y, Z -- I need to name coordinates externally (in public? not very useful) sequence Object = {0, 0, 0} -- I can't say Object = {}, because sequences not able to auto-expand Object[X] = 100 Object[Y] = -200 Object[Z] = 300 puts(1, Object[Z])
4. Re: named array
- Posted by andi49 Sep 02, 2013
- 2257 views
Hi
I'am not sure if my english is good enough, but i will try to explain somethings. If someone knows it better i will be happy if he/she helps with this.
What you do in ruby is very different to what you do in Euphoria. In Ruby you give an 'Object a Name' this name is only valid in the context of the object.
object = { :x => 100, :y => -200, :z => 300 } puts object[ :z ] object1= { :z => 100, :y => -200, :x => 300 } puts object1[ :z ]If you try this, you will see that :z is different.
In Euphoria you declare a constant with enum, the 'Z' will always be the same in whatever context you use it. In the case below 'Z' is 3
You can replace every 'Z' with a '3' and the program also will work.
include std/console.e -- for any_key() enum X, Y, Z -- I need to name coordinates externally (in public? not very useful) sequence Object = {0, 0, 0} -- I can't say Object = {}, because sequences not able to auto-expand Object[X] = 100 Object[Y] = -200 Object[Z] = 300 puts(1, sprintf("%d",Object[Z])&"\n") sequence o2= {100,-200,300} puts(1, sprintf("%d",o2[Z])&"\n") sequence o3={} o3 &= 100 o3 &= -200 o3 &= 300 puts(1, sprintf("%d",o3[Z])&"\n") sequence o4={} o4=append(o4,Object) o4=append(o4,o2) o4=append(o4,o3) puts(1, sprintf("%d",o4[X][Y])&"\n") print (1,o4) puts(1,"\n") sequence o5={} for i = 1 to Z do o5=append(o5,o4) end for puts(1, sprintf("%d",o5[X][Y][Z])&"\n") print (1,o5) puts(1,"\n") any_key()
What i try to say is, you are comparing different Programming paradigm, this will not really work.
From the Programming paradigm, you maybe better compare Euphoria to 'C' or 'Pascal' not to an OO Language (if I'am wrong feel free to correct me).
Andreas
5. Re: named array
- Posted by BRyan Sep 02, 2013
- 2273 views
Does this help ?
This only uses 3 rows and the columns expand for as long as you need too.
You can use Object = repeat{{},50) or what ever size you want for rows
-- test.exw file constant X=1, Y=2, Z=3 object Object Object = {{},{},{}} -- first Object[X] = append(Object[X],100) Object[Y] = append(Object[Y],-200) Object[Z] = append(Object[Z],"test Z") -- second Object[X] = append(Object[X],"abcd") Object[Y] = append(Object[Y],-2000) Object[Z] = append(Object[Z],7077) procedure put_out(object o) if atom(o) then printf(1,"%d\n",{o} ) else printf(1,"%s\n",{o} ) end if end procedure put_out(Object[Y][1]) put_out(Object[X][1]) put_out(Object[Z][1]) put_out(Object[Y][2]) put_out(Object[X][2]) put_out(Object[Z][2]) if getc(0) then -- pause end if
6. Re: named array
- Posted by DerekParnell (admin) Sep 02, 2013
- 2228 views
I need a structure similar to map. But standard Euphoria's maps does not suit me because of side effects. Advise how to do something like the symbols ...
What 'side effects' are a concern to you? Using the map library it's simply ...
include std/map.e map Object = map:new() map:put(Object, 'X') = 100 map:put(Object, 'Y') = -200 map:put(Object, 'Z') = 300 puts(1, map:get(Object, 'Z'))
Or if the 'ugliness' of showing all the detailed assignments is too much for you ...
Create a map helper library such as ...
include std/map.e function mapset(sequence vals) object o o = map:new() for i = 1 to length(vals) do map:put(o, vals[i][1], vals[i][2]) end for return o end function function mapget(object o, object k) return map:get(o,k) end function
Then use it to emulate for favourite slow interpreter, such as Erlang or Ruby ...
include maphelp.e object Object = mapset( {{'X',100}, {'Y',-200}, {'Z',300}}) puts(1, mapget(Object, 'Z'))
7. Re: named array
- Posted by TheresNoTime Sep 03, 2013
- 2213 views
Hi
I'am not sure if my english is good enough, but i will try to explain somethings. If someone knows it better i will be happy if he/she helps with this.
What you do in ruby is very different to what you do in Euphoria. In Ruby you give an 'Object a Name' this name is only valid in the context of the object.
object = { :x => 100, :y => -200, :z => 300 } puts object[ :z ] object1= { :z => 100, :y => -200, :x => 300 } puts object1[ :z ]If you try this, you will see that :z is different.
It is not :z, it is value of hash, associated with :z. Both :z are the same objects. http://ideone.com/zBrG6e
8. Re: named array
- Posted by TheresNoTime Sep 03, 2013
- 2198 views
You can not just say Euphoria's maps don't suit me because of side effects and not explain what you mean by that statement.
A side effect is that the function is changing something outside of themselves. Functions without side effects named "pure functions". Sometimes side effects are necessary, because the display and the hard drive is also part of the outside world. However, it should by all means avoid impurity, if possible. When I'm going to use the maps, I can not write a pure function. Example:
include std/map.e include std/math.e map JohnSmith = map:new() map:put(JohnSmith, "Expenses", {1000, 2000, 3000, 4000}) function getSumExpenses(map Client) sequence Expenses = map:get(Client, "Expenses") return sum(Expenses) end function function getHistory(map Client, integer Months) sequence Expenses = map:get(Client, "Expenses") return head(Expenses, Months) end function function getSumHistoryExpenses(map Client, integer Months) map:put(Client, "Expenses", getHistory(Client, Months)) return getSumExpenses(Client) end function puts(1, "Sum of Expenses from January to March = ") print(1, getSumHistoryExpenses(JohnSmith, 3)) puts(1, "\nAll expenses, must be present up to April = ") print(1, map:get(JohnSmith, "Expenses")) puts(1, "\nFAIL!!! Map has changed forever, even though we changed it inside the function.")
9. Re: named array
- Posted by DerekParnell (admin) Sep 03, 2013
- 2174 views
A side effect is that the function is changing something outside of themselves. Functions without side effects named "pure functions". ... However, it should by all means avoid impurity, if possible. When I'm going to use the maps, I can not write a pure function.
I understand the term 'side effect' in relationship to functional programming and I know what 'pure' functions are. Euphoria is a Procedural Language so if you need to use a Functional Language, you would be better off with Erlang, Haskell, F#, Lisp, OCaml, etc.
It's no good complaining about impurity while using a procedural language paradigm.
On the other hand, you can write pure functions in Euphoria, including map-like structures, but the work involved would probably be counter-productive.
10. Re: named array
- Posted by TheresNoTime Sep 03, 2013
- 2263 views
Or if the 'ugliness' of showing all the detailed assignments is too much for you ...
Create a map helper library such as ...
Very nice idea. I tried to do something similar, but with the sequences. It turned out well, I'm ALMOST satisfied. Today I made the feature even closer to the way of Ruby. It turned out that Ruby keeps the symbols (I remind you that a symbol in Ruby is something like a key of the map in Euphoria) within a single table, shared by entire program. This can cause problems when the table is full. However, I find it hard to imagine a scenario where this happens. If the symbols are generated in some way, this is extremely bad programming style. I tried to do something similar to symbols possible. I hope it will be helpful not only to me. Мemory usage isn't effective, but it is the price paid for the convenience. I hope such "rubinish" thing will help someone else.
narr.e
include std/map.e map Symbols = map:new() integer Index = 0 function nextIndex() Index += 1 return Index end function export function new() return repeat(0, Index) end function export function get(sequence Narr, sequence Symbol) return Narr[map:get(Symbols, Symbol)] end function export function put(sequence Narr, sequence Symbol, object Value) integer Index = map:get(Symbols, Symbol) if Index = 0 then Index = nextIndex() map:put(Symbols, Symbol, Index) end if if length(Narr) < Index then Narr &= repeat(0, Index - length(Narr)) end if Narr[Index] = Value return Narr end function
t_narr.e
include std/unittest.e include narr.e as narr sequence Narr1 = narr:new() Narr1 = narr:put(Narr1, "X", 100) Narr1 = narr:put(Narr1, "Y", -200) Narr1 = narr:put(Narr1, "Z", 300) test_equal("", 100, narr:get(Narr1, "X")) test_equal("", -200, narr:get(Narr1, "Y")) test_equal("", 300, narr:get(Narr1, "Z")) Narr1 = narr:put(Narr1, "X", 1000) Narr1 = narr:put(Narr1, "Y", -2000) Narr1 = narr:put(Narr1, "Z", 3000) test_equal("", 1000, narr:get(Narr1, "X")) test_equal("", -2000, narr:get(Narr1, "Y")) test_equal("", 3000, narr:get(Narr1, "Z")) sequence Narr2 = narr:new() Narr2 = narr:put(Narr2, "Velocity", 543.902) Narr2 = narr:put(Narr2, "X", 0.1) Narr2 = narr:put(Narr2, "Y", -0.2) Narr2 = narr:put(Narr2, "Z", 0.3) Narr2 = narr:put(Narr2, "Name", "Bullet") Narr2 = narr:put(Narr2, "XYZ-1", {narr:get(Narr1, "X"), narr:get(Narr1, "Y"), narr:get(Narr1, "Z")}) test_equal("", 0.1, narr:get(Narr2, "X")) test_equal("", -0.2, narr:get(Narr2, "Y")) test_equal("", 0.3, narr:get(Narr2, "Z")) test_equal("", "Bullet", narr:get(Narr2, "Name")) test_equal("", 543.902, narr:get(Narr2, "Velocity")) test_equal("", {1000, -2000, 3000}, narr:get(Narr2, "XYZ-1"))
Please give advice on how to improve ways to use narrs. I mean string "include narr.e as narr". Why I needn't use "as", when including "map.e"? Second question: How to implement calling of narr:put without assignment? For example: Narr = put(Narr, "Name", "Joe"). When I using maps, I needn't assignment.
11. Re: named array
- Posted by mattlewis (admin) Sep 03, 2013
- 2245 views
Please give advice on how to improve ways to use narrs. I mean string "include narr.e as narr". Why I needn't use "as", when including "map.e"?
To me, I don't see how this really adds any value, because it seems like you've just added a simple redirection layer on top of the normal map interface. So I would dump it and just use a regular map instead of a narr.
At the top of the file, add:
namespace narr
That's the way to add a default namespace.
Second question: How to implement calling of narr:put without assignment? For example: Narr = put(Narr, "Name", "Joe"). When I using maps, I needn't assignment.
std/map.e uses std/eumem.e, which provides a pseudo memory area. These are like pointers which are really indices into a sequence. Map data is stored there. By default, this memory is automatically cleaned up when its reference count drops to zero.
Matt
12. Re: named array
- Posted by TheresNoTime Sep 03, 2013
- 2188 views
I understand the term 'side effect' in relationship to functional programming and I know what 'pure' functions are. Euphoria is a Procedural Language so if you need to use a Functional Language, you would be better off with Erlang, Haskell, F#, Lisp, OCaml, etc.
I love Euphoria. It is very easy and convenient. All of these languages have too little of procedural for my taste. However, I'm interested in other languages, because it broadens the mind. If I had not watched a few video lectures on Ruby and Erlang, I would not be able to solve my problem on Euphoria.
It's no good complaining about impurity while using a procedural language paradigm.
You are not quite right. It is possible to program procedurally in a functional language, it is possible to program functionally in a procedural language. For example, I was doing something similar to the memoization on Euphoria. Choice of language - is the choice of balance. If I can easily realize code, that I need often, I can not accept the fact that some of the rarely required capabilities are implemented difficult (wraps, crutches, external libraries).
Have you heard about the law of 80-10-10? If I am satisfied with 80, the foolish go to another language, because it has 10. Yes, it does have the 10, but it has its own 80, which are unusual to me. If I need the first 10, I think of a crutch. If I need a second 10, then I'll use C++ via the wrapper.
On the other hand, you can write pure functions in Euphoria, including map-like structures, but the work involved would probably be counter-productive.
I hope, Euphoria withstand this load. My program is not very complicated and does not handle huge amounts of data. In addition, they occasionally (quite often) become unnecessary and should be eaten up by the garbage collector.
13. Re: named array
- Posted by TheresNoTime Sep 03, 2013
- 2170 views
To me, I don't see how this really adds any value, because it seems like you've just added a simple redirection layer on top of the normal map interface. So I would dump it and just use a regular map instead of a narr.
You completely misunderstood what I was trying to do. Map here is only the custodian of symbols. Theoretically, it can be replaced by a sequence or constants (it is the original version with the "enum"). This does not wrap around the map, and a wrap around sequences. At first I wanted to do this:
sequence Person = { {"first_name", "last_name", "income"}, {"James", "Bond", 1_000_000} } sequence FirstName = Person[2][find("first_name", Person[1])] sequence LastName = Person[2][find("last_name", Person[1])] integer Income = Person[2][find("income", Person[1])] Person[1] = append(Person[1], "targets") Person[2] = append(Person[2], {"Drax Industries", "OCTOPUS", "Scum"})
I wrote the corresponding functions, but I'm annoyed by some nuances. Firstly, "find" is ineffective. You can improve its efficiency by streamlining the keys in ascending order. Getting is easy. However, the procedure for adding new values will become less apparent. Secondly, there is no sense to store the keys in each sequence, if the keys are the same (or a plurality of keys intersect). For example, we create two types of narrs: Citizen and Superhero.
Citizen = narr:new({ "first_name = John", -- such kind of syntax not realized yet (TODO) "second_name = Smith", "task = buy milk"}) Superhero = narr:new({ "first_name = Hedgehogman", "task = save world"})
Internally, it will look like:
-- map of indexes may contains "first_name" = 1, "second_name" = 2, "task" = 3 (order may be other, but numbers from 1 to 3) Citizen = {"John", "Smith", "buy milk"} Superhero = {"Hedgehogman", 0, "save world"} -- yes, the second element is not used, but it is done for uniformity and speed.
14. Re: named array
- Posted by mattlewis (admin) Sep 03, 2013
- 2150 views
To me, I don't see how this really adds any value, because it seems like you've just added a simple redirection layer on top of the normal map interface. So I would dump it and just use a regular map instead of a narr.
You completely misunderstood what I was trying to do. Map here is only the custodian of symbols. Theoretically, it can be replaced by a sequence or constants (it is the original version with the "enum"). This does not wrap around the map, and a wrap around sequences.
Then I would agree that I don't understand the point. I updated the code you posted:
include std/unittest.e include std/map.e include narr.e as narr sequence Narr1 = narr:new() map map1 = map:new() Narr1 = narr:put(Narr1, "X", 100) Narr1 = narr:put(Narr1, "Y", -200) Narr1 = narr:put(Narr1, "Z", 300) map:put( map1, "X", 100 ) map:put( map1, "Y", -200 ) map:put( map1, "Z", 300 ) test_equal("", 100, narr:get(Narr1, "X")) test_equal("", -200, narr:get(Narr1, "Y")) test_equal("", 300, narr:get(Narr1, "Z")) test_equal("", 100, map:get(map1, "X")) test_equal("", -200, map:get(map1, "Y")) test_equal("", 300, map:get(map1, "Z")) Narr1 = narr:put(Narr1, "X", 1000) Narr1 = narr:put(Narr1, "Y", -2000) Narr1 = narr:put(Narr1, "Z", 3000) map:put( map1, "X", 1000 ) map:put( map1, "Y", -2000 ) map:put( map1, "Z", 3000 ) test_equal("", 1000, narr:get(Narr1, "X")) test_equal("", -2000, narr:get(Narr1, "Y")) test_equal("", 3000, narr:get(Narr1, "Z")) test_equal("", 1000, map:get(map1, "X")) test_equal("", -2000, map:get(map1, "Y")) test_equal("", 3000, map:get(map1, "Z")) sequence Narr2 = narr:new() map map2 = map:new() Narr2 = narr:put(Narr2, "Velocity", 543.902) Narr2 = narr:put(Narr2, "X", 0.1) Narr2 = narr:put(Narr2, "Y", -0.2) Narr2 = narr:put(Narr2, "Z", 0.3) Narr2 = narr:put(Narr2, "Name", "Bullet") Narr2 = narr:put(Narr2, "XYZ-1", {narr:get(Narr1, "X"), narr:get(Narr1, "Y"), narr:get(Narr1, "Z")}) map:put(map2, "Velocity", 543.902) map:put(map2, "X", 0.1) map:put(map2, "Y", -0.2) map:put(map2, "Z", 0.3) map:put(map2, "Name", "Bullet") map:put(map2, "XYZ-1", {map:get(map1, "X"), map:get(map1, "Y"), map:get(map1, "Z")}) test_equal("", 0.1, narr:get(Narr2, "X")) test_equal("", -0.2, narr:get(Narr2, "Y")) test_equal("", 0.3, narr:get(Narr2, "Z")) test_equal("", "Bullet", narr:get(Narr2, "Name")) test_equal("", 543.902, narr:get(Narr2, "Velocity")) test_equal("", {1000, -2000, 3000}, narr:get(Narr2, "XYZ-1")) test_equal("", 0.1, map:get(map2, "X")) test_equal("", -0.2, map:get(map2, "Y")) test_equal("", 0.3, map:get(map2, "Z")) test_equal("", "Bullet", map:get(map2, "Name")) test_equal("", 543.902, map:get(map2, "Velocity")) test_equal("", {1000, -2000, 3000}, map:get(map2, "XYZ-1"))
All I did was replace the narr stuff with map stuff. Note that you can also nest maps, and store and retrieve the data with a single call. Is there a reason you can't simply store the information inside of maps?
Internally, it will look like:
-- map of indexes may contains "first_name" = 1, "second_name" = 2, "task" = 3 (order may be other, but numbers from 1 to 3) Citizen = {"John", "Smith", "buy milk"} Superhero = {"Hedgehogman", 0, "save world"} -- yes, the second element is not used, but it is done for uniformity and speed.
I would say that you're probably better off just coming up with a key, storing the person's structured data as a sequence in a map and using an enum to access the various parts:
enum CITIZEN_FIRST, CITIZEN_LAST, CITIZEN_INCOME enum SUPERHERO_FIRST, SUPERHERO_LAST, SUPERHERO_TASK
Matt
15. Re: named array
- Posted by TheresNoTime Sep 03, 2013
- 2143 views
Then I would agree that I don't understand the point. I updated the code you posted:
skipped
All I did was replace the narr stuff with map stuff. Note that you can also nest maps, and store and retrieve the data with a single call. Is there a reason you can't simply store the information inside of maps?
Yes, two reasons: 1. It is senseless to store same keys two times. 2. I needn't side effects.
I would say that you're probably better off just coming up with a key, storing the person's structured data as a sequence in a map and using an enum to access the various parts:
enum CITIZEN_FIRST, CITIZEN_LAST, CITIZEN_INCOME enum SUPERHERO_FIRST, SUPERHERO_LAST, SUPERHERO_TASK
Matt
Add a few more types of people (BOSS, CRIMINAL, BEAUTY, ASSISTANT). Each of them has three HUNDREDS of properties. Most of the properties are common to all. You may be hard-working Chinese. I'm lazy Russian. I want to quickly write a program to get a drink of vodka and go ride on a tank drawn by bears.
16. Re: named array
- Posted by SDPringle Sep 03, 2013
- 2137 views
enum CITIZEN_FIRST, CITIZEN_LAST, CITIZEN_INCOME enum SUPERHERO_FIRST, SUPERHERO_LAST, SUPERHERO_TASK
This kind of thing makes the accessing much faster than using find with a string. It is easy to write in EUPHORIA:
sequence stephen_hawking = { "Stephen", "Hawking", 120_000 }
The problem is the code requires the coder to know how the structure members are ordered. The above line breaks 'data encapsulation'. Really you want to combine these with a function struct_assign:
sequence stephen_hawking = struct_assign({ CITIZEN_FIRST, "Stephen", CITIZEN_LAST, "Hawking", CITIZEN_INCOME, 120_000 })
The implementation of struct_assign is an exercise for the reader. :) Remember to replace 'sequence' with your own user defined type to save you from blunders.
17. Re: named array
- Posted by mattlewis (admin) Sep 03, 2013
- 2143 views
Then I would agree that I don't understand the point. I updated the code you posted:
skipped
All I did was replace the narr stuff with map stuff. Note that you can also nest maps, and store and retrieve the data with a single call. Is there a reason you can't simply store the information inside of maps?
Yes, two reasons: 1. It is senseless to store same keys two times.
2. I needn't side effects.
It's not senseless if it makes life easier. Though I must admit that I don't see how using a map would be storing the key twice.
You're not getting more side effects with your narr implementation (OK, I guess you could manage it doing things completely differently). Anyways, with maps, you're just passing a reference to your data and manipulating it directly instead of passing and returning by value. Doing it by reference is likely to be faster, especially as the amount of data grows. The map library goes to a bit of effort to avoid unnecessary copies on write.
Add a few more types of people (BOSS, CRIMINAL, BEAUTY, ASSISTANT). Each of them has three HUNDREDS of properties. Most of the properties are common to all. You may be hard-working Chinese. I'm lazy Russian. I want to quickly write a program to get a drink of vodka and go ride on a tank drawn by bears.
Nah...I'm a lazy American. I do what's easy and then if there's some performance problem, I fix that. If you aren't having to deal with a lot of data (I believe this is what you said) then why worry about duplicating some things? Just use nested maps:
map:put( people, { person_key, "first name", "John"} ) map:put( people, { person_key, "last name", "Doe"} ) map:put( people, { person_key, "income", 50_000 } ) -- ...etc... map John_Doe = map:get( people, person_key ) map:get( John_Doe, "first name" )
Of course, you could wrap that and assign constants to stuff like "first name" to make it easy and pretty.
Matt
18. Re: named array
- Posted by BRyan Sep 03, 2013
- 2126 views
Maybe you should rethink your approach.
It sounds to me that you really want to create and use a generic structure that describes the features of each avatar.
These structures can then be stored in a database or map.
19. Re: named array
- Posted by TheresNoTime Sep 03, 2013
- 2124 views
The implementation of struct_assign is an exercise for the reader. :)
I think this is what I came up with. Even more convenient and flexible.
Remember to replace 'sequence' with your own user defined type to save you from blunders.
How to do so? Please correct my code.
20. Re: named array
- Posted by TheresNoTime Sep 03, 2013
- 2126 views
It's not senseless if it makes life easier.
I have repeatedly tried to explain that this approach made my life more difficult. That's why I came up with a "narr" because it makes my life easier.
Though I must admit that I don't see how using a map would be storing the key twice.
Two maps.
You're not getting more side effects with your narr implementation (OK, I guess you could manage it doing things completely differently). Anyways, with maps, you're just passing a reference to your data and manipulating it directly instead of passing and returning by value. Doing it by reference is likely to be faster, especially as the amount of data grows. The map library goes to a bit of effort to avoid unnecessary copies on write.
So, I have to take care of that to backup data to be temporarily changed, and then must be restored. When I use a narr, I can just keep the previous state!
Person = narr:new({"citizenship = USA", "actions = law-abiding", "task = Consume!"}) ClarkKent = narr:put(Person, {"name = Clark Kent", "apparel = suit", "sweetheart = Lana Lane"}) Superman = narr:put(ClarkKent, {"name = Superman", "apparel = tights"}) if equal(narr:get(Person, "task"), "Save the free world!") then Person = Superman else Person = ClarkKent end if
Nah...I'm a lazy American. I do what's easy and then if there's some performance problem, I fix that. If you aren't having to deal with a lot of data (I believe this is what you said) then why worry about duplicating some things?
I don't warry about that. The fact that the keys are not duplicated in the narrs was not my intention. This is an additional effect. I wanted to get something like the symbols of Ruby, because they are simple and easy. You do not want to say that Ruby and Erlang (may be other) created by idiots?
Just use nested maps:
I not only lazy but also stupid a bit. I do not like to use a nested structures, where possible to implement primitive one-dimensional array/list etc.
21. Re: named array
- Posted by mattlewis (admin) Sep 03, 2013
- 2111 views
It's not senseless if it makes life easier.
I have repeatedly tried to explain that this approach made my life more difficult. That's why I came up with a "narr" because it makes my life easier.
I will just have to take your word for it.
So, I have to take care of that to backup data to be temporarily changed, and then must be restored. When I use a narr, I can just keep the previous state!
That's...true, I guess, though we have map:copy, which I suppose would take more effort in some scenarios.
Nah...I'm a lazy American. I do what's easy and then if there's some performance problem, I fix that. If you aren't having to deal with a lot of data (I believe this is what you said) then why worry about duplicating some things?
I don't warry about that. The fact that the keys are not duplicated in the narrs was not my intention. This is an additional effect. I wanted to get something like the symbols of Ruby, because they are simple and easy. You do not want to say that Ruby and Erlang (may be other) created by idiots?
I don't really have an opinion on them. I just haven't been able to divine how what you're doing is an improvement over what you could do more easily (in euphoria) with maps.
Just use nested maps:
I not only lazy but also stupid a bit. I do not like to use a nested structures, where possible to implement primitive one-dimensional array/list etc.
Erm...ok. The nature of what you're doing is nested levels of access, just with slightly different semantics. I don't really know ruby, but I know it's based on perl, and the "symbols" syntax you're using looks a lot like perl hashes, which are basically what euphoria's maps are. I suspect that erlang's records are implemented similarly.
Matt
22. Re: named array
- Posted by useless_ Sep 03, 2013
- 2098 views
enum CITIZEN_FIRST, CITIZEN_LAST, CITIZEN_INCOME enum SUPERHERO_FIRST, SUPERHERO_LAST, SUPERHERO_TASK
This kind of thing makes the accessing much faster than using find with a string. It is easy to write in EUPHORIA:
sequence stephen_hawking = { "Stephen", "Hawking", 120_000 }
The problem is the code requires the coder to know how the structure members are ordered. The above line breaks 'data encapsulation'. Really you want to combine these with a function struct_assign:
sequence stephen_hawking = struct_assign({ CITIZEN_FIRST, "Stephen", CITIZEN_LAST, "Hawking", CITIZEN_INCOME, 120_000 })
The implementation of struct_assign is an exercise for the reader. :) Remember to replace 'sequence' with your own user defined type to save you from blunders.
Looks like an xml data table.
useless
PS: if what the OP wants is a free-form xml table, i wrote such an interface in Eu in a version of strtok: getxml(). I removed it later because of criticism that it wasn't needed and wasn't the "Euphoria way".
23. Re: named array
- Posted by TheresNoTime Sep 04, 2013
- 2031 views
It might be easier if I explain why I conceived the idea of any structure. I'm tired of writing a lot of function parameters. In theory, I can do without any structure at all, even without the sequence.
function getSomeCalculations(sequence x, sequence y, atom velocity, integer index, sequence etc) return bla bla bla end function
The disadvantage is that I have to remember what parameters to pass and in what order. I have tried a variety of options, including all the ones that you advised. And only then, after much trial and error, I came up with narr. I really convenient to think in terms of "state of the system." I send to a function the state of system, and get the data. At first it may seem that we should return the new state of the system, but it was uncomfortable. It is much better to return the data. What to do with them will decide the function which data were requested. Maps are not formed me that it is necessary to take care of data backup. These two pieces of code equivalents.
function willAccident_Map(map State, atom Time) atom Velocity = map:get(State, "velocity") -- get velocity of system atom Acceleration = map:get(State, "acceleration") -- get acceleration of system atom NewVelocity = Velocity + Acceleration * Time -- velocity after "Time" passed map:put(State, "velocity", NewVelocity) -- put new velocity to SAME state boolean Accident = isAcccident(State) -- save answer map:put(State, "velocity", Velocity) -- don't forget to restore state of system!!! return Accident end function function willAccident_Narr(narr State, atom Time) atom Velocity = narr:get(State, "velocity") -- get velocity of system atom Acceleration = narr:get(State, "acceleration") -- get acceleration of system Velocity += Acceleration * Time -- no need to keep the old velocity! narr NewState = narr:put(State, "velocity", Velocity) -- because we can get new state return isAccident(NewState) -- no need to save answer end function
Shorter, cleaner, safer.
24. getxml()
- Posted by jimcbrown (admin) Sep 04, 2013
- 2036 views
PS: if what the OP wants is a free-form xml table, i wrote such an interface in Eu in a version of strtok: getxml(). I removed it later because of criticism that it wasn't needed and wasn't the "Euphoria way".
There are a few XML parsers in the archive. Perhaps one of these could be adapted for such a use. http://www.rapideuphoria.com/cgi-bin/asearch.exu?dos=on&win=on&lnx=on&gen=on&keywords=xml
It looks like getxml() is still around and available too: http://www.rapideuphoria.com/strtok-v2-1.zip
25. Re: named array
- Posted by jimcbrown (admin) Sep 04, 2013
- 2026 views
I really convenient to think in terms of "state of the system." I send to a function the state of system, and get the data. At first it may seem that we should return the new state of the system, but it was uncomfortable. It is much better to return the data. What to do with them will decide the function which data were requested. Maps are not formed me that it is necessary to take care of data backup. These two pieces of code equivalents.
Actually, these two are code equivalents.
function willAccident_Map(map State, atom Time) atom Velocity = map:get(State, "velocity") -- get velocity of system atom Acceleration = map:get(State, "acceleration") -- get acceleration of system Velocity += Acceleration * Time -- no need to keep the old velocity! map NewState = map:clone(State) -- get new state map:put(NewState, "velocity", Velocity) -- put new velocity to new state return isAccident(NewState) -- no need to save answer end function function willAccident_Narr(narr State, atom Time) atom Velocity = narr:get(State, "velocity") -- get velocity of system atom Acceleration = narr:get(State, "acceleration") -- get acceleration of system Velocity += Acceleration * Time -- no need to keep the old velocity! narr NewState = narr:put(State, "velocity", Velocity) -- because we can get new state return isAccident(NewState) -- no need to save answer end function
I could go further, and envision a new function to map that'd go even further.
function willAccident_Map(map State, atom Time) atom Velocity = map:get(State, "velocity") -- get velocity of system atom Acceleration = map:get(State, "acceleration") -- get acceleration of system Velocity += Acceleration * Time -- no need to keep the old velocity! map NewState = map:clone_and_put(State, "velocity", Velocity) -- because we can get new state return isAccident(NewState) -- no need to save answer end function
Shorter, cleaner, safer.
It seems to me what you want (in lieu of direct support of Erlang atom-like functionality in Eu) is an immutable version of maps - one in which every function that could modify a map would return the new map to you while leaving the original (and immutable) map unchanged.
26. Re: named array
- Posted by TheresNoTime Sep 04, 2013
- 1986 views
I could go further, and envision a new function to map that'd go even further.
function willAccident_Map(map State, atom Time) atom Velocity = map:get(State, "velocity") -- get velocity of system atom Acceleration = map:get(State, "acceleration") -- get acceleration of system Velocity += Acceleration * Time -- no need to keep the old velocity! map NewState = map:clone_and_put(State, "velocity", Velocity) -- because we can get new state return isAccident(NewState) -- no need to save answer end function
Yes, it is possible. But why? For what reason? Do you not see that either way - it's my way, but unnecessarily complicated. Your way of using maps plus a crutch to overcome their side effect. My method uses sequences because they initially do not have such effect. Yes, you will have one simple function, and I have three plus the map for keys "behind the scenes". However, if you look at the principle, not to it's implementation, my approach is simpler. It is better to have a new type of data than to remember that it is necessary to use a crutch for old type. Your variation of "willAccident" is shorter, but you just put some of my code into a separate function "clone_and_put". This is the same backup and restore (just disguised), but for the entire map! Pfff...
27. Re: named array
- Posted by jimcbrown (admin) Sep 04, 2013
- 1992 views
Yes, it is possible. But why? For what reason? Do you not see that either way - it's my way, but unnecessarily complicated.
Maps make use of eumem. Your library uses sequences (and a map...) directly. Otherwise, the two are identical. Aside from an explicit copy() call (which your library simply does implicitly), and the complexity inherent to the use of eumem (which is hidden from the map user due to data encapsulation) there is no additional complexity.
Your variation of "willAccident" is shorter, but you just put some of my code into a separate function "clone_and_put". This is the same backup and restore (just disguised), but for the entire map! Pfff...
Looking at it that way, the original map version (requiring a manual restore) is the most efficient. Both your library and my map version require a full (ableit shallow, as opposed to a deep) copy of the dictionary data structure to be made. In both cases this is just a sequence that is copied (as eumem is implemented as a big sequence) - but the original map version saves us that effort (at the cost of changing the original).
Keep in mind that map:clone() benefits from the COW nature of Euphoria sequences. So it's simply a shallow, rather than a deep, copy. For that reason, I say the two approaches (my map version and your library version) are on an equal footing.
Your way of using maps plus a crutch to overcome their side effect.
I was demonstrating that it was possible to use a mutable datatype without actually changing it. Thus, there are no side effects to overcome.
My method uses sequences because they initially do not have such effect.
But sequences are mutable!
Yes, you will have one simple function, and I have three plus the map for keys "behind the scenes".
Strictly speaking, it's not necessary to add even this single function, copy_and_put(), as I demonstrated in the earlier example...
However, if you look at the principle, not to it's implementation, my approach is simpler. It is better to have a new type of data than to remember that it is necessary to use a crutch for old type.
And we're back to the addition of an immutable map type. There are cases where an immutable type is valuable (as you don't trust the other function or library to avoid mutating your data structures), and other languages do follow this principle (having both a immutable String type and a mutable StringBuilder type). In many cases, it simply makes sense to have this distinction enforced by the language itself.
However, I should point out here that you have made a small fuss about the necessity of leaving the original object unchanged without providing any justification why this is necessary. You furthmore seem to be saying that your library implementation is superior to that of maps (or at least implying that this is the case) without really explaining why. Your efforts at explaining this all center on two factors: 1) Your library implements an immutable data structure. 2) Your library is simpler than the Euphoria map implementation.
I content that 1) your library merely implements an immutable map datatype. 2a) A naive or simple implemantation is not always best. (Simple algorithms can be slower than highly optimized ones, for example.) 2b) Your library uses Euphoria maps internally, so it's not really simpler anyways - the combined logic in its totality must be more complex, since any complete and total description of your library must include a description of the Euphoria implementation of maps and eumem. Perhaps your library is the one with a crutch, using maps internally to deal with keys instead of coming up with a more efficient implementation to handle them.
But this may be really getting off track, since you seem to have originally wanted something like Erlang's atoms. Those may be implemented by a big global map structure internally (to connect the string that represents the symbol with the integer that represents the hash that is used), but that's a hidden detail from the user of the language. In actuality, it appears as a entirely new class of datatype - not integer, or floating point, or string, or a class or structure or array composed of multiples of these, but a new kind of literal altogether.
28. Re: named array
- Posted by TheresNoTime Sep 04, 2013
- 2038 views
My method uses sequences because they initially do not have such effect.
But sequences are mutable!
Yes, of course, I can write
narr Person[1] = "James"
instead of
narr Person = put(Person, "name", "James")
if I absolutely sure, that key "name" = index 1 in that map. But it is dirty hack, that I'm not going to do. Otherwise, it is unclear why it was a fuss?
Theoretically, there is a much more efficient way. Write a preprocessor that looks for all the indexes and stores them in a list. For example, when it saw
abc = x[_A] + x[_B] + x[_C] -- underlining is used to indicate keys (that "symbols" in terms of Ruby)
then it creates file symbols.e, that contains
public enum _A, _B, _C public function new() return repeat(0, 3) -- because we have only 3 symbols end function
I just came to mind. Perhaps I will do so. Not because it's faster, but because it will take away a lot of repetitive lines
sequence Name = get(my_narr, "name") sequence Work = get(my_narr, "work")
The disadvantage is that it will lead to the need to monitor changes of consistency and make clones. But it will be much easier.
sequence NewState = State NewState[_VELOCITY] = NewVelocity return isAccident(NewState) -- State isn't changed, NewState is eaten by garbage collector
However, I should point out here that you have made a small fuss about the necessity of leaving the original object unchanged without providing any justification why this is necessary. You furthmore seem to be saying that your library implementation is superior to that of maps (or at least implying that this is the case) without really explaining why. Your efforts at explaining this all center on two factors: 1) Your library implements an immutable data structure. 2) Your library is simpler than the Euphoria map implementation.
Hmmm... No. I did not say so. In the middle of the conversation mentioned structure "map of maps". My narr is simpler than that.
I content that 1) your library merely implements an immutable map datatype.
If you say about one narr - yes. If you say about narrs - no. My narrs is more effective than set of maps, because keys stored in single table. I spied this principle in Ruby. I know that this is not in Python. And I'm not even sure that the atoms of the Erlang are analogous to Ruby's symbols.
2a) A naive or simple implemantation is not always best.
Of course. I'm not going to make a production version. If the Ruby I spied the principle of symbols, the Erlang I spied principle "Let It Crush".
Your library uses Euphoria maps internally, so it's not really simpler anyways - the combined logic in its totality must be more complex, since any complete and total description of your library must include a description of the Euphoria implementation of maps and eumem. Perhaps your library is the one with a crutch, using maps internally to deal with keys instead of coming up with a more efficient implementation to handle them.
Oh no, again... Map of keys absolutely invisible. narr is regular sequence. About effectivness. As far as I guess, fetching some stuff form sequence is almost instantaneous operation. It is pointer internally, eh? So, narr is almost equal to map, because it do two actions only: get index from map by key, get value from sequence by index.
29. Re: named array
- Posted by jimcbrown (admin) Sep 04, 2013
- 2022 views
Yes, of course, I can write
narr Person[1] = "James"
instead of
narr Person = put(Person, "name", "James")
if I absolutely sure, that key "name" = index 1 in that map. But it is dirty hack, that I'm not going to do. Otherwise, it is unclear why it was a fuss?
The disadvantage is that it will lead to the need to monitor changes of consistency and make clones. But it will be much easier.
Your library has the same disadvantage of the necessity of making clones, whether you realize it or not.
However, I should point out here that you have made a small fuss about the necessity of leaving the original object unchanged without providing any justification why this is necessary. You furthmore seem to be saying that your library implementation is superior to that of maps (or at least implying that this is the case) without really explaining why. Your efforts at explaining this all center on two factors: 1) Your library implements an immutable data structure. 2) Your library is simpler than the Euphoria map implementation.
Hmmm... No. I did not say so. In the middle of the conversation mentioned structure "map of maps". My narr is simpler than that.
Ah, I see. I misunderstood. Agreed, in that case.
I content that 1) your library merely implements an immutable map datatype.
If you say about one narr - yes. If you say about narrs - no. My narrs is more effective than set of maps, because keys stored in single table. I spied this principle in Ruby. I know that this is not in Python.
Any immutable map type can be implemented this way (and it makes sense to do so because it is more efficient). Thus, I believe this remains true even in the plural.
Your library uses Euphoria maps internally, so it's not really simpler anyways - the combined logic in its totality must be more complex, since any complete and total description of your library must include a description of the Euphoria implementation of maps and eumem. Perhaps your library is the one with a crutch, using maps internally to deal with keys instead of coming up with a more efficient implementation to handle them.
Oh no, again... Map of keys absolutely invisible. narr is regular sequence.
Agreed. The user of your library has no need to know that a map of keys is used internally in the implementation.
About effectivness. As far as I guess, fetching some stuff form sequence is almost instantaneous operation. It is pointer internally, eh?
Yes. The Euphoria implementation of maps benefits from this as well.
So, narr is almost equal to map, because it do two actions only: get index from map by key, get value from sequence by index.
Agreed - a mutable map type (like the one in Euphoria) has a lot more functionality.
Theoretically, there is a much more efficient way. Write a preprocessor that looks for all the indexes and stores them in a list. For example, when it saw
abc = x[_A] + x[_B] + x[_C] -- underlining is used to indicate keys (that "symbols" in terms of Ruby)
then it creates file symbols.e, that contains
public enum _A, _B, _C public function new() return repeat(0, 3) -- because we have only 3 symbols end function
I just came to mind. Perhaps I will do so. Not because it's faster, but because it will take away a lot of repetitive lines
sequence Name = get(my_narr, "name") sequence Work = get(my_narr, "work")
sequence NewState = State NewState[_VELOCITY] = NewVelocity return isAccident(NewState) -- State isn't changed, NewState is eaten by garbage collector
And I'm not even sure that the atoms of the Erlang are analogous to Ruby's symbols.
If I understand correctly, your preprocessor example would be, though. I agree that, for stylistic reasons, that would be the better approach. Adding a new literal symbol type should be done by adding a new literal symbol type, with syntax sugar and all, not by faking it with arrays and strings or maps.
30. Re: named array
- Posted by TheresNoTime Sep 05, 2013
- 1901 views
The disadvantage is that it will lead to the need to monitor changes of consistency and make clones. But it will be much easier.
Your library has the same disadvantage of the necessity of making clones, whether you realize it or not.
I was talking about something else. I do not care what goes on behind the scenes. The problem is that if you use the maps, you will have to do clones manually. My approach - always make clones, even if they are not needed. This is inefficient, but it can be optimized. Here's how it might look from the outside
narr Local -- Auxiliary variable, to allude it every time when you call a function put() or get(). function playWithNarr(narr External) Local = External put("velocity:152.35 coordinates:458,490,3047 name:Ball") -- equivalent to tree puts: atom, sequence of integers and sequence "Ball"! sequence Data = get("acceleration color") -- equivalent to two gets! But I got carried away. This particular improvement doesn't make any sense. :) -- Ahh! But now would be a very useful thing! Universal function, that able to recognize, what I want: put or get. Local = x("velocity:152.35 coordinates:458,490,3047 name:Ball") Acceleration = x("acceleration")
I'm starting to wonder ... May be, simply use the language, which already has something like this? For example, Ruby? Python has not something similar to Ruby's symbols. Python's dict is equivalent of Euphoria's map, but Python has very useful syntax sugar for it. So, it seems equivalent to Ruby's symbols.
Agreed - a mutable map type (like the one in Euphoria) has a lot more functionality.
In my particular case, this functionality is not only superfluous but also harmful.
If I understand correctly, your preprocessor example would be, though. I agree that, for stylistic reasons, that would be the better approach. Adding a new literal symbol type should be done by adding a new literal symbol type, with syntax sugar and all, not by faking it with arrays and strings or maps.
This is my dream. Do you agree, that Euphoria's syntax is overloaded a bit? It would be great to create something, that would be the same for Euphoria, what was CoffeeScript for JavaScript. I propose to call it Kaif. This is an Arabic word meaning pleasant, relaxed pastime with coffee and tobacco. :)
31. Re: named array
- Posted by jimcbrown (admin) Sep 05, 2013
- 1873 views
My approach - always make clones, even if they are not needed.
Which works fine with Euphoria maps as well.
Agreed - a mutable map type (like the one in Euphoria) has a lot more functionality.
In my particular case, this functionality is not only superfluous but also harmful.
Based on the needs that you have described so far, I disagree. It appears to be harmless. In fact, you contradict yourself on this point - Python's Dict type is also mutable (and should therefore suffer from the same disadvantages), yet you do not treat this as harmful.
If I understand correctly, your preprocessor example would be, though. I agree that, for stylistic reasons, that would be the better approach. Adding a new literal symbol type should be done by adding a new literal symbol type, with syntax sugar and all, not by faking it with arrays and strings or maps.
This is my dream.
Actually, I believe something like this has already been implemented in the alternative_literals branch: http://openeuphoria.org/ticket/657.wc
32. Re: named array
- Posted by TheresNoTime Sep 05, 2013
- 1928 views
My approach - always make clones, even if they are not needed.
Which works fine with Euphoria maps as well.
How? Replace standart "put" with "clone_and_put"?
In my particular case, this functionality is not only superfluous but also harmful.
Based on the needs that you have described so far, I disagree. It appears to be harmless. In fact, you contradict yourself on this point - Python's Dict type is also mutable (and should therefore suffer from the same disadvantages), yet you do not treat this as harmful.
We often do not understand each other because they are talking about several things at once. Security - this is one problem, and convenience - the second. In other languages (Ruby and Python) I will have to decide what is more important. In the Euphoria I have no choice because there is no security, no convenience (in my understanding of these terms).
Actually, I believe something like this has already been implemented in the alternative_literals branch: http://openeuphoria.org/ticket/657.wc
Did not see anything like what I want. Perhaps I misunderstood something.
A Russian programmer told the following story. He is working in the United States with colleagues of different nationalities. Everyone is doing their part of the program. Once his "Russian" part brought down testing. Began to understand. It turned out that the problem is in the "Chinese" part. The Chinese came and looked, and immediately began to correct. Therefore, Russian programmer saw whole process. He was in shock. A Chinese man has opened its source code. Each function has the list of options in a few screens long. The most amazing thing is that he quickly found the desired function, add a parameter in the middle of a very long list, and ... everything started to happen!
But I started to get nervous because the list of options beyond a single line! Maybe I should apply to such a noodle code quieter? Eventually, computer is steel, unlike my nerves. :)
33. Re: named array
- Posted by jimcbrown (admin) Sep 05, 2013
- 1871 views
My approach - always make clones, even if they are not needed.
Which works fine with Euphoria maps as well.
How? Replace standart "put" with "clone_and_put"?
In essence, yes.
In my particular case, this functionality is not only superfluous but also harmful.
Based on the needs that you have described so far, I disagree. It appears to be harmless. In fact, you contradict yourself on this point - Python's Dict type is also mutable (and should therefore suffer from the same disadvantages), yet you do not treat this as harmful.
We often do not understand each other because they are talking about several things at once. Security - this is one problem, and convenience - the second.
Fair enough. I can understand the need for immutability from a security perspective. I agree that Euphoria maps in this sense are not secure - your code may always do a clone() and keep things safe, but some other Euphoria 3rd party library could go in there and muck around with things behind your back. (Since your immutable map implementation uses Euphoria maps behind the scenes, it theoretically shares this vunerability, albiet in a lesser way.)
In other languages (Ruby and Python) I will have to decide what is more important. In the Euphoria I have no choice because there is no security, no convenience (in my understanding of these terms).
Convenience == syntax sugar? Since Euphoria has builtin support for preprocessors, I'll cheat here and say that this provides all the necessary syntax sugar.
I'm still puzzled by your statement that Euphoria lacks both choices, however. You've written a library that provides for your needs (security included), and have come up with a preprocessor design that provides you with the desired convenience. Thus it seems like you have the best of both worlds now, in Euphoria, through your own efforts.
Actually, I believe something like this has already been implemented in the alternative_literals branch: http://openeuphoria.org/ticket/657.wc
Did not see anything like what I want. Perhaps I misunderstood something.
The ticket is not the best description ... You'd need to get into the source code of the branch itself to really understand it, I think. Anyways, 4.1 is under a feature freeze right now, so even if this was a perfect 100% match for your needs, it'd still be a very long time before it made it into the mainstream Euphoria.
34. Re: named array
- Posted by TheresNoTime Sep 06, 2013
- 1826 views
In other languages (Ruby and Python) I will have to decide what is more important. In the Euphoria I have no choice because there is no security, no convenience (in my understanding of these terms).
Convenience == syntax sugar? Since Euphoria has builtin support for preprocessors, I'll cheat here and say that this provides all the necessary syntax sugar.
This information is extremely inspiring. Could you tell us how difficult it is to make sure that the following lines...
sequence x = {key1:value1 key2:value2} sequence y = {key1:value3 key3:value4} -- ...are automatically transformed into... sequence x = repeat(0, 3) x[1] = value1 x[2] = value2 sequence y = repeat(0, 3) y[1] = value3 y[3] = value4
I'm still puzzled by your statement that Euphoria lacks both choices, however. You've written a library that provides for your needs (security included), and have come up with a preprocessor design that provides you with the desired convenience. Thus it seems like you have the best of both worlds now, in Euphoria, through your own efforts.
I meant that those languages have such things right now. Obviously, any powerful language have self-improvement ability. Euphoria can be improved, but Ruby do not to improve, because it already has the symbols.
BTW, So far we have discussed these improvements, I wrote the program. Not all, but enough to not need such flexible instruments. It was necessary to me early on, because I did not know what parameters need to be stored, and which functions will modify the input data. But it could be done faster and easier.
35. Re: named array
- Posted by jimcbrown (admin) Sep 06, 2013
- 1763 views
This information is extremely inspiring. Could you tell us how difficult it is to make sure that the following lines...
sequence x = {key1:value1 key2:value2} sequence y = {key1:value3 key3:value4} -- ...are automatically transformed into... sequence x = repeat(0, 3) x[1] = value1 x[2] = value2 sequence y = repeat(0, 3) y[1] = value3 y[3] = value4
For a preprocessor itself written in Eu, probably an hour of coding and testing...
(I should point out that this appears to be different from the Ruby-Symbols equiv preprocessor that you previously proposed in this thread. You're moving the goalposts.)
I'm still puzzled by your statement that Euphoria lacks both choices, however. You've written a library that provides for your needs (security included), and have come up with a preprocessor design that provides you with the desired convenience. Thus it seems like you have the best of both worlds now, in Euphoria, through your own efforts.
I meant that those languages have such things right now. Obviously, any powerful language have self-improvement ability. Euphoria can be improved, but Ruby do not to improve, because it already has the symbols.
BTW, So far we have discussed these improvements, I wrote the program. Not all, but enough to not need such flexible instruments. It was necessary to me early on, because I did not know what parameters need to be stored, and which functions will modify the input data. But it could be done faster and easier.
Agreed - as I've explained before, what you've written doesn't seem to be a significant improvement on what Euphoria already has.
36. Re: named array
- Posted by jimcbrown (admin) Sep 06, 2013
- 1779 views
I content that 1) your library merely implements an immutable map datatype.
If you say about one narr - yes. If you say about narrs - no. My narrs is more effective than set of maps, because keys stored in single table. I spied this principle in Ruby. I know that this is not in Python.
Any immutable map type can be implemented this way (and it makes sense to do so because it is more efficient). Thus, I believe this remains true even in the plural.
I think I may have misunderstood this - now that I've taken a closer look, it appears that your library has one set of "global" keys that apply to every and all objects of your type, as opposed to using a big list of keys internally but only allowing keys associated with a specific immutable map to be used.
Since the list of keys are "global" and allowed to change (to be added to), an immutable map type won't work here.