Wikifunctions:Project chat/Archive/2024/01

From Wikifunctions


Newsletter #137: Introducing our first new type: Lists

The newsletter introducing our first new types can be found on Meta. Feel free to discuss here! And Happy New Year! --DVrandecic (WMF) (talk) 23:40, 3 January 2024 (UTC)

Been waiting on that for months. I guess it's a good time to come back to Wikifunctions, as lists are a whole new Eldorado: sorting algorithms, easier implementations in Composition and better ways to handle inputs! Poslovitch (talk) 00:11, 4 January 2024 (UTC)
This section was archived on a request by: Sannita (WMF) (talk) 15:54, 26 January 2024 (UTC)

Wikifunctions & Abstract Wikipedia Newsletter #137 is out: Introducing our first new type: Lists

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

In this issue, we introduce our newest and much requested type of function, list. Also, we take a look at the latest software developments.

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

Also, we remind you that if you have questions or ideas to discuss, the next Volunteers' Corner will be held on January 8, at 18:30 UTC (link to the meeting).

Enjoy the reading! -- User:Sannita (WMF) (talk) 10:37, 5 January 2024 (UTC)

This section was archived on a request by: Sannita (WMF) (talk) 15:54, 26 January 2024 (UTC)

Wikifunctions & Abstract Wikipedia Newsletter #138 is out: The Joy of Collaboration; Introducing the Function of the Week: reverse string

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

In this issue, we present you an essay from Denny and we introduce a new section of the newsletter, dedicated to the "function of the week". Also, we take a look at the latest software developments.

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

We also wanted to note that we are in the process of moving the Updates from Meta to Wikifunctions. We'll keep you updated about it.

Enjoy the reading! -- User:Sannita (WMF) (talk) 12:27, 12 January 2024 (UTC)

This section was archived on a request by: Sannita (WMF) (talk) 15:54, 26 January 2024 (UTC)

Informing you about the Mental Health Resource Center and inviting any comments you may have

Hello all! I work in the Community Resilience and Sustainability team of the Wikimedia Foundation. The Mental Health Resource Center is a group of pages on Meta-wiki aimed at supporting the mental wellbeing of users in our community.

The Mental Health Resource Center launched in August 2023. The goal is to review the comments and suggestions to improve the Mental Health Resource Center each quarter. As there have not been many comments yet, I’d like to invite you to provide comments and resource suggestions as you are able to do so on the Mental Health Resource Center talk page. The hope is this resource expands over time to cover more languages and cultures. Thank you! Best, JKoerner (WMF) (talk) 21:43, 18 January 2024 (UTC)

This section was archived on a request by: Sannita (WMF) (talk) 15:54, 26 January 2024 (UTC)

Wikifunctions & Abstract Wikipedia Newsletter #139 is out: Refreshing the Function page; Function of the Week: ROT13

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

In this issue, we announce a redesign and rewrite of the Function page and we present our first "function of the week". Also, we take a look at the latest software developments.

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

Enjoy the reading! -- User:Sannita (WMF) (talk) 12:05, 19 January 2024 (UTC)

This section was archived on a request by: Sannita (WMF) (talk) 15:54, 26 January 2024 (UTC)

French function

Hello, I discover this wikimedia project, bravo! Two questions

Bouzinac (talk) 15:52, 2 January 2024 (UTC)

Hi, @Bouzinac! The function implementations are indeed viewable (and as far as I know editable) for any users. Wikifunctions by design split the function itself and its implementations (there can be multiple). French regular plural (Z11548) is just a function definition (i.e. what inputs does it take, what is its return type). If you head to the details tab on that page, you'll see a list of implementations and test cases. Every such entity is a separate page. The said function has one implementation, French plural, Python (Z11550) in Python. You should be able to view it and maybe able to edit as well. (The interface, especially it being split into two tabs, may change in future, so that the implementations might be available on the same page where the general info is).
Regarding the question to ask for an improvement, I'm not sure how to answer. Certainly, one of possibilities is to create a new implementation that does better and add some test cases to reflect that. But I don't think it's the best way to do it (or maybe it is, depending on assumptions how Wikifuntions should work). In theory, the execution software should pick the correct implementation out of available ones (but I don't know if it already implemented). Msz2001 (talk) 16:51, 2 January 2024 (UTC)

Wikifunctions & Abstract Wikipedia Newsletter #140 is out: Getting debug information from code; Function of the Week: Wrap string

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

In this issue, we discuss debugging in implementations and we present our new "function of the week". Also, we take a look at the latest software developments.

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

Enjoy the reading! -- User:Sannita (WMF) (talk) 10:54, 26 January 2024 (UTC)

This section was archived on a request by: Sannita (WMF) (talk) 11:28, 2 February 2024 (UTC)

Functions and implementations versioning

Given the previous section about the grandfather clause, is it possible to imagine being able to use a version of an implementation's history? It seems terribly flawed to me, but the question begs to be asked. Perhaps it's more desirable to be able to use a version of a function than of an implementation? Lofhi (talk) 05:15, 6 January 2024 (UTC)

I'm not sure if it's intended or not (perhaps yes), but at the moment you are able to run an older version of an implementation. For example, go to: https://www.wikifunctions.org/wiki/Z10331?oldid=30878 (this is a flawed version of implication which for true and true yields incorrectly false). Interestingly, test cases are run using the current version of that implementation.
Running an older version of a function does not make much sense to me. Eventually, functions (that is function definitions) should be stable not to break them for people who used the old function. Msz2001 (talk) 09:34, 6 January 2024 (UTC)

How to respect the grandfather clause?

The more time you take to take an interest in the project, the more you realize the difficulties that lie ahead. Does the grandfather clause have to be respected to the full with testing? But if so, who chooses the rules behind the specification of each function? By example, I am really not sure that the Python and Javascript implementations behind Trim String (Z10079) will always return the same result. What's a whitespace for both languages? Does it also take line terminators into account? Should theses differences be kept or fixed? Lofhi (talk) 05:13, 6 January 2024 (UTC)

Those are great questions! My suggestion would be that once we have tests that show that two implementations behave differently, we should either drop one of the implementations, or we should split the function in two. We should not keep implementations that behave differently, but fix them. --Denny (talk) 23:08, 8 January 2024 (UTC)

Linking to the code for Built-in-functions

I have looked at the Javascript-File in Gitlab what includes as far as I understand the definitions for Built-in-functions. You can find this file here. From my point of view it is interesting to see also for built-in-functions how they work. What do you think about setting a link to the code file in the banner already visible in Built-in-functions. I have not found a template for this on the wiki. At the moment it is from my point of view very difficult to find the definitions of built-in-functions in Wikifunctions. Hogü-456 (talk) 21:14, 8 January 2024 (UTC)

Sounds like a fine idea. It would be great to have an approach that doesn't increase maintenance work in case of refactorings or code changes. Not sure how simple that is. --23:16, 8 January 2024 (UTC) DVrandecic (WMF) (talk) 23:16, 8 January 2024 (UTC)

Generating SPARQL and SPARQL fragment, perspectives ?

Hi, it’s early to talk about that, but I’m starting to work on a Wikidata query gadget based on SPARQL fragments, (see d:Help:Partial query on Wikidata for what kind of fragments are already available).

The assumption is that these kind of fragment may offer a higher level way for users to query Wikidata. I’m starting a user interface to build query based on this. A fragment is a template with parameters, a query built with fragment, simple version, could be a list of fragment with parameters. (For example a list of criteria : ?item has an article in enwikipedia ; ?item was a state president in 1900 ; ?spouse was the spouse of ?item in 1800)

Currently the fragments are templates, but I think that in the future they could very well become wikifunctions … It could even be a usecase for abstract content, query generation based on high level descriptors ? TomT0m (talk) 13:51, 12 January 2024 (UTC)

is single element list (Z12755)

Please can someone help me write a composition for this? I tried, using If (Z802), Is empty list (Z813) (once as a condition on returning false, and then once to wrap around list without first element (Z812) for the final answer), but I got an obscure key-ID error, and I'm not sure if I got something wrong or if there is a bug. --99of9 (talk) 09:45, 13 January 2024 (UTC)

I also just got a similar error when trying to write a recursive composition for concatenate lists (Z12767) using prepend element to list (Z810) first element (Z811) list without first element (Z812) Is empty list (Z813) and reverse list (Z12668). It might be something related to passing a list argument as an argument reference. --99of9 (talk) 11:25, 13 January 2024 (UTC)

Generic list equality check: [Z503/Not implemented yet]

I am in love, and new, but in love, but confused. What does it even mean? [Z503/Not implemented yet]. I was trying to implement some generic list equality check. Z12673 is the function, Z12674 is the implementation, ["abc", "ab", "a", "abcd", "1", "12"] sorted is [ "a", "1", "ab", "12", "abc", "abcd" ] (Z12675) is the broken test used in sort a list by string length (Z12671). Got ["Z1","a","1","ab","12","abc","abcd"] !== ["Z6","a","1","ab","12","abc","abdc"]. Why Z1 and Z6 are even added to the lists? Lofhi (talk) 07:21, 4 January 2024 (UTC)

I know that List equality (Z889) exists, but I wanted to try an implementation of it. Guess we can delete it when someone explains me these Z1 added ones! Lofhi (talk) 07:34, 4 January 2024 (UTC)
The first element of typed list seem indeed to be the type of the list...? Does it mean that the first element of a Typed list (Z881) is the type of the list... or the real first element of the list? first element (Z811) built-in function exists for this reason? Lofhi (talk) 07:50, 4 January 2024 (UTC)

Hi @Lofhi:! Welcome to the project, and sorry that it is still a bit confusing. Happy to help.

The no connected implementation yet (Z503) error comes up because the test ["abc", "ab", "a", "abcd", "1", "12"] sorted is [ "a", "1", "ab", "12", "abc", "abcd" ] (Z12675) uses the function Z12673, which has no implementation connected yet. So when the test case runs, the system doesn't know what to do, and says there's no implementation yet.

Whereas the internal representation of a list does indeed include the type as its first element (see the function model, this shouldn't be true when it is translated to Python or JavaScript. There, an empty list should be just [], and a list with a single string "x" should be ["x"]. I wrote a Python and JavaScript implementation for length of list on the Beta, and you can see with the tests that the numbers are as expected: length of list on Beta (note that we shouldn't copy those implementations, because they don't yet implement serialization and deserialization properly).

I hope that helps! Feel free to ask more questions! --DVrandecic (WMF) (talk) 00:43, 6 January 2024 (UTC)

Thanks for the details, @DVrandecic (WMF). Also, if I understand correctly, there is no sandbox-like available? Tests need to be done on Beta? Lofhi (talk) 04:12, 6 January 2024 (UTC)
@Lofhi: Yes, that's correct. Tests should go to the Beta. That's our Sandbox for now. --DVrandecic (WMF) (talk) 20:03, 8 January 2024 (UTC)
@DVrandecic (WMF): I still don't understand how to make it works: ["abc", "ab", "a", "abcd", "1", "12"] sorted is [ "a", "1", "ab", "12", "abc", "abcd" ] (Z12675). Lofhi (talk) 15:00, 12 January 2024 (UTC)
@Lofhi: I've made it work. Check out the three recent edits. --99of9 (talk) 02:01, 15 January 2024 (UTC)

Wikifunctions is a deterministic project

... but what about a seeded pseudorandom number generator? We could use a short-cycled value for the seed to hit as often as possible in the cache but still get some randomness. We could use the current weekday (1..7)/hour (0..23)/minute (0..59)? Or bigger cycles for longer caching validity (e.g. week number, month number)? Or the WMF really doesn't like the idea? Lofhi (talk) 12:20, 6 January 2024 (UTC)

I think it would make more sense to have a proper design for how to deal with random outputs. One way could be that the seed is part of the input, and thus it would avoid caching. Having a function that returns the current day would also be problematic with regards to caching: the current day should be an input, then it all works.
In short, it would be good to discuss this in much more detail (does someone want to start a page?). Until then, let's avoid non-deterministic output. --DVrandecic (WMF) (talk) 23:13, 8 January 2024 (UTC)
I've started a page here: WF:Determinism where I suggested some guidelines regarding determinism in Wikifunctions, feel free to comment and/or edit it. Msz2001 (talk) 16:06, 14 January 2024 (UTC)

How to use a reference to a parameter of a custom function definition ?

I probably missed something, and it’s an experiment and probably not the optimal way of doing something like that, but I tried to write a relatively complex test and got stuck at some time.

The context is the ROT13 function. I wrote a first test that checked that for a particular value the equality "x = rot13(rot13(x))" was fine. No problem with that.

Then I tried to generalize such a test by checking this property on a list of values, and began another test. I tried to use the function "all meet criteria" for this. It tries to check a predicate on a list of values. I tried to write an anonymous lambda function "x -> rot13(rot13(x)=x" for this, but I got stuck because I can’t find how to name the "x" parameter correctly and/or to reference it in the final call "rot13(x)" and in the equality test.

Is it me that missed something or is it not possible yet ? Do I need to create an explicit predicate wikifunction with an id for this to work atm ? TomT0m (talk) 10:17, 20 January 2024 (UTC)

I'm not sure if we support anonymous functions, but regarding the test cases, I believe the more granural tests are the better the outcome is. For example if there was a test whether the function is an involution for 10 words and it fails, we know nothing about where the error stems from. On the other hand, if they were 10 different test cases, it's very easy to find the word that's processed incorrectly and to find out whether one or ten cases fail. Msz2001 (talk) 13:10, 20 January 2024 (UTC)
Yes, that’s what I said it was a test and not optimal.
Anyway the user interface proposes to define a function on the fly as you define parameters for "all meet criteria", so I assumed it was kind of possible to define local functions, if not anonymous one. So if it’s unintended it’s quite misleading. TomT0m (talk) 16:36, 20 January 2024 (UTC)
A grouped approach could anyway be taken, while avoiding create a function page for the predicate to avoid code duplication.
Something like using a "filter" function instead of "all meets criteria", you return a list of the failing testcases. The attended results is the empty list, and the UI could show the actual result instead, so you would get a list of the string that do not pass. TomT0m (talk) 16:43, 20 January 2024 (UTC)

Marking functions that reference future types

Every now and then I notice new functions that obviously should take a number as input and/or should return a number, but instead use Strings as workarounds. I am marking them but I am afraid that I might be overlooking some. Any help is appreciated. MilkyDefer 08:00, 5 January 2024 (UTC)

To clarify: this means adding (!) to the beginning of the English function label so it shows up near the top of Special:ListObjectsByType/Z8 when changing interface language to English. /Autom (talk) 11:28, 21 January 2024 (UTC)

Translated name about “Wikifunctions”

Wikifunctions is just a English name ,I think it is necessary to give a Chinese name to it ,"维基方程" ,“维基函数","维基功能" , which is the best one？ Hong Kaile (talk) 03:07, 14 January 2024 (UTC)

I perfer “维基函数". 函数 is exactly what Wikifunctions is doing. 方程 is a different concept. 功能 seems a bit far off and needs disambiguation. 94rain (talk) 03:13, 14 January 2024 (UTC)
In fact a bunch of people prefer Wikifunctions as-is. MilkyDefer 04:44, 22 January 2024 (UTC)

Easier language selection / translation adding

The main thing I and many others on Wikifunctions do is the adding of a translation of a certain text in my local language. Things that can use some improvement:

  • Finding where to translate the label/description/alias of the function itself is easy. I click on Icon # languages to see what text has been provided for the languages (as English can be ambiguous). Then I click Add language and the Edit information dialogue appears. Then I have to add my language manually, why? Why is it prefilled if I click on the Pen icon pen icon it is prefilled with my language and a lot less work, but with the Edit information dialogue it creates a lot of work. (And if there is a reason for it, then provide a click selection option, instead of that I type the language code, slow appearing of the language list, select in long list of languages the language the right one.) This sounds maybe a minor thing, but with providing 100(+) translations, this starts to get annoying and because of the amount of times it becomes a major thing.
  • When ready to publish another dialogue appears with the question How did you improve this page? In other projects, like Wikipedia, if I click in this field, I get an overview of earlier used edit summaries which I can choose, but here it doesn't. Or the last used summary is already suggested in the field so I don't have to type over en over the same thing again and again. Again this sounds maybe minor, but when providing 100(+) translations this is tedious.
  • The left box is intended for providing translations, but apparently only some of the translations. If you want to translate the label(s) of certain fields, this is not possible via the left section, but you need to modify the whole page. As many users do not realize there is a translatable label of certain fields, this translation is often forgotten. This works counterproductive. Also the previous two issues above are here a problem too!
  • In multiple functions I have provided the translation for "input" as well as for "number" (etc). Seems to me that this could and should not be provided in each function but be centralised.
  • When multiple translations have been provided, the provided languages are listed in order of creation. If I want to modify it for my language, I have to search to a long list of sections before I can find mine. This is not logic. A more compact overview makes working with it a lot easier, compare for example with Wikidata.

This all creates a lot of extra work and costs extra time. Time that can be spend only once. Romaine (talk) 11:30, 20 January 2024 (UTC)

I think it would be great if it will be easier to translate languages. I have seen many Z-Objects about Languages with only a low number of translations of the language name into other languages. 10 days ago I tried to extract out of Wikidata all Labels for Languages. Maybe it is possible to solve it with a user script what adds the language name in the field after clicking on adding new language until it is implemented in the software itself. Hogü-456 (talk) 21:13, 24 January 2024 (UTC)

Note about MediaWiki:Sidebar

We don't have many projects using Extension:Translate, as the structure of Wikimedia projects is based on one website per language. As a French speaker, I currently have English and French links in the sidebar because some pages aren't translated (and shouldn't be?) like the Wikifunctions:Status title page or Wikifunctions:Project chat. Should we do something about this? Lofhi (talk) 04:36, 6 January 2024 (UTC)

The labels in the sidebar can be localized like here: MediaWiki:Villagepump/de but since it's in MediaWiki namespace, it requires admin or interface admin rights (I'm not sure if it's possible to use Extension:Translate there). Msz2001 (talk) 09:26, 6 January 2024 (UTC)
It is possible to use the translate extension on MediaWiki pages (we are doing that on Wikidata), but I am not a fan of it because we allow all users to edit the interface and circumvent the security mechanism. Just let me know what the translation into French is and I will create the subpages. --Ameisenigel (talk) 09:30, 6 January 2024 (UTC)
Given the ocassion I'll suggest Polish translations too:
Msz2001 (talk) 12:32, 6 January 2024 (UTC)
Here you go:
Lofhi (talk) 12:58, 6 January 2024 (UTC)
All Done --Ameisenigel (talk) 16:55, 6 January 2024 (UTC)
For Dutch:
Thanks! Romaine (talk) 15:15, 9 January 2024 (UTC)
Done --Ameisenigel (talk) 20:05, 10 January 2024 (UTC)
@Ameisenigel, For Bengali:
Thanks. আফতাবুজ্জামান (talk) 18:34, 12 January 2024 (UTC)
Done --Ameisenigel (talk) 18:47, 12 January 2024 (UTC)
I don't think interface admins should be manually adding translations. It's almost impossible for anyone to discover how to add translations for things that way. Messages on Wikidata which use/used that method are/were rarely translated into more than a few languages, even years later. Messages like that should be made translatable on Translatewiki instead (like we do for Wikidata's sidebar), I've made phab:T354608 for the sidebar here and I would suggest making tickets for any other things which aren't translatable. - Nikki (talk) 10:56, 9 January 2024 (UTC)
On some other wikis there is a page to request the change of system messages. I think such would be helpful to centralize the requests.
Another option is to have a page where translations can be requested. Romaine (talk) 08:21, 20 January 2024 (UTC)
This will make it more convienient for localisation/translation.
See https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/WikimediaMessages/+/49d5159/i18n/wikimedia/en.json . -- Winston Sung (talk) 17:08, 4 February 2024 (UTC)

What about naming convention?

I sense great inspiration possible for a long, pointless and endless battle over naming rules. For example, I have a preference for putting everything in lowercase for functions, but I do put a first capital for implementations and tests. Who'd like to fight me? Lofhi (talk) 04:59, 6 January 2024 (UTC)

For languages like French, it's also a question of using the imperative or infinitive. A great war! Lofhi (talk) 05:01, 6 January 2024 (UTC)
With the Z+ template usages, it seems that putting everything in lowercase is the simplest. Lofhi (talk) 05:20, 6 January 2024 (UTC)
See WF:Naming conventions. These are language-invariant at the moment so they do not tell what verb forms to use etc. but provide some outline on the topic. Msz2001 (talk) 09:22, 6 January 2024 (UTC)
Hot take: the names of functions that output Booleans should end in question marks, like in w:en:NetLogo. Arlo Barnes (talk) 21:26, 5 February 2024 (UTC)

Will functions which requires calling a function taken as a parameter will be supported ?

I wanted to implement a function "check fixpoint" in math, which would take a function f and a value v and would return true if the value is a fixpoint of the function : 

(f, v) -> f(f(v)) == v

but it’s impossible right now to implement the call "f(v)", if I got things right. If it not going to be possible the function object string is fixpoint of function (Z12875) should be deleted, but I noticed another object, compose (Z10111) that would require it so maybe it’s not a deadend ? TomT0m (talk) 16:36, 24 January 2024 (UTC)

I believe we also require this to implement right fold (Z12753) and left fold (Z12781). But I am hopeful, because there are inbuilt functions that can do this: Map Function (Z873) and Filter Function (Z872). --99of9 (talk) 10:48, 4 February 2024 (UTC)
Oh nice, I missed those functions existed, they are important indeed. this might be "abused" to implement a function call anyway.
   apply(func, value) = first(map(func, [value]))
The function has even a name, it’s the return (aka unit) function of the "List Monad" (on enwiki)
   value -> [value]
TomT0m (talk) 11:25, 5 February 2024 (UTC)
I tried, got an attempt of implementation first element
(Map Function(Argument reference(function), prepend element to list(value, Typed list(Object))))
But this does not type check. I don’t know why ? The function object :  apply (Z13036) TomT0m (talk) 12:27, 5 February 2024 (UTC)
@TomT0m: I followed your recipe and it worked for me: apply (Z13036): a function that applies another (single argument) function to a value. --99of9 (talk) 22:11, 5 February 2024 (UTC)
Nice, thanks. I try to understand what I did wrong, and it seem the difference to you approach and mine is that you used a function to create the [value] list by prepending the value to the empty list, while I tried to just create a list by adding directly value as first element to the list type. TomT0m (talk) 09:00, 6 February 2024 (UTC)

I tried to use the new "apply" function to implement the string is fixpoint of function (Z12875) function (string is fixpoint(function, value)), but still no luck. I tried this implementation (copy pasted from the compact representation, after removing the unconvenient line jumps) : 

 string equality(apply(Argument reference(function), apply(Argument reference(function),  Argument reference( value ))), Argument reference(value))

But I get an error trying to save it (something like "malformed key / value", the error message had no Zid). I feel like I did something wrong, like this would need an argument dereference, but I’m confused. TomT0m (talk) 12:25, 6 February 2024 (UTC)

I think I got it working string is fixpoint, composition (Z13058). Yours had an unnecessary composition. You just needed to apply the function once and test if the result was equal to the input. --99of9 (talk) 23:03, 6 February 2024 (UTC)
Yes of course, I was not thinking clearly … I think Wikifunctions in is current state is still a bit of a maze to me, I get lost into details and forget where I want to go in the end :) TomT0m (talk) 10:34, 7 February 2024 (UTC)
@TomT0m: stick with it. I think you're actually pushing boundaries with functions of functions. Sometimes it just takes tinkering, other times it takes practice. I'm certainly learning from your ideas. --99of9 (talk) 00:27, 8 February 2024 (UTC)

@TomT0m:, User:GrounderUK pointed me to another inbuilt list function, Reduce Function (Z876), which allowed me to write apply two-argument function (Z13318), which in turn should enable a bunch of new types of list operation (e.g. general sort). --99of9 (talk) 23:30, 19 February 2024 (UTC)

@99of9 Pretty cool. To understand the implementation, does that mean that function values supports partial application (currying (Q1144925)) and that you used that trick to pass a list of arguments to that function ?
This could be generalized to any function arity. During the reduce, a sequence of partial application of the function is built, until all the element are set ?
 Reduce Function(Argument reference("function to apply") , Typed list
    ( Object , Argument reference("second argument")),  
    Argument reference("first argument"))
I guess we could create a generalized "apply" that takes a function with any number of arguments and its arguments as a list, that would just be a wrapper to "reduce" essentially. TomT0m (talk) 20:26, 20 February 2024 (UTC)
I don't think that's what I did, but I could be wrong. I just moved the first argument into the accumulator parameter of the reduce function, and the second argument into a one-element list to reduce. I haven't thought yet about whether the general apply is now possible. Feel free to try! --99of9 (talk) 23:31, 20 February 2024 (UTC)
Yes, I’m being silly, "reduce" could be implemented as (sketch), for the non empty case
  reduce(list, func, acc) = reduce(rest(list), func, func(first(list), acc))
  (and just "= acc" in the case list is empty)
there is only one element in the list so there is no actual recursive call, "acc" is initialised to the first argument and "func" is just called once with the first argument (as acc) and the second argument (as the only element in the list). No partial call involved in that case. This works only because "func" is a binary function and this is a hack to call it somehow.
(The approach I suggested might work if "apply" could do partial call with something like 
     reduce( 
          remove_first(list_of_parameter), 
          (partial_call, parameter) -> apply (partial_call, parameter)), 
          apply (func, first(list_of_parameter)) 
     )
after some thought) TomT0m (talk) 13:18, 21 February 2024 (UTC)

Just a note: it is cool that y'all are trying this out, but we don't regard Functions as argument or return types to be fully supported yet, and you might stumble into issues. We'll eventually get to that, but we are not there yet!

Having said that, I would prefer for experiments like these to be happening on the Beta, but hey, it's your project!

Again, it is super cool that you are trying these things out and pushing boundaries. --DVrandecic (WMF) (talk) 00:10, 1 March 2024 (UTC)

Sorry to unnerve you on the production server. I've added about not being fully supported yet at Wikifunctions:Catalogue#Functional_operations. Personally I've never been able to get into the beta sites because they feel to me like ghost cities, lacking a vibrant regular community. (Even the main WF is a little at risk of this to date.) But I'm also totally happy to stumble my way into issues, in fact the whole of WF still feels a bit experimental to me, but that's part of the fun of it. If it helps to know, the functions listed on the catalogue all seem to work pretty much as expected. I hadn't even thought of functions as return types... so maybe now you'll get me thinking about even more boundaries to push! --99of9 (talk) 02:07, 1 March 2024 (UTC)
You can already select functions as returned type tried this a few times :) Was stuck there because of course it’s not supported yet and there is no way to create a raw "function value" as a return value yet. There is way to create a "local function" in composition but no way to reference the parameters of the outer function yet (last time I tried) so indeed the support is limited.
@DVrandecic (WMF) Yes, I know the experiments should be held on beta, tried a few times but like 99of9 it seemed less vibrant and there is less functions implemented there, it’s a bit demotivating to start over. Anyway I more or less stopped and I don’t think that for myself I’ll continue the experiments on functions values while they are not officially supported. It’s an important tool for composition implementations of course, doing functional programming without them is harder :)
Anyway on the journey I got a question about builtin functions like "reduce" : I got to a point where it was important for some reason to know whether it’s supposed to be a left fold of a right fold, and what would happen if you applied a function to perform the reduce that in non commutative, and there were no way to know the assumptions on the "builtin" reduce right now on the function page. Will this be documented somehow ? TomT0m (talk) 15:48, 1 March 2024 (UTC)
Does this test answer your question? order of pairing (((0,1),2),3) (Z13427) --99of9 (talk) 23:55, 1 March 2024 (UTC)
Yes indeed it does, I did not realize the builtin was actually just an implementation and the function was actually a regular ZObject, and that you might add non-builtin implementations and test on it.
That settles the question I had on the apply list of functions (Z13351) function, apply the composite of a list of functions to a value. The implementation was supposed to be "reduce(list_of _function, apply, value)", but of course "apply(function, value)" works but "apply(value, function)" cannot (in general, it would work if "value" is a function that has a function parameter).
To make this work I then would have to create a "apply reverse" function : "applyreverse(value, function) = apply (function, value)". I suspected this was necessary but at this point it seemed really experimental and hacky that spread out everywhere. Moving the experiment to beta would have meant to rewrite everything, I found no motivation. TomT0m (talk) 11:37, 2 March 2024 (UTC)

Is there an inbuilt function to test for the equality of objects?

As per the title. I think I need this to make a composition implementation for contains (Z12696). It would also help to have a list of inbuilt functions somewhere. --99of9 (talk) 03:33, 12 January 2024 (UTC)

There are Built-in implementation of Equals for Strings (Z966) and Built-in implementation for List equality (Z989) for built-in equality and I think that's all. Lofhi (talk) 14:11, 12 January 2024 (UTC)
There is also Boolean equality (Z844). But I need one for "object type". Perhaps these could all be used in combination if there was a function to return what type an object is. --99of9 (talk) 09:48, 13 January 2024 (UTC)
I've started one here: object equality (Z13052), I think it can be done using list equality. --99of9 (talk) 01:17, 6 February 2024 (UTC)
There is no such function, and I am not sure there should be such a function. The thing is that for some types, equality is actually really difficult to establish -- think for example about the function type. So, assume we had a function or currying: should object equality(curry(Ceaser's cipher, 26), echo string) return true? Well, it should, but I don't expect us to have a function that can say that, and more certainly not to have a single function that can do that for all types.
Having said that, we are currently introducing a new key on types for equality. One thing object equality could do is to check whether there is a value on that key, and if so, call that function. That's nothing that is currently supported, and it might be worthwhile to try it out on the Beta first.
Also, it is unclear to me how it should deal with the situation when there is no such equality function. --DVrandecic (WMF) (talk) 00:06, 1 March 2024 (UTC)
Although there will be edge-cases (like function equality), I think these are outweighed by the need for functions like contains (Z12696) (and I think I've had to use it for a few result validator functions). With current functionality we would have to write a different version of this for each type, which would be confusing and wasteful (and anyway wouldn't deal with lists of mixed types). The new key sounds like a good plan to me. I suggest that when the key is not present, we just return "not equal". I have no problem with the function returning (ROT26 != echo), as long as it gets right everything that *does* have a clearly defined equality (although maybe I'd also like it to return true for echo==echo). If we write this into the specifications and tests, then all should be clear.--99of9 (talk) 00:45, 1 March 2024 (UTC)
Ha! Yes… I like to think that Objects that have identical canonical forms are “equal”, whereas different representations of the same “thing” are simply “equivalent”. We should probably have a built-in Canonical(ize) function to return a String (not an object) and use string equality (Z866) on the resultant strings for true “Object equality”. This is nicely consistent with the proposal for the Natural number type, I think. GrounderUK (talk) 10:12, 1 March 2024 (UTC)
The implemented object equality (Z13052) function tests equality of Python objects. It seems to be necessary as the element equality function in Built-in implementation for List equality (Z989) for comparing untyped lists. Presumably, if we get signed integers we shall have a problem when comparing a non-negative integer with a Natural number with the same value. The function will either say they are == objects (in Python) or it won’t, and either might be considered incorrect. GrounderUK (talk) 19:32, 15 March 2024 (UTC)
my intent for that function is that if would ideally check types too, so if there is a way to do that, please feel free to add it. However, there are also some views at phab:T294371 that the function is not necessary.--99of9 (talk) 22:59, 15 March 2024 (UTC)
Well, not all “object equality” functions are equal!
Your function is useful for comparing values where the type is uncertain, either an element in an untyped list or the result of a function that delivers a Z1/object. I use the term “values” loosely, because values in Wikifunctions and Python are objects. And that is why it works (for the time being).
But, as we saw with contains (Z12696), new types can cause failures in previously successful functions. I tried, but I couldn’t persuade Python that a Natural number of a given value was == the same value in a list. I’ll check again over the weekend but I think it’s because the number outside the list is an integer (object) whilst the one in the list is a Wikifunctions object. There should be a ticket for that. phab:T360247
Anyway, back to types. The Python test is quite a bit more complicated than it looks and I don’t pretend to understand it myself but for your basic types, it ensures that they are objects of the same type, as you intend. But if different types in Wikifunctions are transformed into the same type in Python, it will tell you they are == (as I expect to happen when we get integers and compare them to Natural numbers). I think you want to say they are not equal objects, so you would have to do your type equality test in Wikifunctions before you do the value (object) equality test in Python. That’s a simple composition with the “type-of(Object)” function that does not currently exist even on beta. GrounderUK (talk) 00:32, 16 March 2024 (UTC)
Ok, that makes a lot of sense, thanks. --99of9 (talk) 00:24, 17 March 2024 (UTC)
Retrieved from "https://www.wikifunctions.org/w/index.php?title=Wikifunctions:Project_chat/Archive/2024/01&oldid=99452"