>> The point is that something like:
List.filter (fun s -> String.length s > 0) list
simply cannot be done efficiently, because you require either copying or shared ownership for the strings. This also occurs naturally in a number of other situations, such as storing strings in objects.
This is a very salient point. It bounced around in my brain a couple of hours before I came back to comment.
How often do you need to control memory layout and management so you get the absolute best performance? Compare that to how often you need to express filters.
For me, there's no doubt that expressing functional logic and having it be decently efficient is the most important need.
This little example of yours illustrates that a well-designed garbage-collected language has a HUGE advantage over RAII. I may be slow on the uptake, but this is the first time I've seen it that way.
* If the filtered result is used locally in a function (and then thrown away), a filtered view works just fine, is very cheap, efficient and is lazy (nice if you only consume a subset of it).
* Often only the filtered view is used, so you can destructively modify the original list, so no copies.
* If you need both the original list and the the filtered list, in a functional language you need to allocate new cons cells anyway. The cost of allocating, modifying and touching the new memory is going to dominate except for very long strings, so copying is not an issue.
Of course in C++ lists are frowned upon in the first place (as many algorithms can handle any data structure transparently), while they are kind of central in many functional languages.
There are cases of course where frictionless shared ownership is nice and GC shines. Filter is not one of them.
The problem is that you need a vastly more complex machinery to cover all the various ways to avoid copying/reference counting and then still don't have a general solution when you can't avoid multiple ownership (unless you count std::shared_ptr with its very high overhead).
As I said before, it's not that you can't do it, it's that there are costs associated with it.
> If you need both the original list and the the filtered list, in a functional language you need to allocate new cons cells anyway.
You can filter arrays also and allocating cons cells for a list is pretty cheap with a modern GC, as discussed before.
This is a very salient point. It bounced around in my brain a couple of hours before I came back to comment.
How often do you need to control memory layout and management so you get the absolute best performance? Compare that to how often you need to express filters.
For me, there's no doubt that expressing functional logic and having it be decently efficient is the most important need.
This little example of yours illustrates that a well-designed garbage-collected language has a HUGE advantage over RAII. I may be slow on the uptake, but this is the first time I've seen it that way.
reply