Re: named array
- Posted by jimcbrown (admin) Sep 04, 2013
- 1970 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.
