thanks for the reply, got this after minux's response, some weird golang
nuts temporal discontinuity :-)
Regarding map iterators, this was one of the challenges in building the
interpreter since Go doesn't provide any efficient means in the language to
build an iterator over a map: using a co-routine style iterator leaks
goroutines, and making a slice of key/value pairs makes accessing the first
element take O(n) space---plus it has the wrong update semantics.
Yes, this has been a source of frustration for me. I do a lot of work with
hash tables and the inability to tweak the hash or equality functions to
work with different comparisons and distributions has been a little bit
off-putting when contrasted with the open nature of C++ implementations. In
other words I'd love to be able to get inside a Go implementation of a hash
table, not necessarily in order to suggest changing the standard builtin
map, but just to be able to optimise certain things like memory allocation
for uint64 based keys in specific use cases that I have. I think your work
on enabling transfer some of the core runtime to Go is great work! If a
good way of doing iterators comes out of, even better!
The good news is that the reflect.MapKeys function internally contains
everything you need to do it right, so a future version of the reflect
package could provide just such an iterator.
Yes, there does seem to be a lot of hooks in the runtime C code to make
special exception for the reflect package. I guess pragmatism surpassed
idealism in the amount of Go code that could be trusted to do the job well
and fast in getting 1.0 out the door.
Anyway, look forward to tracking this exciting package!
Donovan (I feel like your inverse!)