djsamperi at gmail.com
Wed Mar 7 16:31:14 CET 2012
On Tue, Mar 6, 2012 at 3:56 AM, oliver <oliver at 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?
> 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 at r-project.org mailing list
More information about the R-devel