Lambda the Ultimate

I like this approach. In fact recently I heard a lot about C# that sounded very intresting.

I think I mean sth. slightly different: The caller decides weither a given argument is passed as ref or value, but the function itself treats the parameter as it likes. In C you are bound to the type of parameter defined in the function definition: either a value or a ref (ptr in C).

I just realized that if the caller chooses how to pass an argument, a function may have as well no effect, because its only purpose may be to modify that argument.

As you say, the definition of the function may rely on the parameter being a reference.

You could approach this problem in another way, by introducing an "update with" syntax, for example something like:

foo => myFunction();

This would be syntactic sugar for:

foo = myFunction(foo);

Our functions will always be called by-value, but the caller can decide to replace their old version with this new one immediately. This would also act as a hint to the compiler/interpreter that it can update this value in-place, ie. we can reuse the existing function in a call-by-reference way. Such a hint would also be useful to track argument usage:

myFunction = function(myArg) {
  temp = otherFunction(myArg);
  return 45 + temp;
}

otherFunction = function(myArg2) {
  temp2 = blah(myArg2)
  return temp1 * myArg2;
}

Here "myFunction" only uses "myArg" once, so it could do "myArg => otherFunction();" to avoid a copy; this can keep cascading until someone actually needs a copy. An example where a copy is needed is "otherFunction", which uses "myArg2" after defining "temp2", so we have to use two variables in this situation.

This has many similarities to CopyOnWrite; there may be advantages to using both together.

It may be useful to allow name changes without copying too, so we can update values in-place while still giving them more descriptive names. This is especially useful for Hungarian notation. For example, we could change our syntax a little to get:

unsafeEmail = askUser("What is your email address?");
safeEmail => sanitise(unsafeEmail);
sendToDb(safeEmail);

Here we've updated unsafeEmail in-place, but given it a new name "safeEmail". I would recommend that this invalidates the name "unsafeEmail", but there may be arguments for keeping both around (like "$foo =& $bar" in PHP).

Most code belongs to the person using it so why do they need protection from themselves? Who can write a C program without passing a pointer to a structure to get something done? In fact, this whole comment seems like a dismissal of all imperative and OOP programming as accessing the data associated with the encapsulated data is an implied pointer from the functions viewpoint.

If you have to worry that somebody with change your data and the language needs to protect you from that person, the person already has access to the programming code and call by reference is the least of your worries.

Of course your solution to this huge problem might just happen to be stateless functional programming. What exactly happens in functional programming when you need the function to act on a 50M data structure? Does a programmer have any rights to the code they write or does it have to pass the compiler writers smell test?

It was nice how you fitted that "compile time type-checks rather than runtime" in there without any justification. It only takes a few words to dismiss dynamic type systems and systems that aren't or can't be compiled monolithically at one time.

So far, all OOP and dynamic languages have bitten the dust. RIP

Libraries, frameworks, services, plugins, etc. embody a great deal of code not controlled by the person using them. In team development efforts, it is not uncommon that no member of the team understands the full codebase. I wouldn't be surprised if most people control less than 1% of the code they use.

If a function is in a library or otherwise doesn't give you access to it's source code, please explain, without changing the function, how to allow the option of call by value or reference? How could this option be available in general through the PL?

You responded to my post and I think I showed that the function would have to be written explicitly to enable both types of calls.

Do you disagree?

How could this option be available in general through the PL?

The trivial solution would be to compile each function each way that it is used. For functions exposed through an interface, you'd compile them each way. A more sophisticated option is to integrate this with the value model - i.e. a value model that can transparently flip from edit-in-place to copy-on-write (perhaps leveraging uniqueness properties).

The technical feasibility isn't in question. The merit is. I think it would be silly to pass-by-reference where pass-by-value is expected, but the converse might be a little useful.

You responded to my post

I responded to your first sentence. You seem to be depending on a premise (that users own most of their code) that disagrees with my own understandings and experiences.

Let's say I wrote a function to change data that was passed by reference and I return whether it worked or not by using a logical. This function could be arbitrarily complex. If you sent that function a copy of the data instead, the algorithm might work correctly but the result would never get back to the caller. The changed data would just die on the stack.

How would you create an equivalent function that could return the resulting data rather than the logical? What would it mean to the function definition to return 2 totally different types from the same function where that type difference depends on the data? By the way, PHP returns different types for some functions that depend on the data and it is very easy to get errors because of it.

If you can see where my argument is incorrect, please enlighten me!

There is no general equivalence between return values and pass-by-reference values; any such property would depend on the language. But I'm not seeing the topic relevance.

What exactly happens in functional programming when you need the function to act on a 50M data structure?

The usual approach these days is to "stream" the data through our functions, much like we stream text through UNIX pipes. For example I can run grep on my entire hard drive, but it will not wait for all the data before it starts processing.

This isn't completely generic, for example we may have an algorithm which needs access to the entire datastructure before it can do anything, but in those cases we're screwed no matter what language/approach we use.

http://okmij.org/ftp/Streams.html#iteratee

Of course your solution to this huge problem might just happen to be stateless functional programming. What exactly happens in functional programming when you need the function to act on a 50M data structure?

[I'll go further than Chris Warburton does in his answer to this]

The equational theory that is the lambda calculus doesn't go all wonky upon reaching a certain length of computation. With that in mind I cannot for the life of me figure out how functional programming at the 50M data structure size is going to be much different than functional programming at any other data structure size.

Beware the fallacy of the beard. Due to various peripheral reasons (performance, process control, partial failure, persistence, memory constraints, limits of human patience), working with large structures is different from working with small ones. Of course, 'large' is relative; these days, 50M isn't too large, but add another order of magnitude or two...

Indeed, different calling conventions are not equivalent even in a pure, Platonic setting like Lambda Calculus. We usually think of the Church-Rosser property as telling us "all calling conventions give the same result", but we have to remember the caveat "if they give a result at all!". For example:


infiniteList = 1 : map (1 +) infiniteList

main = print (fst ("Hello world", infiniteList))


If this program halts, it prints "Hello world". This will happen in a non-strict language like Haskell, which won't bother trying to construct the value "infiniteList" because it's not used. A call-by-value language (Scheme, OCaml, etc.) won't give a different result, it will give *no* result; it will get stuck in an infinite loop trying to build the list.

In fact this is the reason I shied away from mentioning calling conventions explicitly; I can't think of a way to make Iteratees for arbitrary, pre-supplied datastructure which is both call-by-value and constant memory. Of course, if we can implement the datastructure too, we can use thunks to generate the large parts on-demand. For example, in Javascript:


// Naive implementation of the above; will get stuck in an infinite loop.
var infiniteList = function() {
return [1].concat(infiniteList().map(function(x) { return x + 1; }));
};
var main = alert(["Hello world", infiniteList()][0]);

// Implementation using thunks (the second element of each array is a function which generates the rest)
var incAll = function(l) {
return [1 + l[0], function() { return incAll(l[1]()); }];
};
var infiniteList = function() {
return [1, function() { return incAll(infiniteList()); }];
}


If we're getting data from some outside source, these seemingly-artificial thunks can be replaced by the relevant "getNextValue" function for our data source.

Due to various peripheral reasons (performance, process control, partial failure, persistence, memory constraints, limits of human patience),

Exactly, peripheral reasons, none of which are specific to functional programming.

To counter your earlier position, it is sufficient to note that functional programming is different with the larger sizes - different idioms and design patterns, tighter integration with effects for persistence or process-bar feedback, etc.. That this is not specific to functional is a valuable observation for another argument entirely, and perhaps we can study a few paradigms and generalize some requirements for operating on very large data structures.

In general you, as a programmer, have access to the function code and you are the one making the call so you could pass by value or reference depending on what you want.

This statement is incorrect. If I had access to the source in general, that would mean I can always reach the "having-access" state, which I can't (for example, the source may have been lost years ago). In general I *don't* have access, because I can always reach the "no-access" state (eg. by deleting things).

If you mean programmers "usually" have access then I would agree, but hacking library code (without having your patches merged into the trunk) is a bad idea because it puts you in charge of a fork.