Wikifunctions:Project chat/Archive/2023/08

Cannot create a new implementation for echo

When I try to create a python implementation for echo it errors with the following message: [51110bc3-51ff-4a61-af8e-731cd7cee917] Caught exception of type MediaWiki\Extension\WikiLambda\ZErrorException 0xDeadbeef (talk) 15:55, 1 August 2023 (UTC)

@0xDeadbeef Thanks for reporting! At what point in the process? I just tried it on the beta, https://wikifunctions.beta.wmflabs.org/view/en/Z11233 , and it worked there, so I am wondering when do you get that error message? -- DVrandecic (WMF) (talk) 16:05, 1 August 2023 (UTC)

Hi @DVrandecic (WMF): when clicking the "Publish" button at the last step. 0xDeadbeef (talk) 16:06, 1 August 2023 (UTC)

Resolved now. -- DVrandecic (WMF) (talk) 01:43, 3 August 2023 (UTC)

Sidebar

We need a link to this page (Wikifunctions:Project chat) in the site's sidebar, like on other projects. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:32, 1 August 2023 (UTC)

Done Quiddity (WMF) (talk) 22:40, 1 August 2023 (UTC)

DiscussionTools

What are the necessary steps to add the reply tool and the new topic tool to work on this page? I wasn't able to find any instructions from the extension documentation, so it would be great if someone with knowledge about the extension can help out. 0xDeadbeef (talk) 15:49, 2 August 2023 (UTC)

Reply tool should work fine. I just added the "Add topic" button for v22. Terasail^[✉️] 16:12, 2 August 2023 (UTC)

Thank you! Jdforrester (WMF) (talk) 19:48, 2 August 2023 (UTC)

Put the functions higher on the Main page

Hi, I was bold and pulled the list of functions to try out a bit higher on the main page. Feel free to revert it or to tell me to revert it, but I think that's the most interesting part of site. -- DVrandecic (WMF) (talk) 23:15, 2 August 2023 (UTC)

Implementation reordering currently deletes short descriptions

Tracked in Phabricator:
Task T343396

Heads up! On functions with more than one implementation, we have a system job that reorders the implementations based on runtime criteria. Unfortunately, that reordering is also currently deleting any and all short descriptions on the given function, which is bad. A workaround for now is to connect a Function to only one Implementation (since then no reordering happens). Sorry for the inconvenience! -- DVrandecic (WMF) (talk) 00:28, 3 August 2023 (UTC)

Done This is now fixed. Jdforrester (WMF) (talk) 13:42, 3 August 2023 (UTC)

Logo Favicon confusion

Tracked in Phabricator:
Task T326094

Six Wikimedia logos on Firefox tabs. Two are confusingly similar.

Seen in a row with other logos on Firefox tabs, as shown here, it is hard to distinguish, at a glance, this project's logo from Wikipedia's.

I wouldn't suggest a complete redesign, but perhaps we could give it some background colour, or a frame, to make it easer to differentiate them at small size? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:45, 3 August 2023 (UTC)

Thanks, I've added that issue into the existing bug about the favicon when using darkmode (T326094) although the issues may be split apart later. Quiddity (WMF) (talk) 21:03, 3 August 2023 (UTC)

Diffs

Are there any plans to improve the formatting of diffs, such that they're human readable? Wikidata has specialised diff formatting which uses human readable labels so that editors can understand what happened in a change. Here, diffs are all "Z11",{ "Z1K1": "Z11","Z11K1": "Z1002","Z11K2": ... which makes it all but impossible to understand what changed. Samwalton9 (talk) 10:02, 2 August 2023 (UTC)

Yes, this absolutely needs improvement! This is one of the tasks we bumped back in order to have a faster roll-out, and we are very much aware it needs improvement. Some tasks where we are collecting ideas and discussions are the following: T284473, T321204, T321205. You are absolutely right! --DVrandecic (WMF) (talk) 19:19, 2 August 2023 (UTC)

That's great - I assumed a solution similar to Wikidata would be the answer, so looking forward to that :) Samwalton9 (talk) 19:30, 2 August 2023 (UTC)

I've added this explicitly to Wikifunctions:Status so it's visible long-term once this page starts to get archived. :-) Jdforrester (WMF) (talk) 19:48, 2 August 2023 (UTC)

Initial edit request setup

FYI, I’ve just created Template:Edit request and Category:Wikifunctions protected edit requests. I imagine this will later be split into multiple categories depending on the required right, just like e.g. on Commons, but I wanted to start with a simpler version. Lucas Werkmeister (talk) 20:23, 2 August 2023 (UTC)

Might want to add {{Edit request}} to MediaWiki:Protectedpagetext (if this is the right page) so that people who want to make a request know the template exists. Terasail^[✉️] 20:32, 2 August 2023 (UTC)

Good idea, done. (Though this unfortunately disables all of MediaWiki core’s translations of that message, and they’ll have to be re-established on this wiki instead.) Lucas Werkmeister (talk) 20:37, 2 August 2023 (UTC)

Aliases rendering

Tracked in Phabricator:
Task T337384

See this link. The aliases displayed as of writing are "Never,Unreachable,Uninhabited,Bottom". Ideally they should be separated by spaces. 0xDeadbeef (talk) 18:20, 3 August 2023 (UTC)

Thanks for the bug report! That's tracked as part of T337384. Quiddity (WMF) (talk) 20:21, 3 August 2023 (UTC)

Wikidata sitelinks

It seems to be impossible to add a sitelink to Wikifunctions on Wikidata. I don't know if this is a Wikidata problem or a Wikifunctions problem, but it should be fixed (hopefully relatively soon, as it would be useful for synchronization). —‍Mdaniels5757 (talk • contribs) 18:40, 3 August 2023 (UTC)

Discussed on Wikidata, at d:Wikidata:Project chat#Wikifunctions. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:15, 3 August 2023 (UTC)

Yes, adding the wiki to Wikidata is planned work. See phab:T342857. I've added this to Wikifunctions:Status. Jdforrester (WMF) (talk) 20:08, 3 August 2023 (UTC)

Do test case inputs automatically trim?

Tracked in Phabricator:
Task T343608

I created a test case that checks whether a string is properly trimmed. See Remove Leading Spaces: only strip leading spaces (Z10092). Although I provided inputs with rounding spaces, but the contents in the reading view always do not show rounding spaces. MilkyDefer 08:16, 4 August 2023 (UTC)

They do not, but their display does. If you click on edit you can see they are still there. That's not great. I filed phab:T343608. Thanks for reporting! -- DVrandecic (WMF) (talk) 01:46, 5 August 2023 (UTC)

Functioneers can't change the return type of a function

title. Is this intended? 0xDeadbeef (talk) 10:08, 4 August 2023 (UTC)

Functioneers have wikilambda-edit-function-definition (edit a function definition) but not wikilambda-edit-running-function (edit a function definition of a 'running' function, i.e. one with connected implementations or test cases), as doing so will break them immediately for all users without warning.

You should disconnect the implementations and test cases, make the changes, and then fix and re-approve (if they work!).

Of course, there might be a bug where we think it's running when it's not – on which function did you find this behaviour? Jdforrester (WMF) (talk) 13:23, 4 August 2023 (UTC)

On function return type (Z10112), which has a connected implementation. 0xDeadbeef (talk) 13:39, 4 August 2023 (UTC)

Aha, OK, well, that's working "as expected" but clearly we should put some clearer warnings in place, both on the view page itself ("This is a running function, changes cannot be made.") but also when trying to edit anyway? Jdforrester (WMF) (talk) 13:54, 4 August 2023 (UTC)

function returning return type of functions

Tracked in Phabricator:
Task T343611

See get function return type (Z10114). It looks like this isn't currently supported. Will this be fixed soon? 0xDeadbeef (talk) 10:32, 4 August 2023 (UTC)

I think that should work, it's just the implementation is not connected yet. When I tried it out on the Beta, it worked fine (although the output format could be nicer, but that's one of the reasons why we don't officially support other types but strings and booleans yet).

There seems to be an issue with not being able to run the implementation because the "Run function" button is not active. I have filed task phab:T343611 for that specific part --. DVrandecic (WMF) (talk) 02:23, 5 August 2023 (UTC)

@DVrandecic (WMF): when I connect the implementation, it would always return void while returning an error. 0xDeadbeef (talk) 05:19, 5 August 2023 (UTC)

Cataloguing our functions

I see that the speed of function creation is picking up, so I created a very rough entry-point at Wikifunctions:Catalogue for us to highlight the important ones, and where to start thinking about new ones. Jdforrester (WMF) (talk) 20:08, 4 August 2023 (UTC)

Broken talk page links

Tracked in Phabricator:
Task T343588

Talk page links are, at least in the main name space, broken. The link from is a palindrome (Z10096) leads to https://www.wikifunctions.org/wiki/Talk:Z10096&uselang=en, which returns a 404. I have the interface language set to Swedish, if that has anything to do with is. / Autom (talk) 10:32, 5 August 2023 (UTC)

I get the same, with my language set to English. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:52, 5 August 2023 (UTC)

Reproduced. Seems like this is the case for every functions page. Deauthorized (talk) 02:23, 6 August 2023 (UTC)

Broken link labels

Tracked in Phabricator:
Task T343483

Hi. On the page Wikifunctions:Suggest a function, the labels displayed when we do a link to some ZObject have a strange behaviour. This morning (I’m in France, so UTC+2), before I edit the page for the first time, the label for join two strings (Z10000) was « sammanfoga ». After I edited the page, it becomes « join strings ». And a few minutes ago, the labels of the binary Boolean functions were in Polish. And when I clicked on the link with the Polish label, the page is entirely in Polish (the URL is https://www.wikifunctions.org/view/pl/Z10348, so it’s normal). What is not normal is that the language of the labels changed during the day. By looking at the history of the page, I found that when the page was displayed in Swedish, the last editor was Autom (I suppose their language preference is Swedish, as they have Swedish as native language). And when the labels were in Polish, the editor (at least of the section) was Msz2001, whose native language is Polish. By chatting with Poslovitch, it looks like he has the same problem. Lepticed7 (talk) 14:40, 5 August 2023 (UTC)

Yeah, I've reported the issue two days ago. It affects the display label and the link target language and remembers the last user who purged the page. (T343483). Msz2001 (talk) 15:17, 5 August 2023 (UTC)

Cannot create a function

When I use Special:CreateObject to try creating a function, I wasn't able to add an input type. (the "add an input" button appears to do nothing when clicked) Even when I try to publish the function without an input type, I got hit with an error message: "Disallowed root type". 0xDeadbeef (talk) 16:03, 1 August 2023 (UTC)

Just tried using this link: An input type seems to be already in place so it no longer has the input type button issue. (haven't tried adding a 2nd input though), but just when publishing (i.e. creating a function) I got hit by the same error message above: [c9768982-9244-4f30-829e-05d953a64bd0] Caught exception of type MediaWiki\Extension\WikiLambda\ZErrorException 0xDeadbeef (talk) 16:07, 1 August 2023 (UTC)

Thanks for reporting! Looking into it. -- DVrandecic (WMF) (talk) 16:14, 1 August 2023 (UTC)

Being tracked here: T343253 --DVrandecic (WMF) (talk) 20:52, 1 August 2023 (UTC)

0xDeadbeef: can you try again? --DVrandecic (WMF) (talk) 23:26, 1 August 2023 (UTC)

This works now, thanks. 0xDeadbeef (talk) 02:50, 2 August 2023 (UTC)

The scary thing is, we don't know *why* it works now. But, still, a careful celebration of the first function created by a volunteer is in order: Reverse String! Thank you! -- DVrandecic (WMF) (talk) 04:16, 2 August 2023 (UTC)

Example output needed

The documentation ("about" and "details" tabs) of, for example, join two strings (Z10000) has several examples of inputs, but no example output.

One example input is the pair of strings "Hello" and "World".

There is nothing to tell us whether the expected output is "Hello World" or "HelloWorld".

Can we add examples of expected outputs to function documentation? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:10, 3 August 2023 (UTC)

@Pigsonthewing: Agreed; for the Bengali label I specified that "Hello, " and "world" make "Hello, world", and set as a description the rationale for this test: that not only should an English sentence be output, but that this test case is this wiki's 'Hello, world' test. (More complex functions may not admit such simple labels/descriptions given the 100 character limit for both.) Mahir256 (talk) 16:08, 3 August 2023 (UTC)

Also note there is a planned (and near-term goal) long description feature (T260953) which should help with some of these issues, in particular the character limits of the label and short description fields. Quiddity (WMF) (talk) 20:13, 3 August 2023 (UTC)

Restrict types to strings and booleans

Hi all! Yesterday, I saw a first function, Turkish syllabication (Z10033), which should return a natural number, but instead returns a string. And I thought, well, OK, for that one function, let's maybe allow an exception? Now I took a look at Wikifunctions:Suggest a function, and I saw tons of suggestions for functions that would be better with other types than string and booleans.

Changing the signature of an established function will not be trivial. They might have several implementations, tests, might be embedded in other functions. We might build functions that are only needed because we don't have the proper types. In short, I think it is a bad idea. I would suggest that we should for now limit us to functions that are really just about strings and booleans. -- DVrandecic (WMF) (talk) 18:04, 3 August 2023 (UTC)

Just noting here that I believe this applies to some of the recently created functions such as Base64 encode and SHA-512 created by Ingenuity: they should ideally take an array of bytes as input. 0xDeadbeef (talk) 03:23, 4 August 2023 (UTC)

I'm confused by the expectation for typing in WikiFunctions. Are WikiFunction types meant to only be primitives, only types that are used by Wikidata, or may include compound types and restricted subtypes? Would a SHA-512 function have a special output type "SHA-512 hash" defined that is a subtype of "String" of a fixed length, fixed uppercase or lowercase hexadecimal character set, or would a SHA-512 function output a fixed length of bytes that is expected to then separately converted to a "String" should this be required? Dhx1 (talk) 04:11, 4 August 2023 (UTC)

This is probably up to the community to decide since the software would allow us to do this in either way. I think I would prefer to prevent any wrapping such as hexadecimals when it comes to functions like this. So SHA-512, to me, should take in a stream of bytes and output a fixed length of bytes. (in Rustspeak, this would be like fn sha512(bytes: &[u8]) -> [u8; 64]) 0xDeadbeef (talk) 04:41, 4 August 2023 (UTC)

Again, 0xDeadbeef is right: it is up to the community. Personally, I would prefer to have rather specific and semantic types (but I come from a background where I was trained in Ada95). We certainly will not limit us to the data types of Wikidata (in fact, Wikidata doesn't have a Boolean, for starters). Instead of the Wikidata quantity type, I would hope we would have a type for distances, one for durations, etc. If we do that, we will eventually be able to provide a lot of support when writing compositions, and we will be able to do powerful type checking (e.g. avoiding people adding up durations and distances). This will also allow us to capture more issues with validators early, and a better experience for in- and outputs.

So, I would really prefer to have a type for the 512 bits that SHA-512 returns, or "a 64 digits hexadecimal number" instead of that just being string.

But, as said, it is up to the community, and this is not my wiki, but ours. --DVrandecic (WMF) (talk) 01:04, 5 August 2023 (UTC)

Agreed with User:Deadbeef re the SHA-512 and related functions. -- DVrandecic (WMF) (talk) 00:52, 5 August 2023 (UTC)

Welcome template

Please help to expand, translate and use {{Welcome}}.

For inspiration, other projects' equivalent templates are:

• meta:Template:Welcome
• c:Template:Welcome
• d:Template:Welcome

-- Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:23, 3 August 2023 (UTC)

Where should translations be added? / Autom (talk) 20:06, 4 August 2023 (UTC)

I've (hesitantly) added translation markup to Template:Welcome/text, which @Nintendofan885 kindly copied and adapted from Wikidata's template. I'm not sure if anyone has very different ideas for what the content should be, but if folks are happy with the current content, then it should be stable enough to translate now. Thanks! Quiddity (WMF) (talk) 21:55, 4 August 2023 (UTC)

Next Wikifunctions & Abstract Wikipedia Volunteer's Corner on Monday 7

Hello all, this is a brief reminder that the next Wikifunctions & Abstract Wikipedia Volunteers' Corner will be held on August 7, at 17:30 UTC.

If you have questions or ideas to discuss, or you want to get in touch with the dev team, please join us in our first meeting after the launch of the project!

The meeting will be held, as usual, on Jitsi at the following address: https://meet.jit.si/AWVolunteersCorner.

See you there! -- Sannita (WMF) (talk) 10:45, 4 August 2023 (UTC)

Raw JSON editing

is there a way to do raw JSON editing without doing a fetch with the API sandbox? Currently the view with text boxes are quite limited. 0xDeadbeef (talk) 04:11, 6 August 2023 (UTC)

This is intentionally not supported, and the action=wikilambda_edit you reference is an internal API which might change without notice. If you can spell out your use cases, we (or you!) can file them in Phabricator to consider supporting them. Jdforrester (WMF) (talk) 13:16, 7 August 2023 (UTC)

Type proposals

We should have the following type constructors: Either(T, T) takes two types and returns the sum type of those two types. Maybe(T) or Option(T) can be represented as Either(T, Unit) or built-in, is the Maybe monad. With those the typed list type doesn't need to be built in anymore: it can be TypedList(T) = Maybe((T, TypedList(T))) (where the type passed to maybe is a 2-ary tuple) 0xDeadbeef (talk) 03:12, 2 August 2023 (UTC)

Yes, that would neat. We have a few tasks floating around about that. We first want to get to fixing typed lists, then generic types, and that will hopefully takes us to also have Maybe. One detail: is Maybe not rather Either(T, Nothing) instead of Either(T, Void)? --DVrandecic (WMF) (talk) 19:13, 2 August 2023 (UTC)

@DVrandecic (WMF): No. Maybe(T) isn't Either(T, Nothing). In fact, Either(T, Nothing) is actually just T itself, because since no instances of Nothing can be constructed, only the left variant of Either is possible. 0xDeadbeef (talk) 08:40, 4 August 2023 (UTC)

I should re-read a PL book. You're absolutely right, thanks for the explanation! -- DVrandecic (WMF) (talk) 00:33, 5 August 2023 (UTC)

Some relevant tasks: T287608, T282062, T290996. --DVrandecic (WMF) (talk) 19:16, 2 August 2023 (UTC)

Glossary

It would be good to make sure that everything in Wikifunctions:Glossary has a Wikidata representation. In particular, an item about "Abstract Content" would enable Wikifunctions' licensing to be better modelled there. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:32, 2 August 2023 (UTC)

Workaround for reverting edits

Current the undo feature does not work (phab:T335713). Here is a workaround:

• Go to a history version, such as https://www.wikifunctions.org/wiki/Z10000?uselang=en&oldid=1198
• The "Edit" link does not work correctly (phab:T343653). Now manually go to the edit interface of the old revision (https://www.wikifunctions.org/wiki/?action=edit&oldid=1198)
• The "Publish" button is disabled (phab:T343654). Changing any field and change back to enable it
• Now you can revert to an older revision.

GZWDer (talk) 10:44, 6 August 2023 (UTC)

Please do not try to break Wikifunctions, and please let's work on making it welcoming

Please don't try to push Wikifunctions to its limits, and try to see if you can break it. Please be gentle and kind to the project for now. As Wikifunctions matures, the site will become increasingly robust, but no one is being helped by taking the site down at this point. If you want to try out things and see where they break, do so on the instance of Wikifunctions running on the beta cluster. There are a currently quite a few pages in this wiki which would look very confusing to people coming in to explore. Let's make this site more welcoming. -- DVrandecic (WMF) (talk) 06:15, 8 August 2023 (UTC)

Tracked in Phabricator:
Task T343291

It would be nice if I could experiment on the beta cluster, but currently I can't login to the beta site. 0xDeadbeef (talk) 06:28, 8 August 2023 (UTC)

Indeed! I wasn't aware of that one (I am behind on triaging bugs). Thanks for bringing it up. I have just triaged that task up, and hopefully we'll get to fix it soon. -- DVrandecic (WMF) (talk) 06:39, 8 August 2023 (UTC)

(This was fixed a few hours ago.) Jdforrester (WMF) (talk) 12:35, 8 August 2023 (UTC)

AbuseFilters

Although global abuse filters do apply here, and these protect against the majority of filterable abuse, some WikiFunctions-specific ones may need to be created in the future. I have therefore created Special:AbuseFilter/2 (a public test filter) and Special:AbuseFilter/3 (a private test filter). I've also created a log-only filter to capture the use of eval() (with a view that this could be expanded to cover similar "sensitive" function calls). — TheresNoTime (talk • they/them) 12:28, 8 August 2023 (UTC)

Thanks a lot! Hopefully they won't be needed. Sannita (WMF) (talk) 12:48, 8 August 2023 (UTC)

RTRC

Can we pleaes install m:RTRC as a local gadget? I am using this tool in a few wikis and it might be useful for patrolling here as well. --Ameisenigel (talk) 16:08, 10 August 2023 (UTC)

@Ameisenigel Done. Note that ORES is not available on Wikifunctions (yet?), so that functionality will not work. —‍Mdaniels5757 (talk • contribs) 23:55, 10 August 2023 (UTC)

Thank you! --Ameisenigel (talk) 06:08, 11 August 2023 (UTC)

This section was archived on a request by: Ameisenigel (talk) 06:08, 11 August 2023 (UTC)

Hello, world!

Welcome everyone! This is a welcoming thread for everyone who just joined Wikifunctions. We're happy to see you here, and we hope that many edits will follow your first! --Sannita (WMF) (talk) 09:50, 27 July 2023 (UTC)

Hi! 0xDeadbeef (talk) 15:54, 1 August 2023 (UTC)

Hello --Nintendofan885^{T&Cs apply} 16:35, 1 August 2023 (UTC)

How are you gentleman? All of your bases are belong to us. --Lopullinen (talk) 14:03, 2 August 2023 (UTC)

Hello Wikifunctions. PAC2 (talk) 13:23, 3 August 2023 (UTC)

Too late... Hi! Zalán Hári ^{talk page} _{Let's edit!} 03:11, 4 August 2023 (UTC)

Hi, I followed the development newsletters for a while, trying to figure the project out now. Papuass (talk) 10:11, 4 August 2023 (UTC)

Regards, ZI Jony ^(Talk) 17:43, 4 August 2023 (UTC)

Glad to finally see a site without beta in the title ;) Kristbaum (talk) 09:38, 5 August 2023 (UTC)

Been following this for a while, even made an account right when the site came up. Cool to see it up and running now. Deauthorized (talk) 19:54, 6 August 2023 (UTC)

Hello all, good job!! Arnaugir (talk) 10:01, 8 August 2023 (UTC)

Hi everyone! Nadzik (talk) 10:50, 8 August 2023 (UTC)

Hallo! Kghbln (talk) 18:40, 8 August 2023 (UTC)

Oups, didn’t see that. Bonjour ! Lepticed7 (talk) 18:42, 8 August 2023 (UTC)

🌝 --Wolverène (talk) 12:13, 9 August 2023 (UTC)

Hi hi hi! Sdkb (talk) 03:33, 10 August 2023 (UTC)

ਸਭ ਨੂੰ ਸਤਿ ਸ੍ਰੀ ਅਕਾਲ KuldeepBurjBhalaike ^(Talk) 07:46, 10 August 2023 (UTC)

Several issues when trying to create composition implementations

1. When I go to this link to create an implementation for the echo function, I select "Composition", change the type to "Argument reference", enter "Z801K1" as the key ID. From the right sidebar all tests pass. However, the publish button on the top right does not respond to my clicks. (I can't actually publish this as an implementation)
2. When creating an implementation for "string is empty" function, it looks like I am not able to make an implementation based on the String equality function and an empty string as the other argument. More specifically, the argument selector for the other argument to the String equality function does not appear when String equality is selected as the function.

0xDeadbeef (talk) 15:49, 2 August 2023 (UTC)

1. That is weird. I get the same behaviour. Filed this as T343393.
2. I cannot replicate this behaviour though, that seems to work for me. I get two arguments for String equality, one named First String, the other Second String.

DVrandecic (WMF) (talk) 23:35, 2 August 2023 (UTC)

Done @0xDeadbeef I've deployed a fix for T343393, which should now be fixed. Thanks for finding the issue! Jdforrester (WMF) (talk) 17:04, 3 August 2023 (UTC)

@Jdforrester (WMF), @DVrandecic (WMF): I just found a necessary step in replicating #2. First you need to try creating an implementation, but the first thing you have to do is use the pencil icon in the about section to add a label. After you add a label, then selecting a function for composition stops working. 0xDeadbeef (talk) 03:36, 4 August 2023 (UTC)

Sorry, I still cannot reproduce this error (and I tried with several accounts with different rights, even logged out). Here's what I am doing:

Screenshot

1. go to https://www.wikifunctions.org/w/index.php?title=Special:CreateObject&uselang=en&zid=Z14&Z14K1=Z10008
2. click on the pencil
3. in the field under "Labels (optional)" enter "test composition"
4. click Done
5. click the red "Select Function"
6. in the field under "Function" type "string equa"
7. select the function "string equality"
8. it shows me two more fields, one labeled "First String", the other "Second String"

I uploaded a screenshot of my state at this point, see on the right. -- DVrandecic (WMF) (talk) 02:00, 5 August 2023 (UTC)

Huh. I tried it again and it worked now. Maybe this is a device issue. I will look into this and report if this issue pops up again. 0xDeadbeef (talk) 05:13, 5 August 2023 (UTC)

Thank you! -- DVrandecic (WMF) (talk) 06:55, 5 August 2023 (UTC)

Now another issue related to this: if selecting "implementation: code", the name and their inputs have their corresponding ZIDs that can be copied. But when selecting "implementation: composition", those ZIDs disappear. 0xDeadbeef (talk) 09:42, 4 August 2023 (UTC)

Tracked in Phabricator:
Task T343605

We are missing one other part of the code: argument references really shouldn't have to copy and paste the ZID, but since we know all possible arguments, we should just let you select them (we have a task for that, phab:T336985. So you wouldn't need the ZID here. Unfortunately it is in a weird in between state right now, which is not cool. Sorry! I filed phab:T343605 in order to improve the situation you are describing rather sooner than later. Thanks for reporting! -- DVrandecic (WMF) (talk) 00:44, 5 August 2023 (UTC)

Function and implementation metadata

This is something we need, as it would help with tracking function signatures that can be improved, tracking time/space complexity of implementations, and etc. 0xDeadbeef (talk) 16:27, 5 August 2023 (UTC)

Can you explain what you mean by 'meta-data'? Jdforrester (WMF) (talk) 13:16, 7 August 2023 (UTC)

perhaps something like maintenane categories, e.g. "functions needing optimization", "suspected incorrect implementations". Ijon (talk) 06:05, 8 August 2023 (UTC)

The format of test cases is underspecified

Currently, there's no way to add a test case to K combinator (Z10249) without having a "call function and is returned string equals" function. (If you can, then that's great!) This is, if I understand correctly, a limitation of the way test cases are currently represented. Can the validator field of a test case be an actual function (instead of Function call (Z7)) that takes the output of the test case as an argument? That would be great after the experience of creating inline functions is improved. 0xDeadbeef (talk) 17:41, 5 August 2023 (UTC)

We currently do not support functions that return something else then a string or a boolean.

Having said that, a function such as the K combinator, would need to have a special testing function written, for example a function with the signature function x, object y, object z -> boolean, with an implementation of equality(apply(x, y), z). x would be the return of the function call. This could be used for some of the other combinators as well. Another option could be that the function call for the test is not just k combinator(k) but rather k combinator(k)(y), and the testing function is equality(_, k).

All of this also assumes that we would have an equality for objects, which I do not expect. -- DVrandecic (WMF) (talk) 05:12, 8 August 2023 (UTC)

@DVrandecic (WMF): the second option (function call for the test be k combinator(x)(y)) is presently impossible to create in the editor we have. The issue is that the editor doesn't know what arguments the function returned by k combinator takes.

Speaking of this, why can't the type of a function record its input list of types and its output type? Even if we want generic functions, we can have abilities of dynamic dispatch, or emulating generic functions by giving type arguments. For example a generic add two values functions could be a function constructor that first takes the type of the values as input and then returns a function that takes two values of that type as input. 0xDeadbeef (talk) 05:51, 8 August 2023 (UTC)

As stated previously, the user interface currently works for strings and booleans. If you like to try out other types, I would prefer you do so on the betacluster.

Yes, agreed, it would be better if the type was not just function, but if it were to include the signature as well, agreed. This is not implemented yet. There are still ongoing discussions around that topic. -- DVrandecic (WMF) (talk) 06:10, 8 August 2023 (UTC)

MUL labels with math symbols only

Some functions resebmle math operations and thus have their international symbols. What about using those as multilingual (mul language code) labels for functions and test cases? Like I've just done in negation's test cases: Z10512 and Z10513 (at the moment they don't show up as a fallback anywhere, though) with labels ¬1 = 0 and ¬0 = 1. Msz2001 (talk) 11:03, 6 August 2023 (UTC)

Sure, but be aware that maths notation is not wholly language independent, like primes/bars for derivation, decimal comma/dot and the different thousands separators and various grouping schemes.

Some examples in Swedish: 20*500 = 10' (in finance), 10.000 (tabulated) or 10 000 (in a sentence). 123.456,789 (Swedish) = 123,456.789 (English). /Autom (talk) 15:08, 11 August 2023 (UTC)

How to handle invalid function inputs?

As asked here, how should an invalid input to a function be handled by the function? This does not appear to be documented. Can the function raise an exception for the invalid input, return null, something else? Dhx1 (talk) 13:28, 6 August 2023 (UTC)

It should raise an error. We need to document how to create errors. This still needs a bit of refinement. -- DVrandecic (WMF) (talk) 05:13, 8 August 2023 (UTC)

I was under the impression that the first class errors are ones that are fatal enough to end execution. Wouldn't an Either<Value, Error> sum type work in this case? 0xDeadbeef (talk) 05:59, 8 August 2023 (UTC)

Inputting a prime a prime number into a function that calculates the greatest common divisor would not throw a built-in exception. Likewise en_pluralize( "feet" ). /Autom (talk) 15:15, 11 August 2023 (UTC)

Plan for function categorization?

Is there a plan for categorization of functions? Bamyers99 (talk) 14:28, 7 August 2023 (UTC)

For mathematical functions, we could follow the Digital Library of Mathematical Functions. --Daniel Mietchen (talk) 22:00, 7 August 2023 (UTC)

Hi both, there's an entry about that in the FAQ at Wikifunctions:FAQ#How do we sort or categorize functions? - i.e. discussion is needed, and thank you for starting one!

Do we all want to follow Wikidata's model of using Talkpages and Project-namespace pages for categorization, or request some sort of specific feature in the WikiLambda extension, or something else?

Note: There is already this new page, Wikifunctions:Catalogue, for now. -- Quiddity (WMF) (talk) 22:01, 7 August 2023 (UTC)

Hi @Quiddity (WMF): I think some sort of key-value storage per-function and per-implementation would be nice, for example how would we record the fact that this function is the inverse of another function? See also #Function and implementation metadata. 0xDeadbeef (talk) 05:39, 8 August 2023 (UTC)

You can now edit labels on non-function objects

Hi all! As of today, you can now freely edit and translate labels on non-function objects without being a functioneer.

Also remember that translating documentation is one of the very basic - and very appreciated! - tasks that you can meanwhile undertake on this website. Sannita (WMF) (talk) 17:26, 7 August 2023 (UTC)

Thank you! Wd-Ryan (talk) 17:47, 7 August 2023 (UTC)

Thanks. Still discovering how it works.TaronjaSatsuma (talk) 10:25, 8 August 2023 (UTC)

Add Special:CreateObject to sidebar

In Wikidata Special:NewItem is shown in sidebar. I propose to add the Wikifunctions equivalent, Special:CreateObject to sidebar. This requires an edit of MediaWiki:Sidebar by admin (example). GZWDer (talk) 17:58, 7 August 2023 (UTC)

This feels premature? Most users, even logged-in ones, will not be able to use this link for weeks at best, possibly longer.

Also I suggest that it is better to add specifically a link to Special:CreateObject?zid=Z8 instead; the plain special page is more like Special:NewProperty. Targetted new-implementation and new-test case links are already on the function pages, which is the expected behaviour path. Jdforrester (WMF) (talk) 18:08, 7 August 2023 (UTC)

Hi. I did added it as a link in the toolbox using my personal js file. If you want to copy, it’s User:Lepticed7/common.js. Lepticed7 (talk) 17:40, 8 August 2023 (UTC)

Let's don't hardcode a specific locale in Wikifunctions

I think the case in Talk:Z10047 and Talk:Z10018 worth more community attention so let me bring a bit more context before echoing it,

For years I was roughly disappointed the way Lua modules were developed in English Wikipedia, they [understandably] didn't have considerations for other languages, locales that don't use Arabic numerals (0123456789) but other numerals (e.g. ۰۱۲۳۴۵۶۷۸۹), or couldn't easily modified to use a different kind of comma or text direction and so on. And in order to use essential Lua modules in our local Wikis we had to make forks of them and have the maintenance cost of local changes we had to apply to the modules in order to make them to suit our language. See this and this about the English Wikipedia case.

So as a new community let's get such considerations right. I don't like to label this attempt with broader terms like 'decolonization' but I like to be specific about it, let's consider technical needs of people with different languages right from the beginning and reduce the pain smaller languages will have to use functionalities provided by this community.

So let's don't hardcode a specific locale in Wikifunctions. −ebrahim^talk 19:41, 7 August 2023 (UTC)

Whole-heartedly agreed!

Although I would see that the label might make some default assumptions, but that's up to the community. E.g. I could see that the Bulgarian label for a function that returns uppercase Cyrillic output is simply called "uppercase" in Bulgarian, whereas the one for latin letter is called "uppercase Latin letters" in Bulgarian, etc. But that's really up to local naming conventions.

But most certainly, we should have functions for different numerals, or functions that can deal with several different numerals, etc. Everything else would be very disappointing. -- DVrandecic (WMF) (talk) 05:18, 8 August 2023 (UTC)

In the case for turning strings to upper case and lower case, they can work without a locale. With the test cases I added, it looks like both javascript and python use the standard unicode way for mapping letter cases. 0xDeadbeef (talk) 05:37, 8 August 2023 (UTC)

User:DVrandecic (WMF): Thank you! I believe we can head for one upper/lower function that takes both the input text and locale, like this. Creating one function for Latin will encourage incorrect use of it over the generalized and well thought one. Programming languages may have a default locale unaware case conversion as they root to decades ago where these weren't that known but I say let's get it right this time in this community.

User:0xDeadbeef: Considering cases like this or "The special casing conditions associated with case mapping for Greek, Turkish, and Lithuanian are specified in an additional field in SpecialCasing.txt" part in your link, changing cases without a locale is just considering English as the locale and that's what I want to be avoided in this community, having of an implicit default locale. −ebrahim^talk 06:12, 8 August 2023 (UTC)

@Ebrahim: I understand your concern, and I agree that to be language specific one would use a function that accepts locale. The no-locale functions use "locale invariant upper case mapping" from unicode, not latin. See this. 0xDeadbeef (talk) 06:22, 8 August 2023 (UTC)

@0xDeadbeef: Isn't 'locale invariant' in this case to have best effort function that works in different scripts but whenever there is multiple choices it uses English as the locale, I just want to have that be avoided here.

For example in Android programming linter will complain if you use the default locale implicitly, https://stackoverflow.com/q/13444546 somehow I like to propose the same thing here. −ebrahim^talk 06:39, 8 August 2023 (UTC)

@Ebrahim: This is a Java problem. Java only implements locale specific case mapping. this doc says so. 0xDeadbeef (talk) 06:51, 8 August 2023 (UTC)

@0xDeadbeef: The same goes for popular libc implementations also, 'atof' is locale sensitive and you have to do some more thing to have a fixed locale with it (either 'setlocale' or _l counterparts). I believe we can agree on 'locale insensitive' or implicit 'locale sensitive' were both unfortunate things of the past and happened due to legacy these system had to support, let's just get it right this time and make the locale explicit all the times and even providing that 'locale insensitive' conversion (which basically takes one locale as the default) as a special case of the correct explicit locale aware implementation. −ebrahim^talk 07:13, 8 August 2023 (UTC)

@Ebrahim: I think there are times where locale isn't important and having locale invariant case conversions would be perfectly fine. We just need to be careful when using locale invariant functions. Are you suggesting that we should delete the locale invariant case conversion functions? 0xDeadbeef (talk) 07:44, 8 August 2023 (UTC)

@0xDeadbeef: I believe that mindset of most of the times locale doesn't matter and things are perfectly fine is what hurting smaller languages and what I tried to give different examples on different places on how this went bad. Don't you agree 'locale invariant' is just choosing the popular locale the default one? My solution isn't that different from what Android linter does, it discourages use of default option the far possible, makes the lines yellow and makes programmer aware they need to do something different. Guess call it 'deletion' makes it too dramatic, I just want it to even that "locale invariant" explicit, a special case of a correct locale aware interface, an API should encourage correct uses and discourages misuses. −ebrahim^talk 08:00, 8 August 2023 (UTC)

I'm perceiving this as a solution in search of a problem. For the record, I don't hold the mindset that "most of the times locale doesn't matter". Most of what I program don't involve handling region/language specific input, so I personally only use locale invariant functions or even function that only does ASCII case conversions. I don't think there is a middle ground here. Either we are discouraging the use of locale invariant case conversion, or we aren't. If we are, either via deletion or via some sort of warning like you suggested, we are essentially saying, "if you actually want locale invariant conversion, go use the more complicated to uppercase with locale(string, root locale)" instead.

I think it is important to be reminded that locale specific content should be treated carefully. To me, the problems you described are more of a "ignorance of developers handling content" than a "locale invariant case conversion is too easy to write". If parsers for programming languages are to be implemented on wikifunctions, I'd imagine several parsers such as SQL with case insensitive syntax use locale invariant case conversion. I would prefer if a warning isn't issued for them since it makes it easier. In the future, when we have categorization of functions, we could implement this as some sort of wikidata constraint, where a function must be specified as locale agnostic for any implementation to use the locale invariant functions.

From what I have read, "locale invariant" doesn't choose the most "popular" locale (anglocentric people might say that would be "en-US") but the invariant locale is actually the "root locale" which is supposedly what all locales are based on. (I guess you could call that "popular") And also, having a convenient to uppercase function might better help us identify problematic editors (hopefully I don't become one of the problematic editors) who handle inter-regional content without care, since doing it properly would involve a lot of considerations in different specific places, and it isn't just limited to locale invariant case conversions. 0xDeadbeef (talk) 08:33, 8 August 2023 (UTC)

┌─────────────────────────────────┘
Most of the times things written in different places in Wikipedia will end up involving handling of region/language also so this isn't like 'a solution in search of a problem' but let's prioritize the basic API design goals we don't end up having the same problem smaller languages have experienced before. A general thing like w:Module:Coordinates that is written for English Wikipedia, understandably, doesn't have much support for other languages so for adopting in our local fa:Module:Coordinates, in addition to simpler string translation, we have to keep a good number of changes to make it possible to parse and print different kind of numerals also. In the specific case of changing case of 'I' to 'i' or Turkish 'ı', I wish it could acted more like least common denominator and wasn't just touching this specific letter so one could more confidently avoid calling it the term popular and just call it locale invariant. −ebrahim^talk 10:21, 8 August 2023 (UTC)

Hi. I completely agree with ebrahim. I discussed another example with 0xDeadbeef here about anagrams. I think that to avoid languages and regions biases, functions handling localisable strings should always have a locale as a parameter. And the "popular"/"en-US" version of this function could be just a call to the more general function, with the good locale. Lepticed7 (talk) 18:06, 8 August 2023 (UTC)

I agree here. I suppose that if a function treats a string more or less as a stream of code-points (e.g. checking for in/equality, skipping some elements etc.) it may be reasonable to call them locale-invariant. On the other hand, when we rely on some properties of a character, we should really make locale-specific versions. Even when operating at the very ASCII level, we can have a situation like en:IJ_(digraph)#Capitalisation, where Dutch IJ is capitalized as if it's a single letter, e.g. IJsselmonde. And what about Greek sigma that has one uppercase and two lowercase versions (middle and trailing variants)?

If the string manipulations are going to be used eventually to generate actual articles read by actual people from all over the world (even if the world for us is TOP 20 languages), they will not be perfect for any of the languages. And the generated content will seem to be created carelessly.

I think that before we can use proper Monolingual text (Z11) arguments, we should at least try to have as many test cases from different alphabets as possible. Even if they would fail – this would give us information what to do (eiher now or when it's possible and realistic). Lorem ipsums are the boring stuff that's guaranteed to work under any circumstances, but what about Zażółć gęślą jaźń, for example? Msz2001 (talk) 19:53, 9 August 2023 (UTC)

Notability

I think we probably can reach to some sort of agreement around what sort of function we like more to have. My initial feeling about remove all characters except ASCII digits, uppercase Latin letters and lowercase Latin letters (Z10171), why latin characters are special and characters from other scripts and languages should be removed by this function, I fear that will be abused to make issues for smaller languages like this, and about remove regular spaces (Z10052), I think removing space from any part of a string is as arbitrary as removal of any other character from a string, meanwhile I feel Trim String (Z10079) can be useful as it's also already offered by standard libraries of python and javascript so maybe we can draft an initial notability policy based on these [probably inaccurate] observations, something like whether a function is provided by some popular library or it can be shown it will be used by abstract wikipedia. −ebrahim^talk 21:13, 7 August 2023 (UTC)

Maybe the policy should be written around applicability , utility , and re-usability rather than "notability"? Jdforrester (WMF) (talk) 21:20, 7 August 2023 (UTC)

See Wikifunctions:Notability for a draft.--GZWDer (talk) 21:25, 7 August 2023 (UTC)

GZWDer: Excellent, this more or less has what I had in mind also.

Jdforrester, GZWDer: Given the draft and concepts you've mentioned, do you have any comment about the cases I've brought above. I can even feel they can have some use but no more than any other arbitrary function so I like to see how we can form and apply a policy around these two. −ebrahim^talk 21:42, 7 August 2023 (UTC)

@Ebrahim, @GZWDer: I've written some very quick thoughts at Wikifunctions:Valuable which might be helpful? Jdforrester (WMF) (talk) 12:34, 8 August 2023 (UTC)

@Jdforrester (WMF) Hi. I’m not sure to completely understand the first example of Wikifunctions:Valuable. For example, consider a function that takes an Esperanto root and returns a dictionary of the different declensions (e.g. "{'ns': 'pomo', 'np': 'pomoj', 'as': 'pomon', 'ap': 'pomojn'}" with 's' is singular, 'p' is plural, 'a' is accusative and 'n' is nominative). Is this the kind of functions targeted by your first example? Lepticed7 (talk) 18:15, 8 August 2023 (UTC)

Yes, that's a great example of a good function if given the right type; it should take an Esperanto-typed string (Monolingual text (Z11) with its language/Z11K1 set to Esperanto (Z1576)) and reply with a WikiLexeme dictionary data structure that declares its output to be in Esperanto. What it shouldn't do is take a string and reply with a string, and we probably should have an upper-level function "getDeclination" (or whatever), that takes any language-typed string (Z11), and calls the Esperanto-specific one when it sees the user's input is in Esperanto.

Does that clarify? Jdforrester (WMF) (talk) 18:29, 8 August 2023 (UTC)

Ok. Yes, that’s clear. Thanks ! Lepticed7 (talk) 18:32, 8 August 2023 (UTC)

Conventions for code?

This is probably the most annoying thing when it comes to coding. AFAIK, our function implementations are all written in Python and JS since we only support those two for the time being. Will we follow predefined conventions like PEP8 and airbnb/javascript or set our own conventions?

Personally speaking, I'd much prefer it if I don't have to follow MediaWiki's conventions. Spaces inside brackets? No thanks.

NguoiDungKhongDinhDanh (talk) 07:21, 8 August 2023 (UTC)

Some, such as JavaScript unary false (Z10218), are written using arrow function/lambda syntax. This, presumably, is no different than function Z10218() { return false; }, but I still prefer "the old way" as it looks more formal. NguoiDungKhongDinhDanh (talk) 07:39, 8 August 2023 (UTC)

From my limited experience in frontend interviews I can tell that there is a difference between arrow function and named function in Javascript. Although I don't know whether that really matters in Wikifunctions system. MilkyDefer 14:56, 8 August 2023 (UTC)

I'd certainly be against oneliners that are difficult to maintain and understand when coming to the code after some time. And whitespace doesn't hurt (in my opinion things like JavaScript negation (Z10220) would be more readable with spaces). Msz2001 (talk) 17:56, 8 August 2023 (UTC)

I don't see what we gain by keeping it short: abbreviated variable names might become too cryptic or misinterpreted, consistent use of whitespace aids in finding matching brackets and variables in an otherwise dense line of code, and lambdas are marvelous tools for code obfuscation. Like Wikipedia, we have no size limit, and it is my opinion that pointless brevity would harm our other goal of being open and approachable.

For me, any standard promoting consistency and readability would do. I would be in favor of adopting the Wikimedia guidelines for both Python and JS.

/ Autom (talk) 20:35, 8 August 2023 (UTC)

Minify and prettify function when? :) Wd-Ryan (talk) 21:40, 8 August 2023 (UTC)

Actually, our parameters are already as cryptic as they might be. I, for one, have no idea why Wikifunctions developers chose Z10012K1 and whatnot as parameter names. Wouldn't it be better if we can use our own custom names and map them back using whatever in the WF system that is equivalent to a hashmap?

Which convention is actually not too important, since code formatting is a solved problem. We can take our time fighting our glorious holy war of tabs vs. spaces.

NguoiDungKhongDinhDanh ^talk 03:45, 9 August 2023 (UTC)

Well, we're not mandated to use them and the system is going to function properly (see JavaScript negation (Z10220) for example). The issue is multilinguality. While it'll be impossible with code that's defining new variables, I feel like using the key ids (or at least K1 without the Z-part) is reasonable here. Msz2001 (talk) 19:56, 9 August 2023 (UTC)

@Msz2001: I'm not so sure about that. JS doesn't have keyword arguments (only something functionally equivalent: function foo({ bar, baz, qux }) {}), but Python does, and a function can even enforce an argument to be keyword-only:

def foo(positional_only, /, positional_or_keyword, *, keyword_only): ...

How would the arguments be resolved in that case without an explicit map? Or are we going to disallow keyword-only arguments altogether?

NguoiDungKhongDinhDanh ^talk 00:41, 10 August 2023 (UTC)

@NguoiDungKhongDinhDanh: See here and here, but this may change in the future. GZWDer (talk) 15:39, 10 August 2023 (UTC)

@GZWDer: Thanks. If I'm reading it correctly, argument_list=",".join(argument_names) goes to nowhere; there is no such format argument in _FUNCTION_TEMPLATE. Aside from that, am I correct in saying that our implementations will have access to _BOUND_VALUES, _DESERIALIZE and _SERIALIZE as well? NguoiDungKhongDinhDanh ^talk 18:08, 10 August 2023 (UTC)

These are internal function and subject to change. Use of them is not recommended. GZWDer (talk) 18:10, 10 August 2023 (UTC)

@GZWDer: I'm not saying that I will use them, but that this might be a security hotspot. NguoiDungKhongDinhDanh ^talk 06:50, 12 August 2023 (UTC)

Is Reviewing a thing yet?

I created a function, implemented it in JS, and added tests. It is ready for review. The review link leads to Mediawiki, with only a very generic statement that people with the privilege can review the function. Is there a process yet on Wikifunctions, or is there no point yet in initiating reviews? Ijon (talk) 10:53, 8 August 2023 (UTC)

@Ijon: you have the ability to approve implementations and tests yourself. That being said, this function would be better if it accepted a single character (awaiting more types support) as input. 0xDeadbeef (talk) 11:31, 8 August 2023 (UTC)

Thanks, I didn't realize I could approve my own code; my understanding was the point is to also benefit from peer code review... But for now, I'll approve it and continue building some code around Hebrew.

And yes, obviously it should take a single character, but since single characters or even codepoint integers, aren't supported yet, I implemented it this way for now. Ijon (talk) 11:44, 8 August 2023 (UTC)

A codepoint type is planned, but not yet supported.--GZWDer (talk) 11:49, 8 August 2023 (UTC)

An alternative to testing code point ranges is testing for a Unicode character class in a regex. ie.

return /^\p{scx=Hebrew}/u.test(Z10561K1);

--Bamyers99 (talk) 19:22, 8 August 2023 (UTC)

Various implementations by composition?

Hi. I created and implemented some of the binary boolean functions, and when it came to implementation by composition of Boolean Not Right (Z10306), I chose to implement it as the negation of Boolean Right (Z10298). But I also had the idea to implement the function without using Boolean Right (Z10298), and just negating the second argument. It would have given something really similar to Composition Binary Right (Z10304). And I was wondering which implementations should I prefer? Or maybe, should I create both implementations: the one that uses another, simpler, wikifunction, and the one that does not use it? What do you think about that? Lepticed7 (talk) 18:39, 8 August 2023 (UTC)

@Lepticed7: The software will of course allow whatever you would like to do: creating both implementations, or choosing one implementation over the other. The real question is what exactly should we do? WMF has conveniently laid down some puzzle pieces for us to figure it out, like Wikifunctions:NOT. I'm not going to express my preference on what to do here, as it may or may not matter depending on the response I get from this section. 0xDeadbeef (talk) 13:43, 10 August 2023 (UTC)

Can the NTV notation (name, type, value) and its JSON representation be useful for this project?

I am not familiar with Wikifunctions but reading the glossary, I have the impression that the notion of type corresponds to that developed in the NTV project and that the associated JSON representation could be useful.

NTV structure

An NTV entity is a triplet with one mandatory element (the value in JSON format) and two optional elements (name, type).

For example, the location of Paris can be represented by:

• a name: "Paris",
• a type: the coordinates of a point according to the GeoJSON format,
• a value: [ 2.3522, 48.8566]

The easiest way to add this information into a JSON-value is to use a JSON-object with a single member using the syntax JSON-ND(https://github.com/glenkleidon/JSON-ND) for the first term of the member and the JSON-value for the second term of the member.

For the example above, the JSON representation is:

{ "paris:point" : [2.3522, 48.8566] }

With this approach, two NTV entities are defined:

• a primitive entity which is not composed of any other entity (NTV-single),
• a structured entity which is an ordered sequence of NTV entities (NTV-list).

as well as two JSON formats:

• simple format when the name and the type are not present (this is the usual case of CSV data),
• named format when the name or type is present (see example above for an NTV-single entity and below for a structured entity).

Example of an entity composed of two other entities:

{ "cities::point": [[2.3522, 48.8566], [4.8357, 45.7640]] } for an unnamed NTV-list entity

{ "cities::point": { "paris":[2.3522, 48.8566], "lyon":[4.8357, 45.7640] } } for a named NTV-list entity

The type incorporates a notion of `namespaces` that can be nested.

For example, the type: "ns1.ns2.type" means that:

• ns1. is a namespace defined in the global namespace,
• ns2. is a namespace defined in the ns1 namespace.,
• type is defined in the ns2 namespace.

This structuring of type makes it possible to reference any type of data that has a JSON representation and to consolidate all the shared data structures within the same tree of types.

NTV and JSON properties

• each NTV object has a unique JSON representation,
• each JSON data corresponds to a unique NTV entity,
• an NTV entity is a tree where each node is an NTV entity and each leaf an NTV-Single entity,
• an NTV entity is a neutral representation (independent of a software or hardware platform),
• any entity that has on the one hand a function of encoding it into a json value and on the other hand a function of creating from a json value can be taken into account (this approach is very general because the majority of computer objects are defined by a list of parameters (e.g. *args in python) and/or a list of key/values (e.g. **kwargs in python) which simply translate into a JSON-Array or a JSON-Object).

link to the NTV project : https://github.com/loco-philippe/NTV#readme Thomy philippe (talk) 22:24, 8 August 2023 (UTC)

@Thomy philippe: see Wikifunctions:Function model 0xDeadbeef (talk) 01:54, 9 August 2023 (UTC)

Shortcuts

Tracked in Phabricator:
Task T342964

Wikipedias have WP, Wiktionaries WT, Wikivoyages/Wikiversities WV, Wikidata WD and Commons COM. I feel like we too should have something like that, since "Wikifunctions" is clearly a handful. How about WTF? That would be a nod to the well-known measurement of good code: WTFs/min. NguoiDungKhongDinhDanh ^talk 04:07, 9 August 2023 (UTC)

The alias is going to be WF, it just needs some additional code for the redirection to work. Msz2001 (talk) 05:11, 9 August 2023 (UTC)

WF and WT are now working — e.g. WF:Main Page and WT:Main Page — TheresNoTime (talk • they/them) 14:57, 9 August 2023 (UTC)

Is Wikifunctions just a stepping stone for Abstract Wikipedia?

Or rather: How much freedom do we get as a community for defining the scope of Wikifunctions?

Picture this: a contributor frequently adds various implementations/functions related to popular/interesting algorithms, that are of very little importance/usefulness to the making of an Abstract Wikipedia, or.. maybe even not at all. A respectable administrator of the project stumbles upon the contributor's work, and leaves a warning on the contributor's talk page. The contributor is confused but continues their contributions, because they think those are useful. Eventually, the admin blocks this contributor as "not being here to build wikifunctions", or some other block reason suggesting that the user was acting in a way contrary to the project's goals.

Now, to prevent situations like what I wrote above, we have to make the scope of Wikifunctions very clear from the start. No matter what the scope is, making it clear would either discourage contributors from the project thus avoiding interactions that leave those contributors in a bad taste, or embrace those contributors, thus making sure that admins won't act the way I described above.

The recent blogpost advertises Wikifunctions as a project that is a "wiki of functions", answering questions from users. So okay, I guess Wikifunctions includes general purpose functions for every day search queries and things like that. And then Wikifunctions is talked as this big stepping stone towards Abstract Wikipedia. Okay, got it. Wikifunction would also include natural language generation and some natural language processing. But what about functions that serve some very specific, potentially niche purpose?

And then, when I read Wikifunctions:What Wikifunctions is not, I got confused, just like the user in the story when they got a warning from an admin. As a start, the very first section opens with "Wikifunctions will not have the Euclidean algorithm, nor Newton's method, nor Dijkstra's algorithm" and then goes on to explain that "well actually, we could have them, they just need to be able to serve our purpose". I find this to be quite troubling. The Extended Euclidean algorithm, which is just the Euclidean algorithm with some additional variables on the side, is actually used for many different purposes than just finding the greatest common divisors. This inaccurate example would make people who would otherwise be great contributors turn away from the project. But there's another underlying issue other than this example being inappropriate: What is the scope of the project? The "what wikifunctions is not" page places priority on supporting Wikimedia projects, and then beyond. The blog posts describe Wikifunctions as this big stepping stone towards this other project, which doesn't need to be a huge part of what Wikifunctions is. Development of both Wikifunctions and Abstract Wikipedia can happen in parallel, where Wikifunctions can become something different, with a scope bigger than supporting the creation of Abstract Wikipedia alone. Are we here to just build an Abstract Wikipedia, with a few functions on the side between now and then, or are we also here to build a library of functions? The WMF should make that clear to us.

I think this question should be pretty relevant to ask now, as a discussion I had above really depends on the Abstract Wikipedia team's answer to this question. I had actually thought about asking this before that conversation happened, but I was more motivated to write this due to that discussion. In that discussion, I'm seeing a difference in priorities. I am not particularly good at or interested in creating or manipulating natural languages. I might be able to help with technical aspects or some really basic functions when it comes to contributing to the Abstract Wikipedia effort, but a linguist who can also program would probably be many times more helpful than me. I'd like to help out in maintaining a library of functions, if that is within the scope of this project. 0xDeadbeef (talk) 12:55, 9 August 2023 (UTC)

Hi @Ameisenigel: thanks for helping out in translation admin work, but is there a way to unmark Wikifunctions:What Wikifunctions is not for translation? It feels a bit problematic to accept that page as policy before being vetted by the community. And I have also pointed out some concerns above, with no response yet. 0xDeadbeef (talk) 13:52, 10 August 2023 (UTC)

I could unmark the page, but I think that it is in general helpful to have this content translatable. I have just added a draft template, is this okay for you? --Ameisenigel (talk) 14:43, 10 August 2023 (UTC)

Community may define what Wikifunctions will look like, but serving Abstract Wikipedia is its first (though eventually not only) aim and in the near future development will focus on making the Abstract Wikipedia. GZWDer (talk) 15:36, 10 August 2023 (UTC)

@GZWDer that's interesting. Perhaps this should be documented somewhere? Looking at the main page, the only mention of "Abstract Wikipedia" seems to be buried inside the "recent updates" section under "News". Shouldn't the front page reflect the fact that people who are here to create functions such as "Fast Fourier Transform" instead of "convert number to English" will be considered second-class citizens, i.e. the needs and wants of people who create functions like the latter will be prioritized over the former?

I know that WikiLambda is maintained by the Abstract Wikipedia team and they ultimately decide the direction of the project. I don't think that is a big issue. What's concerning is the goal of "building a community on Wikifunctions" that isn't just full of people making whatever is needed for Abstract Wikipedia. If you want a community that does not suck, you should avoid having two groups of users with different set of values and wants and prioritizing one group over the other. 0xDeadbeef (talk) 08:22, 12 August 2023 (UTC)

Number inputs/outputs?

What type do we use to specify a number as the function input/output? Or can we only use String? Wd-Ryan (talk) 13:19, 9 August 2023 (UTC)

@Wd-Ryan: Currently String/Booleans for now. See Wikifunctions:Status#Only String and Boolean types are supported. 0xDeadbeef (talk) 13:21, 9 August 2023 (UTC)

Thank you! Wd-Ryan (talk) 23:29, 9 August 2023 (UTC)

Let's forward user group requests to Stewards, and not WMF

We had a brief exchange at Wikifunctions:Requests for user groups#TheresNoTime where @TheresNoTime volunteered to be a bureaucrat (thanks for offering to help!), and I was reminded of the voting requirements used by Stewards. (Actually brought up by TheresNoTime themself in the discussion for community role granting above) Given meta:Steward requests/Permissions/Minimum voting requirements#Bureaucrat, let's forward local administrator requests to Meta for now, until our wiki is deemed "big enough" to have bureaucrats. 0xDeadbeef (talk) 13:33, 9 August 2023 (UTC)

And as a note, we don't actually have to have a policy on what counts as "successful request", if we hand the responsibility of what counts to be Stewards' discretion. So I guess #Poll for community roles wasn't actually required to get a community sysop request process running, oops. 😅 0xDeadbeef (talk) 13:36, 9 August 2023 (UTC)

Hello, Wikifunctioneers!

my name is Martin, I serve as a Wikimedia Steward and I was summoned here by @TheresNoTime to provide a comment on this topic from a steward's point of view.

The stewards can definitely help with granting "standard" user groups (those that exist everywhere, such as sysops or interface admins). In that case, consensus would be judged by stewards, using the MVR guidelines, as @0xDeadbeef rightly mentions.

Ideally, for that to happen, Wikifunctions should be bureaucrat-free (currently, couple of WMF staff are both members of Wikifunctions staff and Bureaucrat groups). This is mostly because stewards are only able to act as bureaucrats on projects that don't have any yet, and empty "Bureaucrats" group is an easy way to show that. I personally also believe it is a better setup for the long term, as it introduces a clear distinction in the groups (elected bureaucrats versus appointed staff members) and it makes future changes of staff rights (such as phab:T343748) easier.

That said, I'm not sure how would Wikifunctions want to handle the Wikifunctions-specific groups, such as Functioneers or Maintainers. In most cases, project-specific groups are a responsibility of a "standard" local group, such as admins or bureaucrats. I'm unsure whether it would make sense in Wikifunctions's case, especially for the no-bureaucrats period. If that's desired, it is possible for Stewards to (initially) have this responsibility as well. For awareness, stewards would have to assign "special groups" in two steps (first by making themselves a member of the local Steward group and then making a local change on Wikifunctions, as it is impossible to change non-standard groups directly from Meta), but that shoiuldn't be an issue.

I'm not sure whether now is a good time to discuss the arrangement of Wikifunctions user rights procedures, but I wanted to provide the information above regardless, in case it would be useful for future discussion. If anything I mentioned above is unclear, let me know -- I'll be happy to clarify.

Sincerely, Martin Urbanec (talk) 22:28, 12 August 2023 (UTC)

Ideally, the staff should be assigned a group of their own instead of bureaucrat (similar to what Wikidata did). However, since we are a new community and all, it is possible the transfer process will not happen until after a while. That said, I think it's fine to let the staff in charge of user right requests for the time being. NguoiDungKhongDinhDanh ^talk 14:42, 14 August 2023 (UTC)

Staff already has their own user group here: Wikifunctions:Wikifunctions staff members --Ameisenigel (talk) 15:47, 14 August 2023 (UTC)

Staff does have the user group (and it even has bureaucrat-like permissions [in fact, higher-than-bureaucrats permissions]), it's merely the bureaucrat assignment that I meant in my post. That should be easy to resolve any time, at least technically. Martin Urbanec (talk) 17:03, 14 August 2023 (UTC)

Oops, somehow I missed that. Thanks for the catch. NguoiDungKhongDinhDanh ^talk 06:41, 15 August 2023 (UTC)

Structured data

What about adding a third tab after About and Details on the same model of Commons to host structured data about the functions? This could solve Function categorization and give more freedom in the descriptions. Sabas88 (talk) 07:36, 10 August 2023 (UTC)

Oh. I’ve just had the same idea below where I wanted to query the existing descriptions… That would be definitely useful! --Mormegil (talk) 13:51, 10 August 2023 (UTC)

Added on Phabricator as https://phabricator.wikimedia.org/T344038 --Sabas88 (talk) 06:43, 11 August 2023 (UTC)

Length of short descriptions in English and other languages

The short descriptions of all Persistent object (Z2) are limited in the GUI editor to 100 characters for some reason. However, even the descriptions in the original English often exceed that limit (e.g. 146-character Function (Z8)), not to mention text usually expands when translated from English. [1] The limit should probably be increased at least to something like 200. [Side note: is there a smart way to get the list of all persistent objects sorted by their short description length? Something like a SPARQL endpoint for Wikifunctions? Or… will it be there someday?] Mormegil (talk) 13:20, 10 August 2023 (UTC)

See phab:T343770.--GZWDer (talk) 15:33, 10 August 2023 (UTC)

Mormegil: About your side note, I'm working on a new tool that haven't brought it here which you can see it here and the tool is meant to help auditing different objects available on the wiki and give us a big picture of items created in wikifunctions while they still can be listed in one page (so maybe the tool couldn't be used in future if it isn't evolved like the wiki itself), I will try to implement the functionality you need on top of it in some hours hopefully. I've heard there will be sparql support also someday but I guess this tool can be useful for doing such kind of tasks till then. −ebrahim^talk 15:39, 10 August 2023 (UTC)

Mormegil: It's ready now I think, if you like to test it, first open the tool, wait items to load, click on 'Fetch All' and wait all the items to be fetches (it's faster for admins), then click on 'Sort by longest short description' which shows Sandbox-Implementation 2 (Z10123) has longest short description. −ebrahim^talk 17:04, 10 August 2023 (UTC)

"Duplicate", a new gadget

I felt sometimes I need to duplicate an already created rather than going through the UI, that's why I've created and added a gadget, and the first gadget created specifically for Wikifunctions, called Duplicate, which can be enabled in the user preferences and it will add a link, the same place you can find 'Move' and 'History' on any object page. If is there any concern with the functionality please let me know so I can disable the tool. And feel free to bring you gadgets ideas so we can develop them together in order to build this place more efficiently. Thanks! −ebrahim^talk 15:18, 10 August 2023 (UTC)

Main Page - translations, video, content

I've added some notes, and a few questions, at WT:Main Page. I'm posting here for visibility. Here's a brief summary:

• Translations: It is now possible to translate Template:Main page! (Sorry for the delay with marking that up.)
• Video (and other possible content additions): I'd like to add File:Wikifunctions in 7 minutes.webm (with its translatable captions) into the Main Page, but I'm not sure where to place it, or what else you all might want to change/add in the page in the short-term.

Further details over there. Thanks! Quiddity (WMF) (talk) 19:01, 11 August 2023 (UTC)

This section was archived on a request by: Sannita (WMF) (talk) 10:10, 24 August 2023 (UTC)

Wikifunctions at Wikimania 2023

The Wikifunctions team will be present at Wikimania 2023, and will host two events dedicated to our project.

The first event will be our main presentation at Wikimania 2023! You can already preview the slides of the presentation online. The presentation will be held on Thursday 17 at 07:30 UTC in Room 309 and will be broadcasted online on Wikimedia Foundation's Youtube channel.

The second event will be a workshop called First steps with Wikifunctions, that will be held on Friday 18 at 16:45 UTC+8 in Room 311. This event will not be broadcasted and will be available only for people attending Wikimania.

We hope you can join us! -- Sannita (WMF) (talk) 15:41, 14 August 2023 (UTC)

This section was archived on a request by: Sannita (WMF) (talk) 10:10, 24 August 2023 (UTC)

Help with debugging

I started Is valid Qid (Z10696) and for the implementation in javascript: JavaScript is valid Qid (Z10699) all tests are failing. Now, due to phab:T343593 I almost expected the Qids to fail, but why are the other two tests failing? I am not a javascript developer and this is my first function here, so perhaps there is something obvious I am missing. Ainali (talk) 11:03, 15 August 2023 (UTC)

Hey, I just had a look. I'm here to improve as a developer myself, so take my edits with a grain of salt. To me, the function looked more complicated than it needed to be. Since you were using a regular expression to test the number, I went ahead and tested the entire string with a regex. If you want Q7 to fail and Q1 to succeed, I guess there needs to be a step which checks with Wikidata? Maybe this should be a separate function? One to test the format of the QID and one to check if it is valid at Wikidata? --Azertus (talk) 13:36, 15 August 2023 (UTC)

@Azertus Thank you! And yes, you are correct, in the first version I had the skeleton for such a check in it. But I think you are right, that should probably be in a separate function and then there might be a composite of the two. I'll remove the Q7 test from here. Ainali (talk) 15:26, 15 August 2023 (UTC)

Plan for the out of Wikimedia projects?

It is said "It will be possible to call Wikifunctions functions from other Wikimedia projects" on project:FAQ. Is there a plan for out of WMF wikis? I thought Wikifunctions will replace Scribunto Lua modules(in theory, at least) and eventually the centralized templates and modules(T121470) for the MediaWiki ecosystem will be accomplished. Is this on the load map of WMF? Lens0021 (talk) 16:06, 15 August 2023 (UTC)

In my opinion a future global repo for templates and modules will more likely be in MediaWiki.org rather than here. GZWDer (talk) 18:13, 15 August 2023 (UTC)

@Lens0021 For the time being, development will be focused on serving Wikimedia projects for the next foreseeable future, since it's going to be already some work. Support for third-party websites is in the late future stage of development -- it's one of the goals, but not one of the ones we're gonna focus on. Sannita (WMF) (talk) 08:07, 17 August 2023 (UTC)

If it will be done in a recent decade, I don't care. Thank you! Lens0021 (talk) 12:21, 17 August 2023 (UTC)

Do wikifunctions staff still require bureaucrat?

With some staff members still holding bureaucrat user group, this is causing some confusion with stewards regarding stewards handling user groups in a bureaucrat role. I have a few questions regarding this, which I will try to lay out here. This is an attempt to address the issues directly rather than avoiding this issue which previous discussions somewhat have.

In regards to the technical ability of crats vs staff, the difference comes down to assigning WF:AC, WF:Bots, WF:IA, WF:TA, and WF:Admins for crats which the staff group can't add (All other crat rights are covered by admin of staff group rights).

Reading the draft staff policy it states that staff members can request such rights as admin (crat is implied here). This would imply that a discussion should really occur if staff members wish to hold crat indefinitely.

Since the Wikifunctions:Requests for user groups was created, staff members haven't assigned user groups as they did on Wikifunctions:Apply for editing in the first week. Looking at Special:Log/rights, only 2 bot flags have been added, and one translation admin for User:WikiLucas00 (excluding admin self additions of TA) since requests moved to the specific page. I understand that staff members may have been inactive on group requests due to wikimania but is there still a reason that staff need to assign these rather than going through requests for user groups?

With the suggestions to use the Steward requests/Permissions for user rights, and the confusion caused by staff members holding the crat group (see this) it may be better if staff members could remove themselves from the bureaucrat user group, unless there is some pressing technical reason for staff members to keep this group.

Thanks for reading this block of text, any thoughts? (Pings for some staff: @DVrandecic (WMF), Sannita (WMF), and Quiddity (WMF):) Terasail^[✉️] 16:14, 15 August 2023 (UTC)

In general there are very few user rights that may be helpful for staff as an addition to the staff rights. Nearly all user rights are redundant (except interface admin). I would support removal of redundant rights if there is no good reason to keep them. --Ameisenigel (talk) 16:53, 15 August 2023 (UTC)

See phab:T343748. Note previously Wikidata staffs also have bureaucrat rights.--GZWDer (talk) 18:09, 15 August 2023 (UTC)

In order to hand out the functioneer rights, wouldn't staff still need to be bureaucrats?

Regarding the other rights, I am happy to commit that staff shouldn't hand out any other rights, if that is what the community has decided. I am currently at Wikimania and couldn't follow the discussion, so if there is such an agreement, I am happy to follow the community's consensus. -- DVrandecic (WMF) (talk) 06:57, 17 August 2023 (UTC)

Wikifunctions:Wikifunctions staff members includes the right to grant functioneer to other users. --Ameisenigel (talk) 10:41, 17 August 2023 (UTC)

The bureaucrat user group explicitly doesn't have the permission to add the functioneer or maintainer user group at the moment and the addition of both is strictly restricted to Wikifunction staff members. Terasail^[✉️] 17:02, 17 August 2023 (UTC)

Done (removed from all). Thanks for the nudge! Quiddity (WMF) (talk) 13:21, 20 August 2023 (UTC)

Concerns on a function

I came across regular expression match (Z10196). That raises a huge red flag for me. I think it is at least a common sense to never trust user inputs, and I quite fear regex attacks. By the way every language has slightly different definition on regex, this makes the function tied on a specific language. MilkyDefer 17:50, 16 August 2023 (UTC)

I have deactivated it for now. MilkyDefer 17:51, 16 August 2023 (UTC)

@Jdforrester (WMF): I am not sure whether the current system is safe enough for handling ReDoS (by using a hard execution time limit). See also phab:T176312 and subtasks. GZWDer (talk) 18:56, 16 August 2023 (UTC)

@MilkyDefer: Thanks!

@GZWDer: Good question. Our time limit is certainly one defensive measure, but in general I agree that this probably it's the right kind of function for us to support. Jdforrester (WMF) (talk) 01:31, 17 August 2023 (UTC)

As a note, this object is currently used in is IPv4 (Z10476). There are currently no native way to trace usage of objects (see phab:T342984), but as a workround you can use [2].--GZWDer (talk) 13:54, 17 August 2023 (UTC)

In my opinion, is IPv4 (Z10476) is ill suited for regex evaluation. See Talk:Z10504. Even if it would drop support for classful notations, string explosion and numeric comparisons would be easier understood and possibly execute quicker. /Autom (talk) 18:39, 17 August 2023 (UTC)

Fully agree here. Not until actually touching the specific detail did I know what a mess the internet standards were 30 yrs ago. MilkyDefer 19:43, 19 August 2023 (UTC)

@MilkyDefer: Yep, many of the the old standards are right cans of worms when you look into them. Like evaluating an email address, which can contain comments, nested escape sequences and of course clasful IP addresses. "@"ME(comment)%EXAMPLE@[1] should reach the user @ME at example by being forwarded through 0.0.0.1, were it not for the fact that the domain "example" is an RFC 2606 exception that must not be forwarded. And that does not even involve Unicode or subaddressing. /Autom (talk) 22:50, 20 August 2023 (UTC)

Function implementation

I was looking through the functions, and they only seem to be implemented in Python and JavaScript. I'm assuming that means only those languages are supported by Wikifunctions, so my question is: are others (i.e., Java, C++) going to be supported in the near future? MEisSCAMMER (talk) 20:43, 16 August 2023 (UTC)

Yes. See Wikifunctions:FAQ#Which features are available now, which will be soon available, and which are further away?. It's the penultimate bullet point under "Ongoing development". Bongo50 (talk) 10:30, 20 August 2023 (UTC)

Two requests for administrator are currently open

A Request for Administrator is currently open for discussion at Wikifunctions:Requests for user groups#Minorax for Minorax. Terasail^[✉️] 11:41, 20 August 2023 (UTC)

A second Request for Administrator is also currently open for discussion at Wikifunctions:Requests for user groups#Ebrahim for Ebrahim. Terasail^[✉️] 18:49, 20 August 2023 (UTC)

This section was archived on a request by: Terasail^[✉️] 14:48, 25 August 2023 (UTC)

Labels broken

New functions, implementations, and test cases are appearing untitled while they have a label assigned. URI encode Python (Z10815) shows "Implementation: Untitled" in the title but "URI encode Python" in the about section. Wd-Ryan (talk) 14:08, 19 August 2023 (UTC)

@Wd-Ryan The label was set in chinese for some reason, so it didn't show in the title because you have your language set in english. I updated it. Terasail^[✉️] 16:23, 19 August 2023 (UTC)

Oh yeah, and others, like remove punctuation (Z10812) are EN-GB instead of EN, so they also won't show for me! Wd-Ryan (talk) 21:00, 19 August 2023 (UTC)

This section was archived on a request by: Terasail^[✉️] 16:12, 27 August 2023 (UTC)

Function calling currently broken

Tracked in Phabricator:
Task T344998

Hello all,

Unfortunately, making a function call that's written in Python or JavaScript isn't working, as the back-end service isn't responding (T344998). We do not currently know what broke this, and so we don't have a timeline for it being fixed. Our apologies. Will update as soon as we know more. (Thanks to @Bongo50 for reporting this!) Jdforrester (WMF) (talk) 20:30, 25 August 2023 (UTC)

This is now fixed. Sorry for the disruption! Jdforrester (WMF) (talk) 13:34, 28 August 2023 (UTC)

This section was archived on a request by: Sannita (WMF) (talk) 15:49, 29 August 2023 (UTC)

Five requests for administrator are currently open

There are currently five requests for adminship that are open:

• Minorax — Closes: 06:26, 27 August 2023 (UTC)
• Ebrahim — Closes: 18:26, 27 August 2023 (UTC)
• Manjiro5 — Closes: 23:04, 31 August 2023 (UTC)
• Wd-Ryan — Closes: 01:59, 1 September 2023 (UTC)
• Xnet1234 — Closes: 13:07, 1 September 2023 (UTC)

Terasail^[✉️] 14:51, 25 August 2023 (UTC)

This section was archived on a request by: Terasail^[✉️] 13:24, 1 September 2023 (UTC)

How do I add code (or do I)?

I would like to contribute the following Python function to https://www.wikifunctions.org/view/en/Z10012

# reverse_string - reverses the input_string and returns it as reversed_string

def reverse_string(input_string):

reversed_string = input_string[::-1]

return reversed_string

This is a python function that performs the reverse string. I do not see where to add this code to the page.

Is it intended that examples of such functions would be included in the page? PatrickStingley (talk) 03:32, 18 August 2023 (UTC)

Also, the wiki gobbled up the three space indents on lines 2 an 3 of the code, which would make it non-functional in Python. When I edited the page and saved it, it gobbled up the carriage return before the def statement. I have inserted a second line break to ensure this doesn't happen.

Hi @PatrickStingley: - this wiki is currently in limited roll out, and editing functions is only available after going through the Wikifunctions:Apply for editing process. The development team is slowly (and temporarily) assigning this at first, and generally limiting it to experienced wikimedians. In the near-future, this will be opened up further, per that first link.

Regarding the code examples, there are various methods to format code, documented at m:Help:Advanced editing#Disabling wikitext interpretation and/or reformatting.

I hope that helps. Quiddity (WMF) (talk) 10:43, 18 August 2023 (UTC)

This section was archived on a request by: Terasail^[✉️] 16:19, 3 September 2023 (UTC)

"string" and unicode normalisation

I was going to suggest "Unicode normalisation" as an algorithm, but it's unclear whether the "string" type is already normalised. I'm guessing that this is a technical question for those who configured the webserver. Maybe update the glossary with this detail? Constant-time Unicode normalisation algorithms have become important again as folks look to Unicode for passwords and need to avoid leaking information via variable-time algorithms. Stuartyeates (wikifunctions) (talk) 03:45, 23 August 2023 (UTC)

The function already exists: normalize Unicode (Z10384). GZWDer (talk) 20:51, 24 August 2023 (UTC)

This section was archived on a request by: Terasail^[✉️] 16:20, 3 September 2023 (UTC)

Bots we want

Want to bring a bot from elsewhere over? Put it below in a level 3 heading (3 equals signs on each side), and discuss it. Bots will be approved after discussion if there is a consensus for them.

SpBot

This bot provides archiving of resolved and old sections. I think this will be useful once we have enough stuff to archive. I can create the templates and reach out to the owner if there is interest. Mdaniels5757 (talk) 00:30, 2 August 2023 (UTC)

• Yes, we definitely need this bot --Ameisenigel (talk) 16:54, 2 August 2023 (UTC)
• Yes please! I'd appreciate being able to easily archive resolved sections. Quiddity (WMF) (talk) 23:39, 2 August 2023 (UTC)

  OK, I've asked the botop, but there's a pywikibot error blocking this for now. It's tracked at phab:T343573. —‍Mdaniels5757 (talk • contribs) 19:54, 4 August 2023 (UTC)

  This is done and running per c:User talk:Euku, I'll post a Steward request. —‍Mdaniels5757 (talk • contribs) 15:54, 9 August 2023 (UTC)

  Flag added. Xaosflux (talk) 18:58, 9 August 2023 (UTC)

EmausBot

For resolving double redirects --Nintendofan885^{T&Cs apply} 19:15, 3 August 2023 (UTC)

I think that it is not necessary, due to the low number of the renames, but it would not hurt. Zalán Hári ^{talk page} _{Let's edit!} 03:09, 4 August 2023 (UTC)

• I support this --Ameisenigel (talk) 06:22, 4 August 2023 (UTC)

Process for community roles

Right now, staff is handing out community roles such as admin, interface admin, etc. I don't think we should. It would be great if the community would start getting self-organized on that. --DVrandecic (WMF) (talk) 19:41, 2 August 2023 (UTC)

In a long term I'd rather copy the procedure from other multilingual wikis. Meta, Commons and Wikidata all use ≥75% percent of votes in favor and at least 8 supporters. It seems reasonable for me to introduce something like this here too. During the initial phase we may like to have an additional option that even if there are too few supporters, the candidate may get the rights but limited in time (like for 3 or 6 months), provided that there are no severe objections raised (decided at the bureaucrat's discretion). Msz2001 (talk) 15:39, 5 August 2023 (UTC)

Personally I believe that 66,67 % should be enough. I think there are basically three important aspects: how high should the percentage of support votes be, how many support votes are the minimum and how long should the vote take place? --Ameisenigel (talk) 16:09, 5 August 2023 (UTC)

+1 to 2/3 support rate 0xDeadbeef (talk) 16:55, 5 August 2023 (UTC)

2/3 support rate may be enough for a temporary adminship, but probably not a permanent one.--GZWDer (talk) 17:08, 5 August 2023 (UTC)

75% is probably best since even of it is exactly 75% there is no question there is support, also matching the other multilingual wikis is probably best for consistency. I would say, any user group requiring voting should last a minimum of a week. As for minimums, I think a wait and see how active these discussions are with a tentative minimum participation of 8 people and can be revisited after the first 2-5 requests. Terasail II ^[✉️] 12:15, 6 August 2023 (UTC)

Poll for community roles

Given some participation and voices above, here's an initial proposal for our process for granting roles:

Any request for the Administrator, Interface administrator, Translation administrator, or Bureaucrat user groups should be posted to Wikifunctions:Requests for user groups, where a discussion of whether to grant the permission will take place. An user is added to their requested group indefinitely, after a minimum discussion period of one week, if at least 8 community members in good standing (no active blocks or sanctions) have voted in favor of the candidate, and that ≥75% of all votes are in support of the candidate.

WMF staff should help with the technicality of granting these user groups, until we get community bureaucrats who can handle granting the user rights.

0xDeadbeef (talk) 06:30, 8 August 2023 (UTC)

Comments (community roles process)

•  Support as proposer. I think one potential concern for this is how we handle requests with not enough participation, and close call cases. I've intentionally omitted details about closing requests as failed, as I think we can deal with those as we go (though feel free to propose how to close them as fail) 0xDeadbeef (talk) 06:30, 8 August 2023 (UTC)
• I  Support most of this proposal, but please let us not set this high criteria for translation admin. Looking at TA requests on other projects, there is in general very little participation and we will probably never be able to elect someone as TA if we require 8 support votes. I would just suggest one week and consensus without a specific amount of votes. --Ameisenigel (talk) 09:31, 8 August 2023 (UTC)
•  Support. It makes sense to start formally taking these requests woth these numbers to start, the information at Wikifunctions:Administrators, Wikifunctions:Bureaucrats and Wikifunctions:Translation administrators should be updated to reflect this change if it passes. I also don't think the minimum of 8 users is as important for TA requests. Terasail II ^[✉️] 09:56, 8 August 2023 (UTC)
•  Support I think that for the start, this process is just fine. Later on we can work out the details (i.e. close calls or how much leeway will the bureaucrats have). ALTHOUGH, I would be in favour of lowering the treshold to 2/3% for Translation admin, or to give this right solely to the bureaucrat discretion. Let's not limit ourself at the start. Nadzik (talk) 10:02, 8 August 2023 (UTC)
•  Support, with the caveat that requiring a minimum level of participation can sometimes be problematic — following something like meta:Steward requests/Permissions/Minimum voting requirements and only assigning rights temporarily might help? TheresNoTime (talk) 10:04, 8 August 2023 (UTC)
• I don't really see a point in a minimum participation requirement, but this otherwise sounds good to me. Taavi (talk) 11:28, 8 August 2023 (UTC)
•  Support These values seem to work for other multilingual projects, so why not to start from them. I'd lower the requirements for translation admin, though, as it's more of a technical job and, as far as I know, can't have as disruptive effects as the other ones. Msz2001 (talk) 20:48, 8 August 2023 (UTC)
• I  Support as proposed for admin/bureaucrat. I  Oppose the requirement of 8 support votes for translationadmin. I would support translation admin being granted by a bureaucrat after a short discussion, as on Commons. I  Oppose requiring administrators to go through a formal request for interface adminship as well, this should be granted by a bureaucrat on request (also as on Commons); however, for non-administrators seeking interface adminship, the normal requirements should apply. —‍Mdaniels5757 (talk • contribs) 00:03, 9 August 2023 (UTC)
• Since it's a community procedure, why should WMF staff handle the rights management? Why not have a community-elected body (stewards) until a local bureaucrat is available? Community rights management should be handled by stewards via SRP. I also don't see a good reason for the minimum participation requirement. --MdsShakil (talk) 17:25, 9 August 2023 (UTC)
• Stewards can handle this until 'crats are elected. It would be best to get a staffer to notify us stewards that this handover to community management is ready. Xaosflux (talk) 19:01, 9 August 2023 (UTC)

Wikiscan for Wikifunctions!

Hi,

A quick message to let everyone know there is now subpage of Wikiscan for Wikifunctions: https://wikifunctions.wikiscan.org/

There you can find an edit counter and various other metrics (and yes, it is strange to see edit from before the opening but it comes from the history imports).

Cheers, VIGNERON (talk) 17:37, 21 August 2023 (UTC)

Duplicate: how to merge?

Tracked in Phabricator:
Task T344973

I noticed that Moldavian (Z1239) and Moldovan (Z1668) have been created, both for the language Moldovan. The second with the outdated ISO 639-1-code, the first one with the actual used language code. How to merge these two items? Romaine (talk) 06:01, 25 August 2023 (UTC)

Unfortunately this is currently not possible (see Wikifunctions:Requests for deletions#(Z1346) & Z1816 for reference). --Ameisenigel (talk) 07:05, 25 August 2023 (UTC)

I have created a Phabricator task for requesting this feature. --Ameisenigel (talk) 07:12, 25 August 2023 (UTC)

New name proposal for this page

Hi, I wish ask for your consent in order to rename this page which is simply called Wikifunctions:Project chat to Wikifunctions:Agora, in homage to the agoras, that was a central public space in ancient Greek city-states, which would make it possible to give a more original name. Regards, Manjiro5 (talk) 22:53, 24 August 2023 (UTC)

I disagree. Our main language is English, so the page name should be a meaningful, common English word. Being a non-native speaker, I've never heard of "agora" before, and I don't see how ancient Greek city-states and Wikifunctions are related. NguoiDungKhongDinhDanh ^talk 23:59, 26 August 2023 (UTC)

It would be useful it the MediaWiki:Sidebar link, Extension:Display Title and header section were translatable. /Autom (talk) 13:05, 27 August 2023 (UTC)

I do not like this new proposed name. It is not particularly clear as to what its purpose is and I feel that clarity is more important than uniqueness or originality. Bongo50 (talk) 07:47, 28 August 2023 (UTC)

Access from npm/pypi

Hi,

is there any plan to allow acces the wikifunctions from 3rd party code ?

for example using a npm package that could fetch function definitions and execute them locally ?

Julienb42 (talk) 11:33, 29 August 2023 (UTC)

I very much hope that such libraries will develop. It is not likely that the development team will be tackling that task. --DVrandecic (WMF) (talk) 02:54, 30 August 2023 (UTC)

Patrol and Autopatrol rights?

Tracked in Phabricator:
Task T343946

Right now, many changes on Special:RecentChanges are unpatrolled, even though they are made by trusted users. On Commons, we have the autopatrolled group (containing the autopatrol right), which admins can give out to trusted users; right now, the autopatrol right is only available to bots and sysops.

Relatedly, many non-admin users can be trusted to patrol other people's edits. Again on Commons, we have the patroller group (containing the patrol right), which can be given to trusted users. Again, right now, this right is only available to bots and sysops.

This isn't much of a problem now as IP editing is disabled and few-to-no vandals are coming here. As we expand, this will likely become a problem.

I invite thoughts on:

1. Should we create a new user group or two?
2. If we make this two user groups, should (a) one group contain both patrol and autopatrol rights and the other the autopatrol right only (as on Commons) or (b) one group contain only the autopatrol right and one group only the patrol right (as on enwiki)?

Best, —‍Mdaniels5757 (talk • contribs) 02:48, 9 August 2023 (UTC)

For the second question, I prefer the first option (also the case on Meta). One who patrols others' edits must be trustworthy themself. NguoiDungKhongDinhDanh ^talk 03:24, 9 August 2023 (UTC)

I prefer one group for autopatrol and one for patrol including autopatrol. think it would make sense to include autopatrol in the funtioneer group. This would reduce the workload and functioneer rights will probably not be given out to vandals. --Ameisenigel (talk) 06:52, 9 August 2023 (UTC)

@Ameisenigel Just to repeat what you said back to you, you want (1) an autopatrol group, (2) an autopatrol+patrol group, and (3) add autopatrol to functioneers? Also, should functioneers get patrol too, or just autopatrol? —‍Mdaniels5757 (talk • contribs) 16:42, 9 August 2023 (UTC)

(1): yes

(2): yes

(3): yes, I originally just thought about adding autopatrol to functioneers. I do not have a strong opinion about adding patrol as well. --Ameisenigel (talk) 18:05, 9 August 2023 (UTC)

I made a patch for adding autopatrolled only, as given the quantity of edits coming from users who would be autopatrolled there may be no need for non-sysop patrollers. The ticket is phab:T343946

Re functioneers getting autopatrol: I'm not opposed to it, but would want assurances from the WMF staff handing it out that they will only give it to established users on a WMF project. If they want/plan to expand their grants of functioneer past that, I think having those edits autopatrolled would not be desirable. —‍Mdaniels5757 (talk • contribs) 02:35, 10 August 2023 (UTC)

@Mdaniels5757 Thanks for starting the good discussion, and the patch!

Re: The patch, shall I ask the dev-team to check and merge that as soon as possible (to potentially arrive with the deployment train next Wednesday), or does it need more discussion first?

Re: The current process for Wikifunctions:Apply for editing (early + temporary Functioneer user-group), yes I can confirm we're currently checking CentralAuth for existing advanced-rights and/or extensive-experience, and existing blocks (and historic logs in uncertain cases). The only exception is our current GSOC student whom has been working closely with the dev-team (cf. T333498). Thanks. Quiddity (WMF) (talk) 21:34, 11 August 2023 (UTC)

@Quiddity (WMF) Thanks for responding!

Re the patch, in light of the responses here I don't think the patch adding an autopatrolled group needs any more discussion (it seems uncontentious) and can be merged whenever, but the ticket was set to stalled for lack of consensus. Maybe it can be merged Monday afternoon to allow more time for objections.

Re the functioneer group, that's great, and I think I'd want them to receive autopatrol in that case. My only concern would be when the functioneer group is depreciated, we should give active functioneers the autopatrol group, if that's technically feasible. But that shouldn't be a blocker. I'll make a patch for that, and that can also probably be merged Monday afternoon, if that's in time for the train.

Best, —‍Mdaniels5757 (talk • contribs) 01:01, 12 August 2023 (UTC)

@Mdaniels5757 Note the Functioneer group itself is permanent. Staff are just allocating the group (with a temporary expiry) for the first few weeks/months so that if unforeseen problems arise then they don't affect too many people/edits. In the near-future, Admins will be in charge of assigning the group to folks. See mw:Help:Wikifunctions/User rights for the expected setup once we reach phase 3 of the deployment plan. Hope that helps, and you all have a good weekend! Quiddity (WMF) (talk) 01:56, 12 August 2023 (UTC)

I think that it is a good idea and uncontroversial that autopatrol should be added as a usergroup, adding a patrol usegroup may be best after a separate discussion when WF is out of limited roll out so that the need can be better assessed. I think that at this moment it is probably best that functioneers do not get autopatrol/patrol until the group is in a more finalised form instead of the temporary state it is at the moment and can be reassessed at that time. Terasail^[✉️] 11:11, 4 September 2023 (UTC)

---

The autopatroller group has been added and functioneers have been given the autopatrol right. Terasail^[✉️] 20:48, 28 September 2023 (UTC)

This section was archived on a request by: Terasail^[✉️] 20:48, 28 September 2023 (UTC)

Add the ability for administrators to add and remove the confirmed user group

Tracked in Phabricator:
Task T344261

I have created a phabricator task on this however, this will require community consensus for this change to occur. I will copy over my reasoning here aswell (So you don't have to open phabricator).

If anyone were to request the confirmed (Not autoconfirmed) usergroup, there should be no real reason why this is restricted to Bureaucrats as it is at the moment (WF group rights). The ability for admins to complete this is somewhat standard with commons, wikidata and enwiki allowing it, with a notable exception being Meta-Wiki. There is a section available at WF:Requests for user groups#Confirmed to request this, however with a lack of any non Wikifunctions Staff bureaucrats, and Wikifunctions staff wanting to step away from general user group granting, admins and stewards are the only user groups able to grant general user groups for the community.

Do you think that this is a good change to make for Wikifunctions? Terasail^[✉️] 17:01, 17 August 2023 (UTC)

•  Support --Ameisenigel (talk) 18:05, 17 August 2023 (UTC)
•  Support Xnet1234 (talk) 16:33, 24 August 2023 (UTC)
•  Support reasonable for a tech project like this. Xaosflux (talk) 00:05, 28 August 2023 (UTC)
•  Support seems like a good idea. Bongo50 (talk) 07:45, 28 August 2023 (UTC)
•  Support --MdsShakil (talk) 03:40, 30 August 2023 (UTC)
•  Support Karnataka (talk) 18:05, 3 September 2023 (UTC)
•  Support Koavf (talk) 06:20, 9 September 2023 (UTC)
•  Support Zippybonzo (talk) 19:18, 12 September 2023 (UTC)
•  Support Lens0021 (talk) 22:02, 26 September 2023 (UTC)

---

This change has now been implemented. Terasail^[✉️] 20:47, 28 September 2023 (UTC)

This section was archived on a request by: Terasail^[✉️] 20:47, 28 September 2023 (UTC)

Function exists?

Tracked in Phabricator:
Task T285424

How can I know if a function already exists? Search bar at the top is utterly broken: no functions/implements/test cases (or, any ZObjects) can be found by name via it. Sometimes I attempted to create a def for a new function, but when I publish it, the system tells me that a function with the same label in the same language already exists (clashing). This is quite a problem, as users tend to create several objects with the same function if we don't know if it had been created by someone else. -- U.T. 06:51, 31 August 2023 (UTC)

@Unite together: Thanks for your report. There's already an open bug on Phabricator, if you see something is missing, please edit it accordingly or suggest me the proper integrations here, so that I could add them to the ticket. Thanks! --Sannita (WMF) (talk) 09:12, 31 August 2023 (UTC)

@Unite together: While the automatic search doesn't work, it does work when pressing enter (or using Special:Search directly). This will match both labels and aliases in any language, but not substrings. /Autom (talk) 10:44, 31 August 2023 (UTC)

Nearby

Tracked in Phabricator:
Task T345459

Tracked in Phabricator:
Task T345463

Hi,
project has Special:Nearby for geographical coordinates with button Nearby in mobile version (in the collapsible sidebar: press ☰). If it's not needed (?), should it be removed or replaced?
I also want to note that banners (for example, Wikifunctions is a new project by...) are visible only in the desktop version. Proeksad (talk) 20:20, 31 August 2023 (UTC)

I think the button is unnecessary now and can be removed. Alternatively, it might be possible to create a parallel feature that would allow you to select functions that receive coordinates as input (how will we find them all? This is a future question), and that accessing them through this button would input the user's location. · ^מקף Hyphen _෴ · 21:17, 31 August 2023 (UTC)

Thanks, I've filed phab:T345459 to change that configuration to remove Nearby, and phab:T345463 to enable Sitenotice here. Quiddity (WMF) (talk) 18:25, 1 September 2023 (UTC)

External function tables

I came across this list of Excel functions and their Wikifunctions mappings by @Sabas88:, and I think that we should have tables like this somewhere in the main namespace. It would be helpful to see what gaps are missing on the website. Spreadsheet programs, programming language libraries, etc.. -wd-Ryan (Talk/Edits) 14:46, 22 August 2023 (UTC)

Thank you! I proposed the idea on Telegram, but I wasn't sure where to put the page.. I'm open to move it! --Sabas88 (talk) 07:53, 23 August 2023 (UTC)

If we're going to bug-for-bug implementations of functions from other platforms (and Excel famously has bugs in the time/date functions that Microsoft has grandfathered in), then they need to kept in their own namespace in some fashion to protect ordinary users from those bugs. Stuartyeates (wikifunctions) (talk) 09:12, 24 August 2023 (UTC)

Oops, I meant the Wikifunctions: namespace, not main. -wd-Ryan (Talk/Edits) 14:49, 24 August 2023 (UTC)

Done Now at Wikifunctions:Excel functions --99of9 (talk) 23:57, 19 September 2023 (UTC)

Running an implementation from its page causes an error

Hello, when running an implementation directly from its page, "wikilambda-zerror" is returned. For example, try using + in Python (Z10004) which is an implementation of join two strings (Z10000) that is connected and has passed all of the tests. At the bottom of the page, enter any text for each input and click "run function". The result is "wikilambda-zerror". Apologies if this issue is already known or expected. Bongo50 (talk) 10:37, 20 August 2023 (UTC)

@Bongo50: It seems that only those with the wikilambda-connect-implementation right (e.g. functioneers) can connect a function to its implementations and thereby run it. NguoiDungKhongDinhDanh ^talk 16:16, 24 August 2023 (UTC)

But I'm not trying to connect the function to its implementations. I'm merely trying to run it. That's not something that should require that user right in my opinion. Besides, I can run the function directly from its page. It's just trying to run a specific implementation that causes the error. In any case, if this is intended behaviour, I feel that there should be a more informative error message, but I can't see that this intended behaviour. Bongo50 (talk) 18:36, 24 August 2023 (UTC)

Thanks for reporting, that would indeed be a potential bug. So, right now, if you are not logged in, you shouldn't be able to run any functions. But if you are logged in and on an implementation pages that is connected, you should be able to run the implementation on the implementation page. That also works for me. It might have been fixed in the meantime (we had a number of weird bugs floating around in that space for a while). Please let us know if that is not resolved yet. It should be. DVrandecic (WMF) (talk) 20:39, 29 September 2023 (UTC)

void (Z24)

What is the relationship between this and Nothing (Z23)? I know Nothing (Z23) is a Type (Z4) which has no instances whereas this is a Unit (Z21), but that's it. I speak neither Polish nor Czech, so reading the descriptions doesn't really help. NguoiDungKhongDinhDanh ^talk 16:59, 24 August 2023 (UTC)

Is it correct to say that void (Z24) is similar to null/None and that these two are almost irrelevant? NguoiDungKhongDinhDanh ^talk 17:07, 24 August 2023 (UTC)

void (Z24) might be similar to null in type systems like TypeScript strict (where it's the only value of type null). Unit (Z21) is just typeof(Z24). There exist other unit types as well, e.g. Unit in Kotlin. The intention of having them is mainly to convey a lack of any significant value. On the other hand, Nothing (Z23) is like void in C. There is no way to create a variable of type void because there's no single value of that type (on the contrary, Z21 has a single possible value).

I'm not sure how these three will be used on WF, but Unit (Z21) and its value, void (Z24) can be used to create a Maybe type (Maybe<T> = T | Unit in TypeScript notation) that is conceptually equivalent to returning an object or null if some condition applies.

I have no idea what could be the aplication of Nothing (Z23), however. Perhaps it might be used in future to create optional arguments to a function?

There is a related question on StackOverflow too: What is the purpose of Unit returning in functions?.

Msz2001 (talk) 20:31, 24 August 2023 (UTC)

You are correct: Nothing (Z23) cannot have any instances constructed, and void (Z24) is similar to a null/None. However, the comment above suggesting that Nothing is similar to void is wrong. In C, it isn't legal to have a variable with type void. In type systems things can have the Nothing type. It is called a bottom type. 0xDeadbeef (talk) 15:22, 25 August 2023 (UTC)

Yeah, the descriptions are quite right. The relevant English Wikipedia articles are here:

• for Nothing (Z23), it is Bottom type
• for Unit (Z21) and its instance void (Z24), it is Unit type

What is the application? A function that has the return type Z21, returns no information. That in itself is rarely useful. But together with an Either generic, as Msz2001 alluded, it can be useful, to allow the function to say "no answer for your inputs". Similarly, this is one way to build optional values.

A function that has the return type Z23, or an argument type Z23, is basically never callable, and would always generate an error (don't try it out right now, or, if you do, go to the Beta). That might be useful for testing, but doesn't sound immediately useful otherwise.

But in the end, we are not entirely sure yet, and we certainly listen to input on the Function model. One way is also sketched out in T287608.

In short, we are thankful for thoughts on the function model. We are still implementing parts of it. --DVrandecic (WMF) (talk) 20:57, 29 September 2023 (UTC)

Naming convention draft

A week ago I've made a draft WF:Naming conventions. I've mentioned it already in Function naming? thread but it appears to have got lost between comments. I'm reposting it thus here and seeking for input on that. Feedback and suggestions are welcome.

One more issue, that's not yet included there, is how descriptive the function names should be? Should we recommend including verbs there? Msz2001 (talk) 13:32, 27 August 2023 (UTC)

As previously stated, I like the current draft a lot. I also lean towards descriptive function names with verbs. Bongo50 (talk) 14:45, 27 August 2023 (UTC)

I think it's at least as important to consider whether we prioritize clarity over using a short name already in use. normalize Unicode (Z10384) for example isn't going to mean as much to many as "to Normalization Form Canonical Composition (Unicode 15.x)". Stuartyeates (wikifunctions) (talk) 09:06, 28 August 2023 (UTC)

In a case like that, I prefer the more descriptive name (with the shorter name as an alias, of course). People who will come to Wikifunctions won't necessarily be programmers and so I don't think we should assume familiarity with acronyms. Bongo50 (talk) 11:04, 28 August 2023 (UTC)

Shouldn't it be at WF:Naming conventions? Might just be what I'm used to seeing on enwiki, but plural feels better here. Skarmory (talk • contribs) 05:59, 1 September 2023 (UTC)

Agreed, probably we'll have multiple conventions (for example one for types, another for implementations, etc.). —Suruena (talk) 13:10, 2 September 2023 (UTC)

Moved. Msz2001 (talk) 13:52, 2 September 2023 (UTC)

I think it is useful to differentiate the names of predicate functions (returning a Boolean), and other functions. The current convention for predicate function is to use names like "is empty string" or "string starts with". When not returning a Boolean, I like the programming convention of using a noum (e.g. "distance between Earth and Sun on"), no need to use a verb ("calculate a distance between Earth and Sun on"). —Suruena (talk) 13:10, 2 September 2023 (UTC)

I feel like the implementation names part could do more with specifying how exactly to format it [i.e. ... (python), in python, or just python]. The algorithm name should probably also be forced for the sake of standardization[?] Infernostars (talk) 20:22, 29 September 2023 (UTC)

separation of functions, implementations and tests?

I wonder why these three are not separated into different namespaces. They seem to be clearly delineated, and I imagine we will later want to search them separately. I'm sure there are technical reasons I haven't considered, so if anyone knows them, I'm interested to hear. --99of9 (talk) 00:28, 31 August 2023 (UTC)

They are all objects. Being an implementation, being a test, being a function, all of them are represented as objects for Wikifunctions (that's because Wikifunctions aims to be homoiconic). Now we are left we three choices:

1. every instance of a type goes into their own namespace, per type
2. all instances of all types go into a single namespace
3. some instances of some types go into special namespaces, and others go into some fallback namespace

Since adding types will eventually be something the community can do, but adding a namespace is not, combining these two, as suggested in the first possibility, was too tricky. The third possibility felt more complicated than either of the other two. So instead we opted for the second possibility. --DVrandecic (WMF) (talk) 21:22, 25 September 2023 (UTC)

Thanks for explaining. Since posting I've realised there are already quite a few categorically different types of types, even before user-creation. I'm still concerned about searchability, but I see that namespaces may not be the answer. --99of9 (talk) 02:05, 26 September 2023 (UTC)

Yes, searchability will be interesting. Also uniqueness of names. We currently require that all objects have unique names in every language. But this might be a bit too strict. So thinking about that too, together with searching. -- DVrandecic (WMF) (talk) 20:41, 29 September 2023 (UTC)

Using a GObject like closure system to support more languages.

GObject is an object system built in C and designed so that things built on top of it can be easily binded to lots of higher level languages (https://en.wikipedia.org/wiki/List_of_language_bindings_for_GTK). One of its features is a closure system that allows callbacks to functions in other languages to be created and be easily call from C code. One of the components of GObject closure is a system to convert language independent GTypes to language dependent types.

Would a similar system for Wikifunctions be applicable/useful? Having a system to convert Wikifunctions types to language dependent types and being able to have implementations in many different languages.

https://docs.gtk.org/gobject/struct.Closure.html CoderThomasB (talk) 02:27, 18 August 2023 (UTC)

(unarchive and date-bump. Still intending to reply. Sorry for the delays) Quiddity (WMF) (talk) 22:28, 18 September 2023 (UTC)

@CoderThomasB Thanks! Your description of GObject sounds super interesting. One major advantage that we want to exploit is that Wikifunctions are functional, i.e. the objects wouldn't have (hidden or non-hidden) state, whereas my understanding of the GObject system is that it allows for state. This makes our usecase much simpler.

What I couldn't find on the page you linked, and what I would be very interested in, is how to they specify the mapping of language independent GTypes to language dependent types? --DVrandecic (WMF) (talk) 20:37, 29 September 2023 (UTC)

Sorry for the long reply, but I just wrote a lot and don't really want to cut any of it

What dose GObject type introspection do?

I think the most relevant thing from GObject is its type introspection. If I have a GObject style function that, say, takes in a GBool and a GInt and returns a GString, then I can pass my code to a tool that generates an XML description (called GIR) of the function and the types of its inputs and output. Then a bindings tool can take that GIR and create a glue function in its native language. For example, it may generate a Java function that takes a Java bool and a Java int and converts them to the GObject equivalent, calls the C code and then converts the returned GString into a Java string, making the GObject function appear "Transparent" to a Java developer. The tools to generate the bindings and glue code are not part of GObject, GObject only specifies what the GTypes are (e.g. for some reason a GBool is 32 bits for backwards compatibility reasons) and provide tools to generate GIR from C (and Vala). In this example I only referred to "simple" types like GInt but the benefit of GObject is that it has an okay object system and these objects, classes, signals, interfaces, and other things can also be described by GIR and already have an ecosystem of binding tools.

So if I write some obscure library in GObject then it would be possible to interact with it from say Python or Haskell with some level of transparency because of the type introspection and automatic binding generation around GObject.

Type descriptions in WikiFunctions

In WikiFunctions the type description of a function is already in the wiki and so a type description doesn't need to be generated from an implementation. Rather, it is the other way around, where it is kind of the entire point that the function's implementation's job to conform and handle the types ascribed to it by the wiki. And so a tool to generate a type description from code isn't necessary.

Dynamically typed

Alongside this, both JavaScript and python use dynamic types, which mean that any function given a random input can just figure out its type and handle it, unlike in C where types are a pure compile time idea and it's all just memory at runtime. (Unless you use a library like GObject and wrap something in a GValue, or it is a GObject.) This kind of makes a type description unnecessary when trying to call one of these functions from another language because the converted value will have the type embedded into it at runtime and the function being called will just throw a runtime error if the type can't be handled, unlike in the C example where you just can't call a C function unless you know what its type is.

Why would someone use this?

One more thing is that most of the functions on this wiki are quite trivial and a developer could just use their language's equivalent, unlike in GObject where a developer would use it because they want to interface with a complex library like GTK from whatever language they liked. Which makes sense because that's not what WikiFunctions is trying to be and so I think the type introspection is unneeded in WikiFunctions because no one from Haskell or C or Vala would want to call any of the functions on this wiki because doing so would require them embed an entire copy of a python or javaScript interpreter in their program when they could just use their language's string reverse function. So I don't think a system to let other language interface with WikiFuncshons beyond the web API is needed.

JSDoc or Typescript annotation

Though, despite what I just wrote, maybe something that generated JSDoc or Typescript annotation from the types in WikiFunctions might be cool and maybe useful to someone.

In short

In short, I don't think something like GObject's type introspection is relevant to WikiFunctions because of the use of dynamically typed languages and the non need for other language to interface with WikiFunctions outside of the api.

Links to things about GObject and GObject type introspection:

• https://docs.gtk.org/gobject/concepts.html
• https://gi.readthedocs.io/en/latest/
• https://docs.gtk.org/gobject/struct.Value.html

CoderThomasB (talk) 04:00, 30 September 2023 (UTC)

Type for morphological function

There has been some discussion and wondering about the types a morphological function should take. For example, in the Beta, we have the following functions:

• English plural
• French plural
• Swedish genitive
• German feminine plural
• Croatian feminine plural nominative

All of these functions take a string and return a string. Now one could argue that they really should take a monolingual text and return a monolingual text.

There are several points to consider:

1. first, history: why do we have a monolingual text? It's an idea I carried over from Wikidata, and for Wikidata we had carried that over from RDF, where it is called a language-tagged string.
2. the advantage of monolingual texts come in particular from their role in a multilingual text, where we can select a specific language from a dictionary with several languages.
3. stronger typing usually avoids certain mistakes. It is usually a really good idea to type, for example, numbers and dates, in order to avoid adding them up in a meaningless way. Personally I have a bias towards stricter typing, as you can see. And yet I find myself wondering if it makes sense in this case: what kind of errors would we be able to avoid by this stricter typing? What kind of helpful hints do we give to the users by using this stronger typing? I am a bit of a loss here, I am not sure I see an immediate advantage.
4. if a function such as "English plural" has the input type "Monolingual text", this would mean that everyone using that function needs to, in addition to enter the word they want to pluralize (e.g. "book"), also enter the language, i.e. English. But how useful is that? What if it is a different language? What's the point of forcing the user to select that every time?
5. in the end, the implementations would probably be something like "check if this is the right language(English) -o- get the string from the monolingual text -o- do the actual string manipulation -o- package it as a monolingual text(English)". So we would likely have a string-based function to do the string manipulation anyway, in addition to the one based on monolingual text?
6. but the representations of the forms of the Lexemes in Wikidata will all be coming as monolingual text, so having the same type seems an advantage when we tie together with Wikidata for the natural language generation?
7. I guess for each of those functions, we would simply ensure that they have the right language, raise an error. That seems again not particularly friendly: why ask for the language then at all?
8. a minor advantage is that we could start right away with morphological functions and don't need to wait for the monolingual text type to become properly supported.

Particularly Point 4 is giving me a headache, and gently nudging towards "let's just use strings for morphological functions".

I would like to get input from the community on this question. In particular calling @Mahir256 who I know is interested in that question, but I sure hope there are others. I honestly don't know what the best approach is. I am also happy to answer any further questions to help with the decision finding. -- DVrandecic (WMF) (talk) 03:23, 30 August 2023 (UTC)

This is far outside my expertise, and I'm monolingual to boot, but I'm still building a multilingual tool (wikidata:Wikidata:Entity Explosion) which I hope will use some of these string functions in future. I would expect that in the long term we will want both a monolingual and a string version. I agree with you in #5 that one will often wrap the other. One thing you haven't mentioned above is that the monolingual version will also require/ensure a single script system, so we won't get mishmashes like (Greek)'βιβλίο'+(Latin)'s'. I imagine there would be an advantage to some calling functions to be able to assume that the output was in the script/language they expected, without having to do a subsequent check. So the bit you described as "package as a monolingual text" may be doing some heavy lifting? But other reusers would be more carefree and could just call the general string version if they didn't really care what came back (or if they knew they had already sanitised their input). --99of9 (talk) 01:05, 31 August 2023 (UTC)

What I can come up with as cases when languages are mixed in when the subject of the article is a specific language. Then there might be cases where we use some "plural" descriptor/constructor and it’s not really the same language as the default rendering language and we might have to use a specific function instead of the "default" renderer for the language, and we might be happy if there an error because we mixed-up stuff.

What seems sure is that if we have a function "english plural" it could be useful to have just a function "plural", generic to all languages and selects the good function according to the language tag. If we do this it’s pretty certain that we always selects the right function for the language, so usually few possibilities of errors. Maybe there are some cases where we get a random lexeme from a query from Wikidata and, for some sophisticated language generic situation, stuffs become mixed up and we end up calling a renderer for this lexeme and the languages do not match, however.

It’s probably irrelevant (and a rabbit hole), but this switching functions according to types reminds me of the notion of "dependant types" : https://cstheory.stackexchange.com/questions/33984/dependent-types-and-compile-time-types , where the type system can do sophisticated stuffs like selecting a type according to a runtime value and do sophisticated verifications, but I believe it’s hard to get to such sophistication in the Wikifunction case. Is Wikifunction type system sophisticated enough to be able to express some kind of useful specification to the code ? And how will implementations handle this ? I guess it could be interesting at the implementation level if the typing helps us to guarantee that some situations never occurs to simplify the implementation, which could be a win. This is an interesting stuff to think about because Wikifunction always have an intermediate step between nested function call, however, putting verifications at that step. If the implementation indeed are correct and respects the typing contracts, everything should be fine. TomT0m (talk) 18:06, 31 August 2023 (UTC)

I guess an answer for 4 to not force everyone to enter a tag would be that the UI (and the type system?) is aware of the type "English string" and in this case just selects the right tag for the value. You then have a widget that just asks for the string and just adds automatically the tag to the value. TomT0m (talk) 18:12, 31 August 2023 (UTC)

Personally, I think that since the name of the function is "English plural", the function will only be called in an English context and the input and output parameters should simply be strings. A multilingual function, perhaps "plural", would use monolingual text and would then call "English plural" in the English case, "pluriel français" in the French case etc., but once the language is determined, strings are better. Using monolingual text in the English case adds complexity and I do not think there is much advantage - it can only add checks for cases which should never occur, as you have to get the context right anyway. There is a general feeling that stronger typing is more virtuous, but I think that that is not always true. Strobilomyces (talk) 12:11, 19 September 2023 (UTC)

I'm pretty sure a monad would be able to do the job (something like an English string type) 0xDeadbeef (talk) 04:03, 16 October 2023 (UTC)

My two cents: monolingual text seems to be a crude and ineffective way to check if the entry is valid. For instance, English plural applies to nouns only in all variations of English. For instance, if you enter "be"@en is a verb but the monolingual text type can't check that and will produce "bes"@en. On the other hand, British english behaves (almost always) like English but "dog"@en-GB would be refuse if the function expect strictly @en texts (and I don't even imagine for more comple case like sr-Latn and sr-Cyrl or like Wikidata specific and private tags: "piou"@br-x-Q54555486 :/). In both these cases, monolingual text is too wide and too narrow. That said, we definitely need something that allows to check if the entry is valid or not. Cheers, VIGNERON (talk) 13:13, 21 October 2023 (UTC)

Function naming?

Should we create a naming guideline for functions, implementations, and test cases? Right now it's a mix of different styles. I've been using title case for function names (for example, substring exists (Z10070)), some people have been using all lowercase (like join two strings (Z10000)), and some have capitalized only the first letter (like string equality (Z866)). Ingenuity (talk) 02:55, 5 August 2023 (UTC)

Strong yes! -- DVrandecic (WMF) (talk) 06:57, 5 August 2023 (UTC)

I'd personally prefer Wikidata/Wiktionary style labels (lower case unless there's a reason not to), alternatively first letter capitalized, like Wikipedia. My main reason for not liking title casing is that it is not used in many languages, like my native Swedish. A weaker rule-set would allow language variation under a common guideline. / Autom (talk) 08:04, 5 August 2023 (UTC)

The embedded objects already use Sentence case and that's what I'd prefer for names, no matter whether these are types, objects or functions (as it would simplify it for the end-users). I'm not against the all-lowercase, but I feel like naming non-functional objects that way may feel a bit strange (we might be used to naming classes starting with capital letter, whereas functions are named very differently in the languages and there's no predominant style, I think).

There's another question that arises. Should we recommend functions that contain a verb in their names? String equality does describe what the function does but doesn't suggest how to interpret the result. Even if many people would intuitively think of the function returning true for equal strings, there's C's strcmp that does something very opposite: false means equal. Not to mention that for non-technical users, names like SHA-256 may mean nothing (and may even clash with a potential type for a SHA-256 value). On the other hand [Cc]alculate a SHA-256 of string is way more descriptional and gives some clues what to expect from it.

I'm strongly in favor of creating naming guidelines, as it would make it easier for us not to get lost in the project after a few years and not to make is messy. Msz2001 (talk) 08:58, 5 August 2023 (UTC)

Note that you are also free to change the labels on the embedded objects to make it adhere to any style guide you come up with. -- DVrandecic (WMF) (talk) 16:16, 5 August 2023 (UTC)

I've just created page WF:Naming convention where I tried to summarize this section and place some other recommendations that I deem useful. Since everything other than not useing Title Case hasn't been polled, feel free to edit and/or extend the page :) Msz2001 (talk) 17:43, 20 August 2023 (UTC)

I like the draft as it stands so far. I think a next logical step would be to do a poll on whether labels should contain verbs and, in general, how descriptive they should be. I personally lean towards saying that they should as it would make it much more immediately clear what a function does. In any case, I feel that establishing these guidelines should be considered very important. For example of what to avoid, I have found contradictory recommendations for image captions on Commons which have confused me as a newer editor. Getting clear guidelines established quickly feels like a good way to avoid that. Bongo50 (talk) 22:03, 20 August 2023 (UTC)

Poll on capitalization

Please indicate whether you'd prefer Sentence case, Title Case, all lowercase, or something else. Ingenuity (talk) 21:29, 5 August 2023 (UTC)

• I'd prefer either sentence case or lowercase, since they are already widely used on other projects. Ingenuity (talk) 21:29, 5 August 2023 (UTC)
• I prefer all lowercase unless things should be capitalized. E.g. K combinator (Z10249). 0xDeadbeef (talk) 04:12, 6 August 2023 (UTC)
• I prefer lowercase --Ameisenigel (talk) 09:03, 6 August 2023 (UTC)
• For the functions, I prefer all lowercase. Lepticed7 (talk) 09:42, 6 August 2023 (UTC)
• Either lowercase or sentence case. Msz2001 (talk) 10:57, 6 August 2023 (UTC)
• I prefer lowercase too, unless there is some stuff that has to be capitalized (like @0xDeadbeef showed) Poslovitch (talk) 11:14, 6 August 2023 (UTC)
• Lowercase, with exceptions like described above allowed. /Autom (talk) 12:44, 6 August 2023 (UTC)
• The scope of the poll could be made clearer — is it (i) only for functions or broader and (ii) only for English or broader? Assuming we're talking English labels for functions, I think all lowercase is reasonable. I would be fine with Sentence case and do not like the idea of using Title Case or CamelCase for this purpose. --Daniel Mietchen (talk) 21:57, 7 August 2023 (UTC)
• I prefer lowercase too. –– Tahmid (talk) 04:08, 8 August 2023 (UTC)
• Our "function names" are actually labels; their true names look like Z followed by a meaningless number. There is really no reason not to follow Wikidata's convention (i.e. lowercase). NguoiDungKhongDinhDanh (talk) 07:15, 8 August 2023 (UTC)
• Either works, but consistency and maybe a style guide is needed. Wd-Ryan (talk) 23:26, 8 August 2023 (UTC)
• I'd prefer all lowercase with exceptions as brought up above. Bongo50 (talk) 10:54, 20 August 2023 (UTC)
• I don't really care about the chosen solution but I agree that we should talk about it and write some guidelines. And if possible, make the solution simple. Cheers, VIGNERON (talk) 17:25, 21 August 2023 (UTC)
• I also prefer lowercase by default. Waldyrious (talk) 15:14, 23 August 2023 (UTC)
• Piling on to agree with the lowercase-with-exceptions consensus for function names. --99of9 (talk) 00:21, 31 August 2023 (UTC)
• Follow d: convention as per above by NDKDD. Koavf (talk) 06:19, 9 September 2023 (UTC)
• All lowercase is fine to me. Pamputt (talk) 13:54, 26 September 2023 (UTC)
• I would like all lowercase. GothamRCity (talk) 23:55, 25 October 2023 (UTC)