On Tue, Mar 6, 2012 at 3:56 AM, oliver <oli...@first.in-berlin.de> wrote: > On Mon, Mar 05, 2012 at 04:54:05PM -0800, Nicholas Crookston wrote: >> There are many experts on this topic. I'll keep this short. >> >> Newer Fortran Languages allow for call by value, but call by reference >> is the typical and historically, the only approach (there was a time >> when you could change the value of 1 to 2!). > > Oh, strange. > > >> >> C "only" calls by value except that the value can be a pointer! So, >> havoc is just a * away. > [...] > > For me there was no "havoc" at this point, but for others maybe. > > There are also other languages that only use call-by-value... > ...functional languages are that way in principal. > > Nevertheless internally they may heavily use pointers and > even if you have values that are large arrays for example, > they internally just give a pointer to that data structure. > (That's, why functional languages are not necessarily slow > just because you act on large data and have no references > in that language. (A common misunderstanding about functional > languages must be slow because they have nor references.) > The pointer-stuff is just hidden. > > Even they ((non-purely) functional languages) may have references, > their concept of references is different. (See OCaml for example.) > There you can use references to change values in place, but the > reference itself is a functional value, and you will never have > access to the pointer stuff directly. Hence no problems with > mem-arithmetics and dangling pointer's or Null-pointers. > > > > [...] >> I like R and will continue to use it. However, I also think that >> strict "call by value" can get you into trouble, just trouble of a >> different kind. > > Can you elaborate more on this? > What problems do you have in mind? > And what kind of references do you have in mind? > The C-like pointers or something like OCaml's ref's?
OCaml refs are an "escape hatch" from the pure functional programming paradigm where nothing can be changed once given a value, an extreme form of pass-by-value. Similarly, most languages that are advertised as pass-by-value include some kind of escape hatch that permits you to work with pointers (or mutable vectors) for improved runtime performance. The speed issues arise for two main reasons: interpreting code is much slower than running machine code, and copying large data structures can be expensive. Pass-by-value semantics forces this to happen in many situations where the compiler/interpreter cannot safely optimize it away. Based on the video Julia manages the speed issue by viewing everything like a template, thus generating new methods based on type inference. This means there isn't a lot of runtime type checking for dispatch, because customized methods were already generated, but this can lead to another problem: code bloat. There are no free lunches. >> I'm not sure we will ever yearn for "Julia ouR-Julia", >> but it is sure fun to think about what might be possible with this >> language. And having fun is one key objective. > > I have fun if things work. > And if the tools do, what I want to achieve... > ...and the fun is better, if they do it elegantly. > > Do you ask for references in R? > And what kind of references do you have in mind, > and why does it hurt you not to have them? > > Can you give examples, so that it's easier to see, > whwere you miss something? > > > Ciao, > Oliver > > P.S.: The speed issue of R was coming up more than once; > in some blog posts it was mentioned. would it make > sense to start a seperated thread of it? > In one of the blog-articles I read, it was mourned about > how NA / missing values were handled, and that NA should > maybe become thrown out, just to get higher speed. > I would not like to have that. Handling NA as special > case IMHO is a very good way. Don't remember if the > article I have in mind just argued about HOW this was > handled, or if it should be thrown out completely. > Making the handling of it better and more performant I > think is a good idea, ignoring NA IMHO is a bad idea. > > But maybe that really would be worth a seperate thread? > > ______________________________________________ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
