On Wednesday 20 May 2015 19:56, Bartc wrote: > "Steven D'Aprano" <steve+comp.lang.pyt...@pearwood.info> wrote in message > news:555c225b$0$2769$c3e8da3$76491...@news.astraweb.com... > >> The mental gymnastics they go through to force the round peg of pass-by- >> sharing object semantics into the false dichotomy "pass-by-value versus >> pass-by-reference" is just crazy. >> >> One consequence of this is that the meaning of "call by value" depends on >> whether the value you are talking about is a boxed or unboxed value. >> Unboxed >> values are copied. Boxed values are not. Except that they are, if you >> understand that "the value" doesn't refer to the actual value, but to >> some hidden and implementation-dependent reference to the value. > > I have a language where everything is boxed (the data that isn't boxed, > has to be before it can be manipulated). > > But simple data such as small integers and floats are passed by value. > Bigger data is 'sort of' passed by reference, but not full reference (the > details are a bit messy, but if an object consists of two parts (A,B), > then a copy of descriptor A is passed, which contains a pointer to B. For > small scalars, the B part doesn't exist).
Sounds complicated and confusing. In my opinion, you would be better off picking a well-known argument passing convention (call by value, reference, name, sharing) and using that, always. Or at least have a simple, objective rule for when you swap from one convention to another, like "arrays are passed by reference, everything else is passed by value". What you *shouldn't* do is implement your own argument convention, then call it "pass by value" if it is not the standard meaning of pass by value. Don't do what the Java community does, which is implement pass by sharing but call it pass by value. Don't do what the Ruby community does, which is implement pass by sharing but call it pass by reference. Don't do what the Lua community does, which is invent a stupid distinction between "reference types" and "value types" so they too can misuse terminology: http://stackoverflow.com/questions/6128152/lua-function-variable-scope-pass- by-value-or-reference Take note of the highest voted answer, by Bas Bossink, claiming that Lua uses pass-by-value for some values and pass-by-reference for others. He is wrong. Just like Python, Lua uses the same calling convention for all types, and it is neither pass by value nor pass by reference. This calling convention has been known as pass by sharing (or variations of that, like "pass by object sharing") since it was named by Barbara Liskov in the 1970s, for the language CLU, but the convention itself goes back to Lisp in the 1950s. Fuzzy thinking leads to confusion, error, and PHP. > (A proper reference is available when passing arguments to functions: > a boxed pointer to (A,B) is constructed.) > > However, I was so impressed with how (C)Python does things (working > exclusively with pointers, doing assignments by simply copying pointers, > and using reference counting to manage memory), that I'm experimenting > with letting my language work the same way. (Also then I can benchmark the > two more fairly.) Most modern application languages (as opposed to systems languages) use the same convention, pass by sharing. Java uses it for objects; Python, Ruby and Lua use it for everything. I'm *guessing* that Javascript also uses the same convention, but I'm not sure. Perl, I imagine, does the most complicated thing that can possibly not collapse in a heap of internal self-contradiction :-) > Then I get a little disillusioned when I find out in this thread that a > simple slice of an array actually copies every element! Since I currently > create a view (a good term I'd never come across before) for a slice, does > that mean I now also have to do what Python does? You only have to do what Python does if you wish to claim that your language is an implementation of Python. Feel free to borrow slicing syntax list[start:stop:step] but return a view. That's what Go does. Views and copies each have their own advantages and disadvantages. As the designer of your own language, you get to decide which trade-offs your language makes. -- Steve -- https://mail.python.org/mailman/listinfo/python-list
