抽象的なウィキペディア/更新情報/2021年01月21日

◀

抽象的なウィキペディアの更新情報

▶

今週のニュースレターは、他と比べて少し技術的な内容になっています。

本題に入る前に、お知らせを：ロゴコンセプトの提案は現在、募集中です！すでに6つのロゴの提案がなされており、それぞれ一見の価値があります。より多くの提案がでてくることを期待しています。提出期限は2月16日です。

現在作成されている公式の関数モデルは、関数モデル全体がすでに実装されていることを前提としています。特に、ジェネリック型に依存しています。ジェネリック型とは、通常、別の型によって変数化される型を意味します。

変数化された型の例はどんなものでしょう？リストでの型を見てみましょう。

リストは、順序付けされた一連の要素です。これらの要素の型は何でしょう？何でもいいでしょう！リストの要素の型を知らなくても実行できるリストの操作はたくさんあります。リストの最初の要素を取り出したり、リストの要素の順序を逆にしたり、リストの2番目の要素をすべて取り出したり、それ以上のことができます。
そのようなリストの1番目の要素を出力する関数により戻り値の型は何でしょうか？知ることはできません。リストの要素はどのような型でもよいので，1番目の要素を出力する関数の戻り値の型も，どのような型でもよいことになります。

Now, instead of having a single type called “list” you could also have types called, say, “list of strings”, or “list of numbers”, or “list of booleans”. Or, even more complicated, “list of lists of strings”. You could also have a list of any kind of elements, or multiple kinds at once. Now, if you have a function that returns the first element of a “list of strings”, you know that the return type of that function will always be a string. You have more type safety, and you can have your code-writing tools provide much better guidance when writing functions and function calls, because you know that there must be a string. It is also easier to write the functions because you don’t have to check for cases where there are elements of other types popping up.

But on the other side, we suddenly need many more new types.

In theory, an infinite number of specialized types. And for each of these types, we would need all the specialized functions dealing with that type, leading to an explosion in the number of functions. This would be a maintenance nightmare, because there would be so much code that needs to be checked and written, and it all is very similar.
In order to avoid that, we could write functions that create the type and functions that we need, and that take the type of the elements of the list as an argument. So instead of having a type “list of strings”, we would have a function, call it list(string), that has a single argument, and that you can call list(string) and that would result, on the fly, in a type that is a list whose elements are strings. Or you can call list(integer) and you get a list whose elements are integers.

The same is true for functions: instead of having a function “first” for that only works on lists of string and returns a string, you would have a function that takes the type “string” as an argument and returns a function that works on a list of strings and returns a string. Instead of writing a “first” function for every kind of list, we would write a function that creates these functions and then call them when needed.

There are also situations where the dimension of typed input on which you need to operate is limited by number, rather than or as well as type.

As a more complicated example, if we had a method to do matrix dot multiplication, the number of columns in the first input matrix and rows in the second must match. There, instead of taking just a type to create the matrix (say, a floating point number), our top-level type function would take two integers as the numbers of rows and columns as well. We could then call this method with matrix(float, 4, 3).
Similarly, Earth-based ground positioning information is generally relayed by two dimensions of degree, and optionally one of altitude; there you might have tuple(float, 2) for the former, and tuple(float, 3) for the latter.
The exact way that the Wikifunctions community would decide to model the position type is left up to them – in deciding on a type, they might also want to explicitly specify the planetary body, the datum, the accuracy in each dimension, or other data as well. We just need to make sure we provide the flexibility to editors to represent things they will need or want. Note also that common types, such as geocoordinates, will likely be created as named types on wiki, but structures can always be created on-the-fly too.

This idea has many different names and concrete realizations in different programming languages, such as templates, concepts, parametric polymorphism, generic functions, and data types, etc. For our purposes, we call this generics, and it is currently scheduled to be implemented in Phase ζ (zeta).

Now the thing is that the function model as it is currently described relies heavily on generics. But until they are in place, we can’t really use them. So we are in kind of a limbo, where the precise function model we are implementing right now is not specified anywhere, and instead we are adjusting on the fly based on the current state of the implementation and where we want to eventually end up.

それをサポートするために、明示的なプレ・ジェネリック関数モデルを公開しています。これは、また現在のモデルを説明していないことに注意してください。でも、これはフェーズγ（ガンマ）の終わりまでに実装する予定のモデルであるため、現在wikiで説明している最終的な関数モデルよりもはるかにすぐに役立ちます。その考えは、ジェネリックをサポートするようになったら、プレ・ジェネリック関数モデルから完全関数モデルに移行するというものです。 Comments and suggestions on the pre-generic function model and the plan presented here are, as always, very welcome.

前提となるウィキペディアの記事:

そして、進行中のロゴコンセプト提案コンテストを覚えておいてください！