Wikifunctions:Project chat

Welcome to the Project chat, a place to discuss any and all aspects of Wikifunctions: the project itself, policy and proposals, individual data items, technical issues, etc.

Other places to find help:

• Wikifunctions:Administrators' noticeboard
• Wikifunctions:Report a technical problem
• Wikifunctions:FAQ

SpBot archives all sections tagged with {{Section resolved|1=~~~~}} after 1 day and sections whose most recent comment is older than 30 days.

edit
Archives
2023/08 2023/09 2023/10 2023/11 2023/12 2024/01 2024/02 2024/03 2024/04 2024/05 2024/06 2024/07 2024/08 2024/09 2024/10 2024/11 2024/12 2025/01 2025/02 2025/03 2025/04 2025/05 2025/06 2025/07 2025/08 2025/09 2025/10 2025/11 2025/12 2026/01 2026/02 2026/03 2026/04 2026/05 2026/06 2026/07 2026/08

Contributing to language functions 1: Language Fragments

At Wikimania, @Dnshitobu recommended cloning a page like User:Dnshitobu/Dagbani Fragments and filling it with my own language. If I understand correctly, it's supposed to help to create functions for handling my language.

I created User:Amire80/Hebrew Fragments and started filling it. There are a bunch of problems with it, but let's say that I can complete it. Is it actually useful? Once it's complete, what do I do with it?

More broadly, if it is useful, is there a written guideline anywhere that recommends doing it? If I didn't visit Wikimania, I wouldn't know about it. Amir E. Aharoni (talk) 22:10, 30 July 2026 (UTC)

From this week's newsletter: [Dnshitobu's] main proposal is that editors can create simple wikitext tables of example fragments in their language so that others could later do the technical work of setting up the lexemes and NLG functions. The next step is to correlate your example sentences to the top-level NLG functions, then add 1 or 2 test cases to each function from your table.
I don't believe Dnshitobu wrote up the process anywhere on-wiki, but that would be worth doing. YoshiRulz (talk) 22:30, 30 July 2026 (UTC)

OK, I can try to do it.

However, I should mention that the examples work kind of well in English, and perhaps they work in Dagbani, but they don't translate easily into Hebrew. Different nouns need different prepositions some letters require morphology transformations and some don't, etc. It cannot really be solved with a few basic concatenations as it was probably done in English.

The same is true for probably most other languages. Amir E. Aharoni (talk) 23:49, 30 July 2026 (UTC)

Also, who do I notify when it's ready? Amir E. Aharoni (talk) 00:58, 31 July 2026 (UTC)

WF:Requests for connection and disconnection YoshiRulz (talk) 01:15, 31 July 2026 (UTC)

But these are not functions or implementations. These are just example strings. Amir E. Aharoni (talk) 09:58, 31 July 2026 (UTC)

Right, you have to create test cases from them. For example, the "part of" sentences #7 and #8 correspond to Z34637, so start by adding a test there. Then create a new function with the same shape as Z34867 and add all your sentences to it as tests. YoshiRulz (talk) 17:49, 31 July 2026 (UTC)

I think people should get help also if they can just write down how a fragment looks like for a specific language. So it should be not required to create a test case. So far I am not good in implementing functions in Wikifunctions. In the last days I have thinked about how to find a good way to define the fragments if the inputs are modified. This is difficult and I am not sure what is the best way. In the past I proposed decision tables for it. From my point of view more ideas and ways how to implement functions are needed as I expected more content in more languages in Abstract Wikipedia so far. It seems to me like it is too complicated to contribute to Wikifunctions at the moment. Hogü-456 (talk) 21:31, 11 August 2026 (UTC)

On a set type

In WF:TP, sets were refused as an independent type (and we are redirected towards using Typed lists). After adding many functions relative to hereditary sets and von Neumann ordinals, I believe a proper hereditary set type could be welcome on Wikifunctions. Here is the rationale behind this:

• In its current state the Wikifunctions composition language lacks basic arithmetic operations. It is interesting to provide a set-based "fallback" for those, even if its performance makes it rarely used. One of Wikifunction's goals is to "Imagine a programming system that allows us to make the next big leap in knowledge representation", having a proper representation of natural numbers is a good start.
• Set operations are the basis of mathematics. Mathematically, natural numbers are typically defined with sets. Note that these mathematical sets are well defined hereditary sets: sets that only contain other hereditary sets or are the empty set.
• Currently Typed list(Object) is the best available representation of hereditary sets. They are however unclear (Object could be anything, while hereditary sets can't contain anything), and a pain to document: every function performing arithmetic using set representation needs to write "von Neumann ordinals represented as hereditary sets"; simply making the input type "Hereditary set" is a much cleaner and clear solution.
• Hereditary sets can easily be defined as Typed list(Hereditary set). I am however unsure wether this kind of recursive type is possible in Wikifunctions.
• Hereditary sets have all the characteristics of a normal type (a validator, an equality function, and even type converters). Making a proper type for them avoids repetitive work and allow for better integration in the Wikisource ecosystem. Note that all these functions are different from their Typed list equivalents (equality ignores duplicates, type converters return set objects and not list objects).

I would love to see a proper hereditary set type being discussed. If this isn't the right place, please tell me, I'm quite new to the type proposal process :) Virinas-code (talk) 20:30, 8 August 2026 (UTC)

Another use is to avoid confusion, such as between Equality of sets (Z34270) and Equality of hereditary sets (Z34273), which has already caused issues before. Virinas-code (talk) 20:32, 8 August 2026 (UTC)

IMO being "reliant" on code Implementations for arithmetic isn't a problem. Von Neumann ordinals are useful as a mathematical foundation but not as a computational one. YoshiRulz (talk) 05:18, 9 August 2026 (UTC)

After further work on von Neumann ordinals related functions, it appears Wikifunctions' builtin type converter from a Python list to a Typed list really struggles with deeply nested lists. I believe having a strong type converter for hereditary sets can really help with fast computations. Virinas-code (talk) 00:06, 13 August 2026 (UTC)

I don't have the whole answer, but here's some information to start.

> Hereditary sets can easily be defined as Typed list(Hereditary set). I am however unsure wether this kind of recursive type is possible in Wikifunctions.

This is possible! All of the needed features exist in Wikifunctions. If you try to define this type and find it's not possible, then that should be filed as a bug in Wikifunctions (and one we will triage fix through the normal channels).

I also want to set some expectations. While Wikifunctions can (barring bugs?) absolutely represent a hereditary set type, operations on that type will not necessarily have the expected asymptotic performance characteristics. Generally, the ZObject language specification doesn't allow for an object to have an arbitrary number of members, so any container type will end up relying on some kind of recursively-defined structure like WF's own List type. Practically, this means that the composition language could never do something like an O(1) set lookup.

That said, I also want to point you to code converters, which would allow the hereditary set type to be converted to a more efficient representation inside of the JS and Python code executors. That's a secondary concern for after the type exists.

Happy to discuss further! CMassaro (WMF) (talk) 16:02, 13 August 2026 (UTC)

Hi! I'm guessing the proper way to discuss this would be to make a draft type proposal? I still have some free time left on my holiday and I would love to develop that idea further :)

I'm aware of performance limitations; my goal is to rely on composition only as some kind of theoretical fallback while all performance intensive computation is done with code implementations. That way what I make can be "well-defined" and fast at the same time (ideally...). Virinas-code (talk) 21:38, 13 August 2026 (UTC)

Yes, that makes sense. Are you on IRC? #wikipedia-abstract is a very friendly and helpful group; if you're looking to make a new type, that would be a good place to get pointers. CMassaro (WMF) (talk) 09:36, 14 August 2026 (UTC)

Wikifunctions as a programming system

With lambda and half-of-an-eval, the runtime environment of Wikifunctions now resembles a somewhat less poor LISP. Whereas the runtime, as it stands now, is somewhat reminiscent of Smalltalk, Self and others, an object-oriented programming system. I wonder: how far/well the theory (in the sense of programming language theory, semantics and such) behind Wikifunctions have been developed, whether that has been documented somewhere (beyond Function model) or it still resides in the minds of the implementors for now, which direction you wish to develop this system and so on; where such discussions can take place.

Among the secondary goals is: Faster development of new programming languages due to accessing a wider standard library (or repository) of functions in a new dedicated wiki. For which we should have categorized and isolated the portion of functions (and objects), to be made available seperately as self-contained/sufficient collections, that are most relevant to implementing programming languages/systems. Has (if so, how much) there already been any work in this direction?

Since Wikifunctions aims to be natural-language- as well as programming-language-agnostic, it should be agnostic of any particular representation as well. Thus it should work with different representations (whether it's the underlying (JSON) representation of the objects, the specific choice of numberings, type system or even ontology) and be convertible among equivalence classes of representations (and conceptualizations?). It's this level of generality I'm quite interested about, and wish to have some in-depth discussion (here, insofar relevant to this project and elsewhere).

---

Smlckz (talk) 11:31, 12 August 2026 (UTC)

Hi @Smlckz! I am really interested in the viability of Wikifunctions as a programming system too, but I don't think you're in a for a great experience... While my experience here is quite limited, I worked a lot on a major issue that still bothers me: the composition language is incapable of basic arithmetic. If you look into Wikifunctions:Reserved ZIDs, you'll notice that there isn't any built in implementation for addition, subtraction, and there isn't even a builtin type for Natural numbers. This leads to quite a few fundamental issues, like the fact that the built-in Byte (Z80) depends on the non-built-in Natural number (Z13518)...

Strings aren't much better: the only core functions to manipulate them, [deprecated] -> Z22693 (Z886) and [deprecated] -> Z22683 (Z888) have been deprecated.

And while Wikifunctions:Function model is a great start it is out of date and is nowhere complete enough to be considered a proper specification. If you want any information as to how evaluation and the object model actually work you have to look into the Gitlab repos for the current implementation.

Last thing, the Get envelope from function call (Z823) function is a total breach of purity, and allows functions to get information about there own implementation, the environment they run in, etc. This can even be used, I believe, as a source of randomness.

I have great hopes that Wikifunctions will become a strong programming system one day, but as of now, it's far behind any other functional programming languages. Virinas-code (talk) 00:15, 13 August 2026 (UTC)

I hope that folks who are interested, like you two, can help with moving in that direction.

The development team is not focusing on that secondary goal currently. That shouldn't preclude anyone else from doing so.

How does Z823 break purity?

Honest question: do we need closure for anonymous functions, or is alpha conversion sufficient? --DVrandecic (WMF) (talk) 12:25, 13 August 2026 (UTC)

Sorry for the use of the maybe unclear term purity, I stole it from the Nix language :)

Purity would be the principle that the same inputs always return the same outputs, independently from the running environement. Get envelope from function call (Z823) does the exact opposite by literally giving you information about the outside environment. This constitues a source of randomness that I really do not appreciate from a theoretical standpoint, as it potentially introduces painful runtime errors (race conditions even, albeit only in extreme cases) which no one likes to debug.

I personally think that it is quite an useless function (4 uses in mainspace), but if people really want to keep it, I propose to restrict its usage to tests or make any function using it be marked as "impure" too.

To answer your last question, I don't really understand it --- I'm sorry for showing my lack of computer science basics here :') If you wish to explain it further, I'd be happy to give you my opinion.