Re: Discuss changing the behaviour of append()
- Posted by SDPringle Jun 18, 2014
- 4269 views
So, this is not about belief or facts but rather about feelings.
Hmm ... kind of ... the only empirical thing I can come up with, which is actually why I even bothered in the first place, is that if it were built into the append() function (i.e. C code) it would give better performance than using IL code. The built-in is already testing for the first argument's data-type so there's no change there, so the only difference would be that instead of crashing the application, it could efficiently build a new sequence using the first argument.
I believe Derek is saying if we don't have this change, map:put with the APPEND argument will have to handle more cases specially in order to behave as intended. I am saying routines have this kind of strictness to data-types to help users. Especially new users who are learning the language. A new user who misuses this builtin currently gets a helpful error. I feel the if in doubt give an error is more in the spirit of EUPHORIA. Instead of garbage in - garbage out. It is garbage in - give a helpful error. Like I said before, it is subjective which is better.
I think there are better ways to improve EUPHORIA's performance.
Maybe we can handle the case specially where a variable is passed to a user defined function and the result of that function is assigned to that variable. It really shouldn't add a reference at all but just leave the reference count alone in this circumstance to avoid unnecessary copying. Another thing, what is the bottle neck that motivates library wrapping developers to create shims for libraries? Is it the cost of the allocate/poke/peek cycle? Is c_func too slow?
Shawn
