Wikifunctions:Project chat

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

Other places to find help:

• Wikifunctions:Administrators' noticeboard
• Wikifunctions:Report a technical problem
• Wikifunctions:FAQ
• Wikifunctions:Apply for editing

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

edit
Archives
2023/08 2023/09

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 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)

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 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)

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)

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)

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. to NFC (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)

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)

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)

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)

Editing sandboxes

I see Wikifunctions:Sandbox is open to editing for all editors, but as of before getting functioneer, the sandboxes listed there (e.g. Sandbox-Function (Z10119), the function sandbox) did not allow editing unless you have the right user access group. Is this intended? Skarmory (talk) 05:48, 1 September 2023 (UTC)

I think it’s an issue where you can’t let everyone edit a function (yet), only functioneers. Zippybonzo (talk) 10:56, 3 September 2023 (UTC)

Object annotations

Hi, I think it would be very useful and powerful to "annotate" with extra information each kind of object, for example:

• type: granularity, range, modulo, holes, physical units, measurement scale (nominal, ordinal, interval, ratio)...
• function: pre-conditions, post-conditions...
• implementation: computational complexity, space complexity, algorithm used...
• test: nominal / robustness / boundary test, autocoded test...

Of course these are just examples, and it can be argued whether each one should be available or not, but the general capability to add this "semantic information" that can be used by different tools (e.g. tools to check if every function is tested with both nominal, boundary, and robustness tests). Maybe "keys" can already be used to annotate objects with these different annotation, or otherwise we can use templates in the talk pages temporally until Wikifunctions support this concept. Do you think keys can be used for that? Which additional annotations do you think can be added? Thanks! —Suruena (talk) 09:11, 2 September 2023 (UTC)

There's a similar request in Phabricator, T344038. I think that the idea is great, and would be very interesting to implement, but for now I would like to see it, as you suggest, implemented through talk pages and templates, so that we can see about its usefulness, and then partially implement with keys, when we find something particularly useful. Some of these things, such as the complexity class for a problem, I think really belongs on Wikidata (especially if these are theoretical results with their own paper, etc.) In the end, this can be tremendously useful - think of the way annotation on properties have developed on Wikidata - and I think using the talk pages in that way is a good way to kick this work off without waiting for resources from the development team. --DVrandecic (WMF) (talk) 21:18, 29 September 2023 (UTC)

Creating types

Hi, I just created the function is leap year (Gregorian calendar) (Z10996), but even if the input type should be a "year" (specifically a Gregorian year), as currently I think it's not possible to create a new type (tried creating year (Z11002) but not really a type, and I have not permissions to create an actual type) so I used instead directly a String (because numbers are not allowed yet either...). Even if this works for now, I think that in the future it would be needed to modify the function to use a proper type instead (for example, annother function is needed if the year follows the Julian calendar instead of the Gregorian calendar). I assume that new Types cannot be created by everybody, but only by admins because need to be agreed by the community (like the Wikidata properties). In my opinions each function should be as precise as possible regarding the types expected and returned, so users known clearly what to expect from the functions and to simplify implementations. Can anybody confirm if types are expected to be created just by admins? In any case, I propose to create a dedicated template like template:new type to temporally annotate those functions that should use a different type not available yet. Opinions? Thanks —Suruena (talk) 09:29, 2 September 2023 (UTC)

As far as I know, at the moment, Wikifunctions only support passing strings and bools to functions. Eventually it will be possible to define and pass any type. Creating functions dealing with other types is not recommended now and such existing ones are marked usually with (!) at the beginning of its name.

Currently, only staff can create new types but according to mw:Help:Wikifunctions/User rights, the ability will be eventually given to all functioneers. Msz2001 (talk) 13:58, 2 September 2023 (UTC)

@Suruena Hey, sorry for replying this late to your message. I suggest you to use Wikifunctions:Suggest a function in cases like this, so that we can take note of what type we should be focusing on more when developing the new types. Sannita (WMF) (talk) 15:59, 5 September 2023 (UTC)

Unable to edit Z868

Tried to edit String to list (Z868) but was unable to do so as it does not have a return type set (and I could not set it to be anything; it appears to return a list of code points). Can anyone help with this? ネイ (talk) 11:38, 2 September 2023 (UTC)

Also there seems to be a bug with the Discussion Tool. On Talk:Z868 the sentence generated by Discussion Tool reads as follows (the span tag is shown): "You can use this page to start a discussion with others about how to improve String to list (<span dir="ltr">Z868</span>)." ネイ (talk) 11:39, 2 September 2023 (UTC)

Thanks for reporting! The DiscussionTools bug is tracked at phab:T344491. Quiddity (WMF) (talk) 19:42, 8 September 2023 (UTC)

It's missing an Output type, because the appropriate List type isn't supported yet. This Object (and similar ones) will be fixed by the development team once the relevant types has been finalized. See more context at Wikifunctions:Status#Only String and Boolean types are supported. I hope that helps. Quiddity (WMF) (talk) 19:45, 8 September 2023 (UTC)

Thank you for the pointers! Will wait and see whether they get resolved. ネイ (talk) 08:38, 10 September 2023 (UTC)

Blocking policy?

Hello all. I will like to propose to introduce a local blocking policy (link). The page is largely based of its common's counterpart. CU & OS subsections can be commented out as we're likely not gonna have any local CU/OS anytime soon. Comments? Minorax (talk) 08:08, 3 September 2023 (UTC)

Seems good, we might end up with CU and OS so just leave that section as draft I would say. Zippybonzo (talk) 10:55, 3 September 2023 (UTC)

 Support with the removal of the CU/OS sections and explicit mentions, the policy makes sense however I strongly disagree that they should be left as drafts since this is likley to just add to confusion and will imply that CU/OS blocks are local since they are on the local policy page. There is nothing stopping such sections just being added through discussion in the future. Terasail^[✉️] 11:36, 3 September 2023 (UTC)

👍 · ^מקף Hyphen _෴ · 12:11, 3 September 2023 (UTC)

I  Support generally, but I think it should include how would we handle the situation of a global block that needs to be whitelisted locally and users who need the ipblock-exempt permission. Also, I suggest removing the part of CU/OS as well. Xnet1234 (talk) 19:29, 3 September 2023 (UTC)

It seems better to exclude CU/OS block. When it is necessary to introduce it, it can be introduced either through a separate RFC or by forming a consensus. I agree with the rest. --Sotiale (talk) 11:34, 4 September 2023 (UTC)

 Support with removal of CU/OS --Ameisenigel (talk) 17:06, 4 September 2023 (UTC)

 Support with removal of CU/OS for now. Koavf (talk) 06:24, 9 September 2023 (UTC)

Translation Administrator requirements

There are currently no local or Meta-Wiki requirements for Translation Administrator and the guidelines currently listed at Wikifunctions:Translation administrators#Requirements are currently pulled from Administrator requrements in order to have a baseline for steward requests. This will be unique to Wikifuntions since all other projects rely on bureaucrats to decide when to grant TA. I am proposing that Wikifunctions replaces what is currently listed and adds the following requirements:

• Create a new discussion section requesting the user group at Wikifunctions:Requests for user groups#Translation administrator.
• Allow 1 week for any discussion.
• The candidate must obtain at least 2/3 (two thirds) support.
• Present a sample edit to demonstrate your practical experience with the translation syntax (Suggestion from Minorax)

This should clear things up since the active guidelines were never considered by the community and just added by myself which shouldn't stand for a long period of time.

Do you think this is a positive change and do you have any thoughts? Terasail^[✉️] 11:57, 3 September 2023 (UTC)

Seems fine. However, I'd like the requester to have an example of how they would use the tool if granted (similar to the requirements on meta). Minorax (talk) 13:36, 3 September 2023 (UTC)

That is a good idea, I had not thoroughly read through the Meta-Wiki policy but "Present a sample edit to demonstrate your practical experience with the translation syntax" is a good idea. I will add it above, Thanks. Terasail^[✉️] 16:15, 3 September 2023 (UTC)

Looks good to me --Ameisenigel (talk) 17:06, 4 September 2023 (UTC)

I have added these changes to Wikifunctions:Translation administrators Terasail^[✉️] 16:02, 22 September 2023 (UTC)

Search issues

I think we should make search search for functions instead of mainspace because the current search is really hard to use to the point where it is nearly impossible to use. Zippybonzo (talk) 15:39, 3 September 2023 (UTC)

There's currently a bug with the inline autocomplete search (not showing any results), but if you click [enter] or the "Search" button it should give full search results. See the similar thread #Function exists? above.

If I've misunderstood which issue you're describing, please clarify further. Thanks! Quiddity (WMF) (talk) 18:57, 8 September 2023 (UTC)

Function maintainer requirements

I am proposing the following local requirements for the Wikifunctions:Maintainers group:

• Create a new discussion at Wikifunctions:Requests for user groups
• Allow 1 week for discussion.
• At least 3 votes and an 80% support ratio.
• Already a functioneer.

I will provide any reasoning for my individual points upon request, but it's mostly to ensure only trusted and experienced users can have the right to ensure that nothing gets broken accidentally. Zippybonzo (talk) 10:38, 4 September 2023 (UTC)

I think it is a bit too early to be setting out maintainer requirements, considering that the maintainer group has yet to be utilized. Currently only WF Staff can give out the maintainer group and with WF still in limited roll out, we should not be restricting what the staff wish to do with such a role until the group is handed over to the community to manage. On another note, these requirements are currently higher than the requirements to get administrator so that isn't great either. Terasail^[✉️] 10:49, 4 September 2023 (UTC)

I agree with Terasail that it might be too early to define these requirements --Ameisenigel (talk) 17:08, 4 September 2023 (UTC)

It'd still be worth keeping this in mind for when group assignments are handed over to the community. Deauthorized (talk) 07:07, 5 September 2023 (UTC)

Gateway timeout. Is Wikifunctions overloaded already?

I wrote a composition implementation of string is element of CSV (Z11094), and have noticed that the simple test cases often timeout. The composition requires quite a few sub-calls, but nothing is inherently computationally expensive. Since I'm currently the only editor in recent changes, I seem to be stressing WF on my own!? Is scalability going to be a big issue? --99of9 (talk) 01:33, 14 September 2023 (UTC)

@99of9: Thanks much for calling attention to this. I see there was a flurry of RequestTimeoutException during August 24-28, then none of those until September 14, when some more of them occurred. We will continue to monitor this. One question: when you observed these timeouts, did the UI show you an explicit timeout error message? (If so, and if you see it again, please copy it to here.) Thanks! DMartin (WMF) (talk) 04:23, 15 September 2023 (UTC)

@DMartin (WMF): Yes, I can still reproduce it. Go here, then if any of the top three tests fail with an X, click details. In my case I see the second test failing, then get the following details:

composition of substring tests

string split across two elements is not an element

Error summary: [Z507/Error in evaluation] {"Z1K1":"Z7","Z7K1":{"Z1K1":"Z8","Z8K1":["Z17",{"Z1K1":"Z17","Z17K1":"Z6","Z17K2":"Z11094K1","Z17K3":{"Z1K1":"Z12","Z12K1":["Z11",{"Z1K1":"Z11","Z11K1":"Z1002","Z11K2":"string"}]}},{"Z1K1":"Z17","Z17K1":"Z6","Z17K2":"Z11094K2","Z17K3":{"Z1K1":"Z12","Z12K1":["Z11",{"Z1K1":"Z11","Z11K1":"Z1002","Z11K2":"comma-separated value series"}]}}],"Z8K2":"Z40","Z8K3":["Z20","Z11095","Z11097","Z11100","Z11106","Z11107","Z11108","Z11109","Z11110"],"Z8K4":["Z14","Z11099"],"Z8K5":"Z11094"},"Z11094K1":"day,Wed","Z11094K2":"Monday,Tuesday,Wednesday,Thursday,Friday,Saturday,Sunday"} Validator error summary: [Z507/Error in evaluation] Expected result: {"Z1K1":"Z40","Z40K1":"Z42"} Actual result: {"Z1K1":"Z5","Z5K1":"Z507","Z5K2":{"Z1K1":{"Z1K1":"Z7","Z7K1":"Z885","Z885K1":"Z507"},"K1":"{\"Z1K1\":\"Z7\",\"Z7K1\":{\"Z1K1\":\"Z8\",\"Z8K1\":[\"Z17\",{\"Z1K1\":\"Z17\",\"Z17K1\":\"Z6\",\"Z17K2\":\"Z11094K1\",\"Z17K3\":{\"Z1K1\":\"Z12\",\"Z12K1\":[\"Z11\",{\"Z1K1\":\"Z11\",\"Z11K1\":\"Z1002\",\"Z11K2\":\"string\"}]}},{\"Z1K1\":\"Z17\",\"Z17K1\":\"Z6\",\"Z17K2\":\"Z11094K2\",\"Z17K3\":{\"Z1K1\":\"Z12\",\"Z12K1\":[\"Z11\",{\"Z1K1\":\"Z11\",\"Z11K1\":\"Z1002\",\"Z11K2\":\"comma-separated value series\"}]}}],\"Z8K2\":\"Z40\",\"Z8K3\":[\"Z20\",\"Z11095\",\"Z11097\",\"Z11100\",\"Z11106\",\"Z11107\",\"Z11108\",\"Z11109\",\"Z11110\"],\"Z8K4\":[\"Z14\",\"Z11099\"],\"Z8K5\":\"Z11094\"},\"Z11094K1\":\"day,Wed\",\"Z11094K2\":\"Monday,Tuesday,Wednesday,Thursday,Friday,Saturday,Sunday\"}","K2":{"Z1K1":"Z5","Z5K1":"Z500","Z5K2":{"Z1K1":{"Z1K1":"Z7","Z7K1":"Z885","Z885K1":"Z500"},"K1":"Gateway Timeout"}}}}

--99of9 (talk) 11:31, 17 September 2023 (UTC)

@99of9:, thanks! Using your instructions, I saw the same error myself 2 or 3 times during the last couple days, but today it's not occurring for me, plus the tests seem to finish considerably faster. Afraid I can't explain the improvement, but will continue to monitor. In the meantime, your implementation page has brought to light a bad bug: after clicking on any of the Details links, the page freezes. I can't do anything else until I refresh the tab. I'm wondering if this is specific to my OS/browser combination. Have you also seen this behavior?

DMartin (WMF) (talk) 05:28, 21 September 2023 (UTC)

@DMartin (WMF): Yes, that happens to me too at the moment. I can't remember if it was different before. --99of9 (talk) 05:52, 21 September 2023 (UTC)

Page on Wikidata about interoperation with Wikifunctions

Heads up that I created a barebones page at d:Wikidata:Wikifunctions, as all the other sister projects have similar such pages. It would be great if users here who are motivated to figure out how the two projects can work together would help flesh out that page. Thanks. ―Justin (koavf)❤T☮C☺M☯ 08:28, 14 September 2023 (UTC)

@Koavf Thank you very much! Sannita (WMF) (talk) 12:22, 15 September 2023 (UTC)

Can categories be added to main namespace pages?

This project doesn't use categories at all in the main namespace. Consequently, special pages like Special:UncategorizedPages become useless because they are flooded by entries. Is it possible on a technical level to add something like Category:All functions to just make one category that all of these are in to clear out that special page into something that can be reasonably used? If that is not possible locally, is there at least consensus to make a ticket at phab: for this feature? ―Justin (koavf)❤T☮C☺M☯ 06:04, 17 September 2023 (UTC)

I think it's better to configure Wikifunctions with the settings of Wikidata as the concept is the same. Minorax (talk) 06:52, 17 September 2023 (UTC)

The same problem exists on Wikidata. ―Justin (koavf)❤T☮C☺M☯ 07:47, 17 September 2023 (UTC)

@Koavf: Unfortunately, the "categories" system in MediaWiki is a wikitext-exclusive feature. There has been discussion for over a decade about changing this (e.g. as part of T112999 and other broad topics), for which I've gently lobbied, but it'd cost a awful lot to change over to a proper system for marginal use cases, so hasn't been seriously explored.

There's an existing, much simpler, feature request at T305363 to provide a way to hide non-wikitext pages from such listings, but I'd just recommend you not waste time looking at them.

---

I'd roughly guesstimate a couple of years and a few million US$ in development cost, and maybe a tenth of that for new servers/etc. depending on desired feature set. Requested features like T5311 would become possible, but would also add to the cost, for example.

To be clear, marginal use cases for Wikipedias, which dominates general MediaWiki development discussions; obviously here on Wikifunctions, or over on Wikidata, this would have immediate utility, plus also on Gadgets' pages etc..

Jdforrester (WMF) (talk) 11:26, 18 September 2023 (UTC)

Thanks, JD. That's a little disheartening, but good to know. Very thorough response. ―Justin (koavf)❤T☮C☺M☯ 12:43, 18 September 2023 (UTC)

Will python or javascript functions be able to call other wikifunctions?

I hope so. Can they already? --99of9 (talk) 03:45, 18 September 2023 (UTC)

Eventually yes, but it's not a superurgent feature for us right now. -- DVrandecic (WMF) (talk) 00:17, 23 September 2023 (UTC)

Wikifunctions & Abstract Wikipedia Newsletter #127 is out: Renderers and parsers for types

There is a new update for Abstract Wikipedia and Wikifunctions. Please, come and read it!

In this issue, Denny introduces a discussion about how to represent integers on Wikifunctions and its related challenges.

Want to catch up with the previous updates? Check our archive!

Enjoy the reading! -- User:Sannita (WMF) (talk) 08:07, 22 September 2023 (UTC)

I really appreciate these updates. I learn something every time. --99of9 (talk) 01:59, 29 September 2023 (UTC)

@99of9 That's encouraging and very sweet, thank you very much for this note. :) -- Sannita (WMF) (talk) 15:32, 29 September 2023 (UTC)

Running in a web browser

I see that function calls are currently restricted to logged in users. Maybe a way to make it less resource intensive would be to be able to run functions in the browser? JavaScript is obviously feasible, and Pyodide makes Python feasible as well. PiperMcCorkle (talk) 21:37, 25 September 2023 (UTC)

Yes, that is a good idea. We are currently working on putting our runtimes on top of WASM, and I am looking forward to explore pushing execution to the edge, i.e. to the user's browsers. I am not sure when the development team will get to this, but for now, if anyone wants to explore this further, this would be great. It might take a while until we get to it. -- Denny (talk) 22:04, 29 September 2023 (UTC)

Versions of languages?

What are the current versions of languages(Python and Javascript) which evaluators use? What happens when bumping the language? Would implementation be broken by the upgrade? Lens0021 (talk) 00:25, 28 September 2023 (UTC)

We're currently running node v16.17.1 and python v3.9.2.

One of our plans is to separate the runners into different versions of Python and Node, and let you write code against specific versions instead of the current generic "JavaScript" and "Python" tags. This adds flexibility (but also complexity!) to the on-wiki lifecycle. For instance, you'd write an implementation for Python 3.10 and tag it as such, and thus the system would only run it on Python 3.10 runners. At some point, Python 3.11 runners would be added, and a community member could check the code behaves as expected and update its tag to also run there (or not). As we upgraded production, eventually they'd be no Python 3.10 runners left, and so the implementation would be stranded, never to be run (and would show up on report pages as un-runnable implementations). However, none of this work has been done yet, so specifics may change! Jdforrester (WMF) (talk) 14:07, 28 September 2023 (UTC)

Circular compositions

I just made a composition for remove at end (Z11170) using replace at end (Z11178), but then saw that there's already a composition for replace at end (Z11178) using remove at end (Z11170). Will these loops of compositions cause problems? I imagine it would be hard not to if they were the only implementations of both functions!? --99of9 (talk) 01:58, 29 September 2023 (UTC)

They *shouldn't* (TM) cause an issue beyond failing if there is no other implementation. It shouldn't be the contributors job to worry about potential circular compositions (also, note, that we explicitly support recursive compositions). -- Denny (talk) 22:02, 29 September 2023 (UTC)

Open request for adminship

I have started a request for adminship for myself at Wikifunctions:Requests for user groups#Terasail which is set to close at 11:01, 6 October 2023 and would appreciate any input.

Thanks, Terasail^[✉️] 11:03, 29 September 2023 (UTC)

Should Compact JSON of "{ 'x' : 2 }" should be "{'x':2}" (Z10361) use single quotes?

It's technically not the exact test, but the alternative [two sets of double quotes, i.e. Compact JSON of "{ "x" : 2 }" should be "{"x":2}"] felt weird. Infernostars (talk) 16:13, 29 September 2023 (UTC)

Wikifunctions & Abstract Wikipedia Newsletter #128 is out: Serializers and deserializers for types

There is a new update for Abstract Wikipedia and Wikifunctions. Please, come and read it!

In this issue, Denny introduces a discussion about how to make types easier to use, by discussing serializers and deserializers, and their role in Wikifunctions.

Want to catch up with the previous updates? Check our archive!

Enjoy the reading! -- User:Sannita (WMF) (talk) 16:47, 29 September 2023 (UTC)

Also, a brief reminder/highlight that the next "Wikifunctions & Abstract Wikipedia Volunteers' Corner" will be held on October 2 at 13:30–14:00 UTC (earlier than the previous) in an open video call meeting (using Google Meet).

If you have questions or ideas to discuss, or you want to get in touch with the dev team, please join us! We will also hold another live demo on how to create a function. Quiddity (WMF) (talk) 20:01, 29 September 2023 (UTC)