1. named array

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.

new topic     » topic index » view message » categorize

2. Re: named array

TheresNoTime said...

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.

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

3. Re: named array

BRyan said...

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]) 
new topic     » goto parent     » topic index » view message » categorize

4. Re: named array

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

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

5. Re: named array

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 
new topic     » goto parent     » topic index » view message » categorize

6. Re: named array

TheresNoTime said...

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'))  
 
new topic     » goto parent     » topic index » view message » categorize

7. Re: named array

andi49 said...

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

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

8. Re: named array

BRyan said...

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.") 
new topic     » goto parent     » topic index » view message » categorize

9. Re: named array

TheresNoTime said...

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.

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

10. Re: named array

DerekParnell said...

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.

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

11. Re: named array

TheresNoTime said...

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. smile

At the top of the file, add:

namespace narr 

That's the way to add a default namespace.

TheresNoTime said...

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

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

12. Re: named array

DerekParnell said...

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.

said...

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.

said...

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.

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

13. Re: named array

mattlewis said...

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. smile

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. 
new topic     » goto parent     » topic index » view message » categorize

14. Re: named array

TheresNoTime said...
mattlewis said...

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. smile

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?

TheresNoTime said...

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

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

15. Re: named array

mattlewis said...

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.

TheresNoTime said...

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.

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

16. Re: named array

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.

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

17. Re: named array

TheresNoTime said...
mattlewis said...

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.

TheresNoTime said...

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

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

18. Re: named array

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.

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

19. Re: named array

SDPringle said...

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.

said...

Remember to replace 'sequence' with your own user defined type to save you from blunders.

How to do so? Please correct my code.

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

20. Re: named array

mattlewis said...

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.

said...

Though I must admit that I don't see how using a map would be storing the key twice.

Two maps.

said...

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 
said...

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?

said...

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.

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

21. Re: named array

TheresNoTime said...
mattlewis said...

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. smile

TheresNoTime said...

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.

TheresNoTime said...
said...

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.

TheresNoTime said...
said...

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

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

22. Re: named array

SDPringle said...
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".

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

23. Re: named array

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.

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

24. getxml()

eukat said...

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

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

25. Re: named array

TheresNoTime said...

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 
TheresNoTime said...

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.

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

26. Re: named array

jimcbrown said...

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...

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

27. Re: named array

TheresNoTime said...

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.

TheresNoTime said...

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.

TheresNoTime said...

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.

TheresNoTime said...

My method uses sequences because they initially do not have such effect.

But sequences are mutable!

TheresNoTime said...

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...

TheresNoTime said...

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.

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

28. Re: named array

jimcbrown said...
TheresNoTime said...

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 
said...

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.

said...

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.

said...

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".

said...

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.

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

29. Re: named array

TheresNoTime said...

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.

TheresNoTime said...
said...

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.

TheresNoTime said...
said...

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.

TheresNoTime said...
said...

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.

TheresNoTime said...

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.

TheresNoTime said...

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.

TheresNoTime said...

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.

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

30. Re: named array

jimcbrown said...
TheresNoTime said...

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.

said...

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.

said...

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. :)

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

31. Re: named array

TheresNoTime said...

My approach - always make clones, even if they are not needed.

Which works fine with Euphoria maps as well.

TheresNoTime said...
said...

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.

TheresNoTime said...
said...

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

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

32. Re: named array

jimcbrown said...
TheresNoTime said...

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"?

said...
said...

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).

said...

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. :)

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

33. Re: named array

TheresNoTime said...
jimcbrown said...
TheresNoTime said...

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.

TheresNoTime said...
said...
said...

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.)

TheresNoTime said...

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.

TheresNoTime said...
said...

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.

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

34. Re: named array

jimcbrown said...
TheresNoTime said...

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 
said...

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.

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

35. Re: named array

TheresNoTime said...

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.)

TheresNoTime said...
said...

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.

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

36. Re: named array

jimcbrown said...
TheresNoTime said...
said...

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.

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

Search



Quick Links

User menu

Not signed in.

Misc Menu