Lambda the Ultimate

I don't really disagree with your hating on Java's autoboxing, but I most strongly object to the implication that only reified generics deserve the name "real parametric types." In fact, I would say exactly the opposite. The desire for reification makes me highly suspicious that something non-parametric is going on...

I meant "reified" as opposed to "erased". Type erasure in Java leads to all kinds of problems, not the least of which is that primitives cannot be used as type arguments. Obviously having programmatic access to a representation of the type arguments isn't required to have full parametric types. Unfortunately it seems the Java/C# community have the terminology all muddled up now and I never seem to be able to get across my precise meaning.

The ability to do a type erasing implementation of parametric types pretty much coincides with having "real" parametric types. The problem with Java is that they decided to implement type erasure using "Object", which includes most, but not all, values. If there were an actual universal type used in the implementation, type erasure would work fine.

Sure. A universal type implies a universal representation, which is too inefficient for some important use cases. Coercion to the universal type implies boxing (allocation) for some values for some normally non-allocating operations, which can lead to further performance troubles, e.g. in real-time settings. The conclusion I reached is that for languages that already have primitives, some polymorphic specialization is required to avoid the performance troubles with parametric types.

Thank you for the reference. If time allows, I'll have a deeper look at the paper, which seems, like everything PLT/Racket, very solid.

The paragraph you refer to, I suppose, is the following:

Keyword and optional arguments support tasks that need more arguments than fit comfortably into procedures, but where radiacally different forms—such as unit or class in PLT Scheme— are too heavyweight conceptually and notationally. At the same time, keyword and optional arguments offer a smooth extension path for existing procedure-based APIs. Keyword arguments can be added to a procedure to extend its functionality without binding a new identifier (which always carries the danger of colliding with other bindings) and in a way that composes with other such extensions.

The way I understand the "smooth extension" is that you can add an optional argument if you later see a need to refine some API (allow a different mode that would behave slightly differently), without having to change the existing call sites thanks to the use of a default value.

They also make a very interesting point about "composition". The way I understand it, they refer to the potential exponential explosion of the number of functions you must declare if you follow dmbarbour's advised approach, providing separate functions for slightly different modes. I think, however, that for this latter point the argumentation of dmbarbour still applies : abstract all those slightly different modes than need to be composed into a "configuration parameter" that reifies all those choice into a single value with a rich algebra of combinators to active and deactivate configuration options. This could be non-trivial to design in a sufficienly expressive (configuration options with parameters), typed way, tough.

I really think we should separate the two aspects of "named parameters" and "optional parameters", which I think have different justifications. dmbarbour points apply -- or my remark about passing structures/dictionaries with named fields -- most efficiently, I think, to named parameters. Can optional parameters be separated from the "named" aspect? It's true that naming provides a simple and efficient way to know which parameters are missing or have been added; is there another support for optionality?

Data structures that blend both positional and named elements have been popularized by languages like JavaScript and Lua. Maybe it's natural for a calling convention to also have these two parts?

Why should data structures and calling conventions duplicate work? "Just pass a data structure" looks like a good enough calling convention to me.

Obviously, problems with point-free composition simply do not arise in Lisp-like languages without partial application.

I very much doubt this is true -- or only with an overly restrictive idea of 'problems with point-free composition'. ML languages also don't have partial application if you look at them closely.

There was precisely a discussion of this -- in which you were involved -- in the LtU thread you linked; a bit too heated for my taste, but still raising the question and discussing solutions.

It's interesting regarding the former "data structure / calling convention" question to see that the solution to the problem of "define a generic function that takes a function and it(s) (named) argument(s) and apply it/them" is precisely to turn the arguments back into a data structure! This is the solution to all similar complications of the calling conventions, such as "arbitrary number of arguments" as in Lisp or Python.

Note that I'm not trying to contradict your points (or Flatt and Brazilay's). I agree that keyword parameters are not all bad, and that they also have advantages. The 'crutch' post is an occasion to think about, for some time, different ways to solve the same problems, without directly adding features to the language, or adding more orthogonal/general features.

I don't want to turn this topic into a new flamewar about named parameters only; it should be an example between others. I'll be very interested in any further discussion on this point, but please also take time to consider and discuss other aspects of language design that may or may not be considered 'crutches', so that the discussion is as rich and diverse as it could be.

...and furthermore, they have the rather nasty problem that you can only give *one* set of optional values for a function -- there's no way to have multiple sets of optional values.

Just as n-ary functions are subsumed by unary functions + tuples, so too are keywords subsumed by unary funvtions and records. Basically, once you have records and a functional record update notation, there is no need for keyword arguments.

To illustrate, here's a bit of Ocaml code (ironically, a language which has keyword arguments).

(* An named argument list as a record *)
type arglist = {foo: int; bar: string; baz: bool; quux: int option}

(* A function which takes 4 named arguments *)
let f a =
  if a.baz then
    a.foo + String.length a.bar
  else 
    (match a.quux with Some v -> v | None -> a.foo)

(* Two sets of default values! *)
let d1 = {foo = 6; bar = "Hello, World!"; baz = true; quux = None}
let d2 = {foo = 3; bar = "Yo!"; baz = false; quux = Some 67}

(* Calling a function means passing in a default record, plus overrides as needed. 
Note that the calls in x and y each use a *different* set of default values *)
let x = f {d1 with foo = 18; baz = false}
let y = f {d2 with quux = Some 3}

Excellent counter example/alternative! Funny, but I've been working just this weekend on something similar, but with a little syntactic sugar sprinkled on top.(I've been reasoning along the lines of special tuple constructors instead, which one could likely relate semantically closely to your record based OCaml code).

My motivation was to permit default keyword arguments (accommodating the real world of 3rd party libraries) while avoiding N-ary functions and permitting easy application of such functions in HOF. I've also been reexamining Smalltalk's interpretation of keyword arguments (and in my ruminations, tuple arity) as simply components of a function's "real" name.

I was thinking of using this approach for a C conversion of my language. Not using it for default values at the moment, but I could.

The reason for doing it this way is that I want to be able to pass around functions with their arguments fully or partially set.

In any language with default arguments, you can always change the defaults by wrapping f, calling f' if you want d2 defaults. This may have the downside of requiring you to specify every parameter of f, though, when defining f', depending on the language. And while it's certainly true that you can model keyword args with records, I don't think it's clear that using a higher order feature to accomplish something is always the right thing to do.

Disclosure: Named parameters are fundamental in my language.

This is of course a neat solution, but it doesn't address the problem described in the paper: named parameters as in Racket and Common Lisp let you extend a function's protocol post-hoc. Your approach works only if applied by the programmer a priori to every function.

I could see how to use neelk's technique to add a parameter after-the-fact: if you consider that the function type, the record type definition and the set of default parameters are done at the same place -- which mirrors the way those three things are united in function definitions with optional arguments -- you only have to change this place to add new arguments with default values. The important thing is that existing call sites do not change.

Maybe you have a different kind of "post-hoc extension" in mind. To me, it only meant that if you extend the function definition with additional optional parameters, existing call sites do not need to be modified.

The problem is that you'd need to write all functions with such a record parameter from the start. Ruby does this for you, in fact. And it has sugar for passing a record to a function. For example:

    def foo(args)
       args[:bar] + args[:baz]
    end

Now you can do:

    foo(:bar => 2, :baz => 3)

You can do optional parameters at the call site:

    defaults = {:bar => 2, :baz => 3}
    foo(defaults.merge(:bar => 4))

And/or at the callee:

    def foo(args)
       defaults = {:bar => 2, :baz => 3}
       args = defaults.merge(args)
       args[:bar] + args[:baz]
    end

This last bit is important and interacts beneficially with dynamic typing, as you often want to initialize a missing parameter based on the value of another one.

Yes, the Lua convention for named parameters follows naturally from table constructors and a little bit of syntactical sugar that allows such unary functions to dispense with the parens:

some_function { name = 'alice', age = 16 }

As observed, also popular in JavaScript and emerging organically from the language syntax, rather than a 'crutch' that was bolted on later.

Data structures that blend both positional and named elements have been popularized by languages like JavaScript and Lua. Maybe it's natural for a calling convention to also have these two parts?

Magpie, almost incidentally, works that way. I unified tuples and records in that any positional field is just a named record field with an inferred name. That mixed with the fact that all methods are multimethods that (generally) take records in Magpie means that methods can take a mixture of named and positional arguments. The fact that they are also multimethods means you can overload on those named arguments too. It leads to, I think, some nice looking code:

// mix positional and named:
collection insert("item", at: 3)

// overload by argument type:
"something" substring(from: 2, to: 5)
"something" substring(from: 2, count: 3)
"something" substring(from: 2)

I find implementing methods like substring in Magpie is a good bit simpler than most dynamic languages with named arguments since each overload is an actual distinct method with its own body and the language does the dispatch for you, instead of having a slew of if arg instance String branching inside the one monolithic method like you do in Python/JS/et. al.

I unified tuples and records in that any positional field is just a named record field with an inferred name.

The Oz language does something related: tuples are records whose field names are numbers: t.0, t.1... or maybe it starts from 1, I don't remember. It's easy to have comfortable tuply syntaxic sugar on top of that. Fields whose name is omitted are given numeric field names in left-to-right order.

I'm not sure what you mean by "inferred" here. Oz numeric field names are "implicit" more than "inferred" (there is no logic at all in the inference process). I would consider type-based field name inference to be more fragile and hence less desirable, but that's probably not what you do in an untyped language.

Standard ML perhaps is a more prominent example following that approach. Also, its library has long been using records to provide named parameters in exactly the way Neel was describing -- its structural record types make that very lightweight (although it lacks record updates to provide defaults).

I'm not sure what you mean by "inferred" here.

Yeah, "implicit" would be clearer here. I meant "inferred" only in the informal sense. There's no complex magic going on.

Hi,

I guess what you are refering to. Initial versions of Java only provided collection classes and string builders that were synchronized.

Although the synchronized statement has now a very good fast path in Java, still some performance penalty can be seen.

But fortunately the situtaion has improved in that new collection classes and string builders have been provided that are unsynchronized.

You can speed up your application by refactoring as follows:

Vector --> ArrayList
Hashtable --> HashMap
StringBuffer --> StringBuilder

Most of the APIs in the old classes are also found in the new classes,
except for a missing setSize() in ArrayList which could be painful.

Unfortunately this has led to a class library bloat. Don't know whether other approaches would lead to a leaner solution.

Bye

Programs that use locks are not compositional, and static analysis for livelocks and deadlocks is more difficult (doesn't scale well). This is why they are 'awkward at best' for high-level programming. People might be willing to put up with locks for low-level programming, until they find bottlenecks and realize those bottlenecks can be solved by a scalable, lock-free data structure.

Rich Hickey and Cliff Click had a pretty long debate about this. Ultimately, they both agreed that giving locks to John Doe average programmers turned out to be a bad idea in practice. Cliff refers to this mistake as the JVM engineering decision to give locks the illusion of being cheap to acquire/release. It was a mistake, because programmers would then slap locks haphazardly everywhere.

What I admire at cliff click is that he adopts a high level view of VM design. And really critically thinks about functionality allocation inside and outside of the VM.

BTW: Not only John Doe is confronted with the problem. I know a very big company with a number highly qualified engineers, their VM still hangs in certain situations when it should quit on its own, when all GUI interaction is terminated and only daemon threads are running..

So its a problem at the macro level and not at the micro level. What can help? Language design? Or program verficiation and testing discipline? Where is the border between language design and program verification? What is feasible?

Maybe start with better debugging tools. That record the execution trace of all threads until the point of interest. So that we can look at it like watching a film. One shot stack traces for all threads does not give this information. Maybe John Doe would also use such tools.

DirectX seems to be based on COM for this reason, but then it doesn't need to be really portable either.

sun hates delegates tee hee.

Funny, there are no authors on the document....I wonder who wrote this. I have my suspicions :)

I saw the talk ref'd on hackernews but haven't been able to watch it yet do to the Chinese Great Firewall.

Some of it sounds biased. Loops are less simple than set operations, but they are not necessarily less easy. People get loops quickly, they are very concrete, and have to adopt an FP mindset to get set operations, which are more abstract. But maybe Clojure is optimizing for simple over easy?

Scheme makes loops more difficult than map and apply too, I think.