• All fortran interop C API are included in MPI C ABI, e.g. MPI_INTEGER, MPI_Comm_f2c, MPI_F_STATUS_IGNORE
• Jeff intended an MPI ABI implementation that does not depend on Fortran
• Thus the ABI standard need fix all relevant Fortran ABIs
• The key requirement: Fortran INTEGER is equivalent to C int, but also need fix all Fortran datatypes with C equivalents.
• MPI C ABI need implement MPI_Comm_f2c etc. with a dictionary mechanism
• MPI C ABI does not do any Fortran compiler checks, only via assumptions

• MPI should not specifiy INTEGER is C int if Fortran doesn't say so

I haven't been writing a new blog post for many years. It is always in mind that I need write more articles about MyDef. I am still using MyDef, I am still developing MyDef. And I am more than ever convinced of MyDef. The difficulty has been the lack of audience. Without an audience, it is very difficult to formulate sentences. So naturally we imagine an audience during writing. The imagined audience has a few issues. An imagined audience can easily mis-represent real potential audiences, resulting an mis-tuned essay. More critically, an imagined audience shifts during writing, resulting in a incoherent and dis-organized writing.

$ cat test.def
include: c/mpi.def
include: c/thread.def

page: test_send, mpi_frame, MPI_THREAD_MULTIPLE
    module: c
    run: mpiexec -np 2

    &call run_threads, 4

Python does not have explicit variable declarations. It is implicitly created by the assignment. That means to understand a piece of code, specificly, to understand a life time of a variable, one has to hunt down the first occurence of assignment.

In Perl, with use strict, which should be on always, it is a simple matter of searching for keyword my or our. The life time of a local variable starts at the my $var to the end of the scope, period.

From wikipedia, pure mathematics is mathematics that studies entirely abstract concepts.

Good. But what are abstract concepts?

From wikipedia, Abstraction is a conceptual process where general rules and concepts are derived from the usage and classification of specific examples. "An abstraction" is the outcome of this process.

I don't think to develop in Rust is a good idea. By developing, I mean one is not sure about his program's objectives, feature set, and its logical path yet. Majority of coding is at this phase. Even for firefox, when they are constantly implementing new features, finding better algorithms, building new APIs, it is in a developing phase. But I think Rust is so far the best language for a production phase. By production, I mean one has fixed requirement, clear algorithm and logic, and its activities are essentially translations from the developing language and bug hunting/fixing. Why in our current software culture there are so few projects in production phase? Why our current user base have such an appetite for developing stuff rather than simple/usable products?

A comment for: http://stackoverflow.com/questions/27961879/why-is-using-return-as-the-last-statement-in-a-function-considered-bad-style/43146646?noredirect=1#comment73380218_43146646

"It just is." is not a good answer for adults.

Conventions and styles are in the eyes of the users. If the majority of users find using return intuitive, then it is a good style, regardless what the language designers' opinions. If the majority of users use the "return" style, then it will be the convention.

Rust is quite new, so at this point, there is not really much convention or "good/bad" styles, it is just recommendations and guidelines. You have the choice of following them (a particularly good choice when you don't have much of your own opinions) or ignore them as long as it is still correct (a not bad choice if you have sufficient self-confidence).

Fixed precision numbers are desirable as it matches the concept of precision in reality. The problem being it is difficult to be certain of needed precision ahead of time. So ideally, we would like a seamless support at the programming language level. At the source code level, numbers are just numbers and all arithmetics are supported in the same presentation. By default, a floating type will do. However, we can tune he program to more precise precision by updating a variable's type. Integers will have precision of 1 (scale of 1) or more, and some variables may have a precision of 1e-100. Even binary precision may be adopted.

Now this is quite complex to support. Instead of a couple number types -- int32, int64, float, double and their unsigned versions, we essentially need support unlimited number of types. The compilers need output different arithmetic routines based on the operands data types.

But I think it is workable, and it is probably worth while.

Not to rewrite is a very sensible decision due to the fact that the current way of programming is un-rewritable. For example, people don't write FORTRAN in every language. The choice of programming language often fundamentally change the way we approach programming. Switching language not only involves addition or reduction of language constructs, it fundamentally alters programmer's highest level thinking process. That is not a merit.

What we need is a meta-layer programming interface that isolates our higher thinking from lower language concerns to some degree. If you can keep the higher level understanding, then rewriting become less of a barrier. We need write pseudocode in every language.

I have been exclusively programming with a meta layer, MyDef, for quite a while, and I routinely re-write my Perl program to C, not without effort, but always a worthwhile effort trading for the goal of rewriting (speed in this case). I am a researcher, and I rarely write production code. But for production code,

What is wrong in today's programming culture is that it is treated as write-once-only. A program is written and never expected to be re-written.