It also has mechanisms for declaring parameters as “in”, “out”, or “inout”, which makes the compiler’s dataflow analysis rather easier. (You can mostly do the same thing with C++ references using “const”, but this I think is a bit more direct about the purpose.)

I have not looked in detail, but I believe that the interactions between the “pure” keyword and the object-oriented programming introduced in Fortran 2003 will have been fairly well-thought-out as far as combining objects and pure functions.

Well, yes Java and C# are safer than C in many ways. But, simon was being quite specific in his meaning of safety and, from that perspective, they are really quite similar.

There are a few things here. Firstly, objects to not always completely encapsulate the state they access. Oftentimes, an object is shared amongst many and used as a shared variable. In some sense, what you have is many small object networks which are collaborating together. To move one object onto a core you have to figure out which ones from its network are needed as well. And, the compiler certainly is not capable of doing this for us.

I’ll take your word for it that Java, C#, and co. do share state internally, but surely that’s implementation specific and not a limitation of object orientation per se?

Go is actually diametrically opposed to the Haskell philosophy, I would think: it tries to be as useful as possible and safe only when it serves the first purpose. Personally, that seems like the best way to go in practice. Always good to research superior methods, of course… it just doesn’t seem like the research has generated much use in the last few decades.

I prefer writing powerful, useful projects quickly and with fun tools. Ill leave optimizing the parallelizing compilers to the people who feel like mucking with it.

It’s not the “open” annotation or leaving out “final” that commits the superclass writer, it’s the documentation which says how the class is working.

If I’m extending a class and there are no guarantees about its working model written in the documentation, then I accept the risk that my assumptions may be broken with next release.

About requiring parens for application — this overloads the meaning of parens, they’re not only for grouping anymore. I think all kinds of overloading usually complicates matters (but on the other hand, it may be beneficial for expert language users).

Now, if you choose juxtaposition for application, then you need to separate type and name with something (eg. colon). You gain some, you lose some.

To make sure I’m on the same page, would I be correct in thinking that, at least compared to C, that OpenCL is an “SPJ-Useless” language?

It uses two completely different sub-languages to do the job.

anyone comment on the advantages for a compiler for a language that insists on pure functions

The issue here is whether or not the compiler can still perform key optimisations. In some cases, static analysis can determine that a piece of code is pure. But, this is really difficult and most compilers don’t do it (although the JVM presumably does to some extent).

Const in C++ is interesting because the language spec explicitly states that modifying an object through a const reference results in undefined behaviour. This does enable the compiler to optimise, even though const is not strictly enforced (see this). However, the downside is that when some does break constness then subtle bugs can arise which are hard to understand because they’re caused by some specific compiler optimisation.

The search-based nature of Prolog would seem to make it a good candidate for automated parallelisation. However, I don’t really know enough about Prolog to make an informed opinion. Perhaps someone else can comment?

I imagine that the same techniques useful for parallelising Haskell could be applied to logic languages. But I am quite ignorant there.

it is essential for a programming language to be unambiguously precise

That’s a given, and is not specifically about syntax.

The precision of a program should be equally obvious to a human reader as it is to the computer.

No, I definitely disagree on this. It should be much more obvious to a human than the computer That is, I want to make the compiler work harder for the benefit of the human.

That paper you cite claiming things about “Random syntax” lies

That statement is far too strong for me. Certainly, as we discussed in the reading group, there are a few problems with the paper. My point is only that it represents an attempt to do research in this space.

That paper you cite claiming things about “fandom syntax” lies, for all they have done is encipher the keywords, leaving totally unchanged the syntactic rules for the structure of programs. Please, never confuse the “syntactic sugar” and lexemes for the real syntax of a language. (I will argue that the indentation rules of Python are not part of the real syntax.)

I never got taught greek letters at school (well, other whan pi)!

As for research, well there’s that paper on Perl versus Random Syntax.

As for Smalltalk, I just follow Wikipedia … why do they do it that way?

Not sure if there’s any research on this (would be relatively easy to check) but I think best practice is probably to parenthesize if there is any room for ambiguity. That’s why Self, for example, has no operator precedence – if you’ve more than one, parenthesize.

(and you’re still misspelling Smalltalk)

I think it’s good to have generalized principles like you have to guide language development, but every language designer must inevitably come down on the side of personal aesthetics at some point. For example, one of the major syntactic differentiators between Ruby and Python is that Ruby obeys the uniform access principle and Python does not. The argument for this principle is that you don’t want clients of your object to care whether a query is implemented as a property or a function; you should be able to switch implementations in the future without breaking your object’s contract (the origin of this, AFAIK, is Bertrand Meyer’s Object-Oriented Software Construction). One ramification of this is that in Ruby it is not possible to pass a function by name to another function; you must instead create a closure with a block. Ruby happens to include other syntactic support that makes this easy or automatic, but it’s a contrast to Python, where names always refer to some object and not some computation, and function calls are usually discernable from property access by the presence or absence of parentheses. There are now ways of working around this for the purpose of providing methods that are invoked at property accesses instead of reading properties on objects, but this was a late addition to the language and is about as clean and easy as passing a function by name to another function in Ruby.

The point I’m making is that neither of these answers is “correct” in absolute terms. I could argue that Ruby’s method is concise and informative to humans in the general case, but I could also argue that Python’s decision conforms (saying ‘foo’ when you have a function defined by that name refers to the function, not the result of invoking it). Good languages will certainly fulfill these guidelines, but they will do so only within their self-defined context, and comparison across languages is (in general) fruitless.

*Any* operation that is non-associative would require parenthesis to specify order. In this case, either you add a separator between every argument, or parenthesis around every application, or you require people to explicitly group applications when they’re passed as an argument to other functions.

Also, my argument about colons for types isn’t about simplifying it for compilers, but to simplify it for readers of the code, as opposed to writers. I don’t care that the C++ syntax is context-dependent and ambiguous for the sake of the compiler reader, I care because it slows me down when I try to read C++ code. Adding a few carefully chosen symbols to make things easier to parse (by human readers, and compilers) is perfectly sensible.

(f . g) h 1 2

You just need to compose it first to produce the right function. (Note that you still need parens because application binds tighter than any operator).

A more general example:

f : T1 -> T2
g : T3 -> T1

then (f g) : T3 -> T2

… it’s function composition!