This is a rather technical question. If you are not interested in the inner working of the function model, feel free to safely skip this one.
Currently, a function call is represented as follows (assume, Z142 is the concatenation function): Z1K1: Z7 Z7K1: Z144 Z144K1: "Wiki" Z144K2: "data"
If we use global keys, it would look like this: Z1K1: Z7 Z7K1: Z144 K1: "Wiki" K2: "data"
The local keys in this case get expanded against the Z7K1 value, not the Z1K1 value, as is the case for all other local keys. This makes it very different than all the other objects, and requires special handling.
The suggestion is to change the representation of function calls and make them more unified compared to the other entries, i.e. like this:
Z1K1: Z7 Z7K1: Z1K1: Z144 Z144K1: "Wiki" Z144K2: "data"
So, instead of pulling the values into the Z7 object, we basically instantiate a function just like any other type, and wrap it into a Z7 to say that this is a function call. This needs one extra object, but it leads to much more uniform handling of objects.
Any thoughts?
Cheers, Denny
Yeah a few...
Lists of things are prevalent throughout many languages, whether it be a list of things in sentences separated by a : colon, or , comma, or whatever unicode char springs to mind, or packed arrays (HTML <li> elements as a boring example), or Wikipedia formats (Bulleted lists, Numbered lists, etc.) Arity comes to mind for doing repeatable things in a straightforward way if we want. (Easier novice experience sometimes as well). Although a lambda function classically can take any number of arguments, but I'm thinking also about parameter arrays, not just a classic loop or iterator.
1. Would it help or hinder multi-arity functions if supported ? 2. Would it help or hinder variadic functions (functions with infinite arity) if supported ?
Clojure has a built-in apply function which allows you to ‘unpack’ a sequence and pass the unpacked values to a function as individual arguments. https://theburningmonk.com/2013/09/clojure-multi-arity-and-variadic-function...
Maybe this is already straightforward in the design already for the lambda compiler and the answer back to me is "we got you covered, Thad" ?
Thad https://www.linkedin.com/in/thadguidry/
On Wed, Oct 14, 2020 at 6:16 PM Denny Vrandečić dvrandecic@wikimedia.org wrote:
This is a rather technical question. If you are not interested in the inner working of the function model, feel free to safely skip this one.
Currently, a function call is represented as follows (assume, Z142 is the concatenation function): Z1K1: Z7 Z7K1: Z144 Z144K1: "Wiki" Z144K2: "data"
If we use global keys, it would look like this: Z1K1: Z7 Z7K1: Z144 K1: "Wiki" K2: "data"
The local keys in this case get expanded against the Z7K1 value, not the Z1K1 value, as is the case for all other local keys. This makes it very different than all the other objects, and requires special handling.
The suggestion is to change the representation of function calls and make them more unified compared to the other entries, i.e. like this:
Z1K1: Z7 Z7K1: Z1K1: Z144 Z144K1: "Wiki" Z144K2: "data"
So, instead of pulling the values into the Z7 object, we basically instantiate a function just like any other type, and wrap it into a Z7 to say that this is a function call. This needs one extra object, but it leads to much more uniform handling of objects.
Any thoughts?
Cheers, Denny _______________________________________________ Abstract-Wikipedia mailing list Abstract-Wikipedia@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/abstract-wikipedia
1. Regarding multi-arity functions, that's really a question of having defaults on the arguments, which, so far, we have avoided speccing out. It is probably really useful though.
2. Regarding variadic functions, the way that most languages implement these is to basically have an array of the arguments, either from the first argument on, or starting after the last named argument. Both of these patterns will definitely be supported, but we would explicitly say that there is an argument of type list instead of calling it variadic. In the end, the latter is just a bit of syntax over an argument of type list in a specific position.
But either should be doable with both the current handling of Z7 as well as the more uniform handling (or, in fact, the Z7-less handling Arthur is suggesting in his answer).
Thank you for your answer! Denny
On Wed, Oct 14, 2020 at 5:18 PM Thad Guidry thadguidry@gmail.com wrote:
Yeah a few...
Lists of things are prevalent throughout many languages, whether it be a list of things in sentences separated by a : colon, or , comma, or whatever unicode char springs to mind, or packed arrays (HTML <li> elements as a boring example), or Wikipedia formats (Bulleted lists, Numbered lists, etc.) Arity comes to mind for doing repeatable things in a straightforward way if we want. (Easier novice experience sometimes as well). Although a lambda function classically can take any number of arguments, but I'm thinking also about parameter arrays, not just a classic loop or iterator.
- Would it help or hinder multi-arity functions if supported ?
- Would it help or hinder variadic functions (functions with infinite
arity) if supported ?
Clojure has a built-in apply function which allows you to ‘unpack’ a sequence and pass the unpacked values to a function as individual arguments.
https://theburningmonk.com/2013/09/clojure-multi-arity-and-variadic-function...
Maybe this is already straightforward in the design already for the lambda compiler and the answer back to me is "we got you covered, Thad" ?
Thad https://www.linkedin.com/in/thadguidry/
On Wed, Oct 14, 2020 at 6:16 PM Denny Vrandečić dvrandecic@wikimedia.org wrote:
This is a rather technical question. If you are not interested in the inner working of the function model, feel free to safely skip this one.
Currently, a function call is represented as follows (assume, Z142 is the concatenation function): Z1K1: Z7 Z7K1: Z144 Z144K1: "Wiki" Z144K2: "data"
If we use global keys, it would look like this: Z1K1: Z7 Z7K1: Z144 K1: "Wiki" K2: "data"
The local keys in this case get expanded against the Z7K1 value, not the Z1K1 value, as is the case for all other local keys. This makes it very different than all the other objects, and requires special handling.
The suggestion is to change the representation of function calls and make them more unified compared to the other entries, i.e. like this:
Z1K1: Z7 Z7K1: Z1K1: Z144 Z144K1: "Wiki" Z144K2: "data"
So, instead of pulling the values into the Z7 object, we basically instantiate a function just like any other type, and wrap it into a Z7 to say that this is a function call. This needs one extra object, but it leads to much more uniform handling of objects.
Any thoughts?
Cheers, Denny _______________________________________________ Abstract-Wikipedia mailing list Abstract-Wikipedia@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/abstract-wikipedia
Abstract-Wikipedia mailing list Abstract-Wikipedia@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/abstract-wikipedia
Sure Denny!
In that case, In the Z7-less handling case, if that lookup, as you say, is always fast, or instantaneous (are we compiling or is this dynamic in nature?), then there is no impact on performance? Maybe your worrying about some future need for applying Rules, Metadata, Attributes at a Function type level...and possibly losing that or degrading some performance because of a lookup versus pulling the values into Z7 object? (this seems to be the core of the question, by the way) Would|should Z7 ALWAYS unquote and evaluate? Are there useful times when a user or call would say not to, because it wouldn't need to?
Maybe we flip this around and instead hear your worry about losing the local Z7 key? I suspect you have some fear you haven't explained fully to us. Maybe you are thinking that at any given function call there might be a need to implicitly encapsulate some metadata, and so having the local Z7 key would be useful? Maybe you are going through a pre-optimization cycle before we get to the need for that? It would help if you told us those fears, so we could also think through it.
Thad https://www.linkedin.com/in/thadguidry/
On Thu, Oct 15, 2020 at 6:17 PM Denny Vrandečić vrandecic@gmail.com wrote:
- Regarding multi-arity functions, that's really a question of having
defaults on the arguments, which, so far, we have avoided speccing out. It is probably really useful though.
- Regarding variadic functions, the way that most languages implement
these is to basically have an array of the arguments, either from the first argument on, or starting after the last named argument. Both of these patterns will definitely be supported, but we would explicitly say that there is an argument of type list instead of calling it variadic. In the end, the latter is just a bit of syntax over an argument of type list in a specific position.
But either should be doable with both the current handling of Z7 as well as the more uniform handling (or, in fact, the Z7-less handling Arthur is suggesting in his answer).
Thank you for your answer! Denny
On Wed, Oct 14, 2020 at 5:18 PM Thad Guidry thadguidry@gmail.com wrote:
Yeah a few...
Lists of things are prevalent throughout many languages, whether it be a list of things in sentences separated by a : colon, or , comma, or whatever unicode char springs to mind, or packed arrays (HTML <li> elements as a boring example), or Wikipedia formats (Bulleted lists, Numbered lists, etc.) Arity comes to mind for doing repeatable things in a straightforward way if we want. (Easier novice experience sometimes as well). Although a lambda function classically can take any number of arguments, but I'm thinking also about parameter arrays, not just a classic loop or iterator.
- Would it help or hinder multi-arity functions if supported ?
- Would it help or hinder variadic functions (functions with infinite
arity) if supported ?
Clojure has a built-in apply function which allows you to ‘unpack’ a sequence and pass the unpacked values to a function as individual arguments.
https://theburningmonk.com/2013/09/clojure-multi-arity-and-variadic-function...
Maybe this is already straightforward in the design already for the lambda compiler and the answer back to me is "we got you covered, Thad" ?
Thad https://www.linkedin.com/in/thadguidry/
On Wed, Oct 14, 2020 at 6:16 PM Denny Vrandečić dvrandecic@wikimedia.org wrote:
This is a rather technical question. If you are not interested in the inner working of the function model, feel free to safely skip this one.
Currently, a function call is represented as follows (assume, Z142 is the concatenation function): Z1K1: Z7 Z7K1: Z144 Z144K1: "Wiki" Z144K2: "data"
If we use global keys, it would look like this: Z1K1: Z7 Z7K1: Z144 K1: "Wiki" K2: "data"
The local keys in this case get expanded against the Z7K1 value, not the Z1K1 value, as is the case for all other local keys. This makes it very different than all the other objects, and requires special handling.
The suggestion is to change the representation of function calls and make them more unified compared to the other entries, i.e. like this:
Z1K1: Z7 Z7K1: Z1K1: Z144 Z144K1: "Wiki" Z144K2: "data"
So, instead of pulling the values into the Z7 object, we basically instantiate a function just like any other type, and wrap it into a Z7 to say that this is a function call. This needs one extra object, but it leads to much more uniform handling of objects.
Any thoughts?
Cheers, Denny _______________________________________________ Abstract-Wikipedia mailing list Abstract-Wikipedia@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/abstract-wikipedia
Abstract-Wikipedia mailing list Abstract-Wikipedia@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/abstract-wikipedia
Abstract-Wikipedia mailing list Abstract-Wikipedia@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/abstract-wikipedia
Good question Thad about what's the downside of losing the local Z7 key and to what degree this may or may not impact compilation or hot code paths? Denny?
No strong opinions here, this may be similar to what others are getting at, or it's possible I misunderstand...
If we keep Z1K1: Z7, do we want Z7K1: <function ZID> and Z7K2: {TYPED_PARAMETERS_OR_GENERATOR_OF_THEM}? It's all the same in a way as legal parameters still need to be verified against their expected types, but it feels a little more symmetric. I'm not totally sure of the knock-on effects, but it may be useful to think about how IDEs would insert blocks, readability of nested functions for the brave ones who read this stuff, and whether there are novel ways to split things out for execution or symbol lookup.
On Thu, Oct 15, 2020 at 7:42 PM Thad Guidry thadguidry@gmail.com wrote:
Sure Denny!
In that case, In the Z7-less handling case, if that lookup, as you say, is always fast, or instantaneous (are we compiling or is this dynamic in nature?), then there is no impact on performance? Maybe your worrying about some future need for applying Rules, Metadata, Attributes at a Function type level...and possibly losing that or degrading some performance because of a lookup versus pulling the values into Z7 object? (this seems to be the core of the question, by the way) Would|should Z7 ALWAYS unquote and evaluate? Are there useful times when a user or call would say not to, because it wouldn't need to?
Maybe we flip this around and instead hear your worry about losing the local Z7 key? I suspect you have some fear you haven't explained fully to us. Maybe you are thinking that at any given function call there might be a need to implicitly encapsulate some metadata, and so having the local Z7 key would be useful? Maybe you are going through a pre-optimization cycle before we get to the need for that? It would help if you told us those fears, so we could also think through it.
Thad https://www.linkedin.com/in/thadguidry/
On Thu, Oct 15, 2020 at 6:17 PM Denny Vrandečić vrandecic@gmail.com wrote:
- Regarding multi-arity functions, that's really a question of having
defaults on the arguments, which, so far, we have avoided speccing out. It is probably really useful though.
- Regarding variadic functions, the way that most languages implement
these is to basically have an array of the arguments, either from the first argument on, or starting after the last named argument. Both of these patterns will definitely be supported, but we would explicitly say that there is an argument of type list instead of calling it variadic. In the end, the latter is just a bit of syntax over an argument of type list in a specific position.
But either should be doable with both the current handling of Z7 as well as the more uniform handling (or, in fact, the Z7-less handling Arthur is suggesting in his answer).
Thank you for your answer! Denny
On Wed, Oct 14, 2020 at 5:18 PM Thad Guidry thadguidry@gmail.com wrote:
Yeah a few...
Lists of things are prevalent throughout many languages, whether it be a list of things in sentences separated by a : colon, or , comma, or whatever unicode char springs to mind, or packed arrays (HTML <li> elements as a boring example), or Wikipedia formats (Bulleted lists, Numbered lists, etc.) Arity comes to mind for doing repeatable things in a straightforward way if we want. (Easier novice experience sometimes as well). Although a lambda function classically can take any number of arguments, but I'm thinking also about parameter arrays, not just a classic loop or iterator.
- Would it help or hinder multi-arity functions if supported ?
- Would it help or hinder variadic functions (functions with infinite
arity) if supported ?
Clojure has a built-in apply function which allows you to ‘unpack’ a sequence and pass the unpacked values to a function as individual arguments.
https://theburningmonk.com/2013/09/clojure-multi-arity-and-variadic-function...
Maybe this is already straightforward in the design already for the lambda compiler and the answer back to me is "we got you covered, Thad" ?
Thad https://www.linkedin.com/in/thadguidry/
On Wed, Oct 14, 2020 at 6:16 PM Denny Vrandečić < dvrandecic@wikimedia.org> wrote:
This is a rather technical question. If you are not interested in the inner working of the function model, feel free to safely skip this one.
Currently, a function call is represented as follows (assume, Z142 is the concatenation function): Z1K1: Z7 Z7K1: Z144 Z144K1: "Wiki" Z144K2: "data"
If we use global keys, it would look like this: Z1K1: Z7 Z7K1: Z144 K1: "Wiki" K2: "data"
The local keys in this case get expanded against the Z7K1 value, not the Z1K1 value, as is the case for all other local keys. This makes it very different than all the other objects, and requires special handling.
The suggestion is to change the representation of function calls and make them more unified compared to the other entries, i.e. like this:
Z1K1: Z7 Z7K1: Z1K1: Z144 Z144K1: "Wiki" Z144K2: "data"
So, instead of pulling the values into the Z7 object, we basically instantiate a function just like any other type, and wrap it into a Z7 to say that this is a function call. This needs one extra object, but it leads to much more uniform handling of objects.
Any thoughts?
Cheers, Denny _______________________________________________ Abstract-Wikipedia mailing list Abstract-Wikipedia@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/abstract-wikipedia
Abstract-Wikipedia mailing list Abstract-Wikipedia@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/abstract-wikipedia
Abstract-Wikipedia mailing list Abstract-Wikipedia@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/abstract-wikipedia
Abstract-Wikipedia mailing list Abstract-Wikipedia@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/abstract-wikipedia
Yes, that's also an option - Z7K1 for the function ZID and Z7K2 for the arguments as a (list of arguments)? did I get this right?
But then we would need to make the mapping from the list of arguments to the argument keys somehow magical, whereas when we use a single object under Z7K1 it could have these explicitly use the global argument keys.
Or did I misunderstand? Basically, my understanding of your proposal is
Z1K1: Z7 Z7K1: Z142 Z7K2: [ "Wiki", "data" ]
Or did I get that wrong?
On Fri, Oct 16, 2020 at 2:28 PM Adam Baso abaso@wikimedia.org wrote:
Good question Thad about what's the downside of losing the local Z7 key and to what degree this may or may not impact compilation or hot code paths? Denny?
No strong opinions here, this may be similar to what others are getting at, or it's possible I misunderstand...
If we keep Z1K1: Z7, do we want Z7K1: <function ZID> and Z7K2: {TYPED_PARAMETERS_OR_GENERATOR_OF_THEM}? It's all the same in a way as legal parameters still need to be verified against their expected types, but it feels a little more symmetric. I'm not totally sure of the knock-on effects, but it may be useful to think about how IDEs would insert blocks, readability of nested functions for the brave ones who read this stuff, and whether there are novel ways to split things out for execution or symbol lookup.
On Thu, Oct 15, 2020 at 7:42 PM Thad Guidry thadguidry@gmail.com wrote:
Sure Denny!
In that case, In the Z7-less handling case, if that lookup, as you say, is always fast, or instantaneous (are we compiling or is this dynamic in nature?), then there is no impact on performance? Maybe your worrying about some future need for applying Rules, Metadata, Attributes at a Function type level...and possibly losing that or degrading some performance because of a lookup versus pulling the values into Z7 object? (this seems to be the core of the question, by the way) Would|should Z7 ALWAYS unquote and evaluate? Are there useful times when a user or call would say not to, because it wouldn't need to?
Maybe we flip this around and instead hear your worry about losing the local Z7 key? I suspect you have some fear you haven't explained fully to us. Maybe you are thinking that at any given function call there might be a need to implicitly encapsulate some metadata, and so having the local Z7 key would be useful? Maybe you are going through a pre-optimization cycle before we get to the need for that? It would help if you told us those fears, so we could also think through it.
Thad https://www.linkedin.com/in/thadguidry/
On Thu, Oct 15, 2020 at 6:17 PM Denny Vrandečić vrandecic@gmail.com wrote:
- Regarding multi-arity functions, that's really a question of having
defaults on the arguments, which, so far, we have avoided speccing out. It is probably really useful though.
- Regarding variadic functions, the way that most languages implement
these is to basically have an array of the arguments, either from the first argument on, or starting after the last named argument. Both of these patterns will definitely be supported, but we would explicitly say that there is an argument of type list instead of calling it variadic. In the end, the latter is just a bit of syntax over an argument of type list in a specific position.
But either should be doable with both the current handling of Z7 as well as the more uniform handling (or, in fact, the Z7-less handling Arthur is suggesting in his answer).
Thank you for your answer! Denny
On Wed, Oct 14, 2020 at 5:18 PM Thad Guidry thadguidry@gmail.com wrote:
Yeah a few...
Lists of things are prevalent throughout many languages, whether it be a list of things in sentences separated by a : colon, or , comma, or whatever unicode char springs to mind, or packed arrays (HTML <li> elements as a boring example), or Wikipedia formats (Bulleted lists, Numbered lists, etc.) Arity comes to mind for doing repeatable things in a straightforward way if we want. (Easier novice experience sometimes as well). Although a lambda function classically can take any number of arguments, but I'm thinking also about parameter arrays, not just a classic loop or iterator.
- Would it help or hinder multi-arity functions if supported ?
- Would it help or hinder variadic functions (functions with infinite
arity) if supported ?
Clojure has a built-in apply function which allows you to ‘unpack’ a sequence and pass the unpacked values to a function as individual arguments.
https://theburningmonk.com/2013/09/clojure-multi-arity-and-variadic-function...
Maybe this is already straightforward in the design already for the lambda compiler and the answer back to me is "we got you covered, Thad" ?
Thad https://www.linkedin.com/in/thadguidry/
On Wed, Oct 14, 2020 at 6:16 PM Denny Vrandečić < dvrandecic@wikimedia.org> wrote:
This is a rather technical question. If you are not interested in the inner working of the function model, feel free to safely skip this one.
Currently, a function call is represented as follows (assume, Z142 is the concatenation function): Z1K1: Z7 Z7K1: Z144 Z144K1: "Wiki" Z144K2: "data"
If we use global keys, it would look like this: Z1K1: Z7 Z7K1: Z144 K1: "Wiki" K2: "data"
The local keys in this case get expanded against the Z7K1 value, not the Z1K1 value, as is the case for all other local keys. This makes it very different than all the other objects, and requires special handling.
The suggestion is to change the representation of function calls and make them more unified compared to the other entries, i.e. like this:
Z1K1: Z7 Z7K1: Z1K1: Z144 Z144K1: "Wiki" Z144K2: "data"
So, instead of pulling the values into the Z7 object, we basically instantiate a function just like any other type, and wrap it into a Z7 to say that this is a function call. This needs one extra object, but it leads to much more uniform handling of objects.
Any thoughts?
Cheers, Denny _______________________________________________ Abstract-Wikipedia mailing list Abstract-Wikipedia@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/abstract-wikipedia
Abstract-Wikipedia mailing list Abstract-Wikipedia@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/abstract-wikipedia
Abstract-Wikipedia mailing list Abstract-Wikipedia@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/abstract-wikipedia
Abstract-Wikipedia mailing list Abstract-Wikipedia@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/abstract-wikipedia
Abstract-Wikipedia mailing list Abstract-Wikipedia@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/abstract-wikipedia
Hi Denny - this is interesting, but perhaps it means we don't even need the Z7 type at all? That is, just go with:
Z1K1: Z142 Z142K1: "Wiki" Z142K2: "data"
So every instance of Z8 (function type) is itself a type whose instances are function calls? I'm wondering how either approach would allow for currying though... I guess that gets into function implementations? But at some level you'd want a function call that allowed for combining both Z142 keys and the key of the curried function. So there may still be a need for several different key prefixes within the same ZObject?
Arthur
On Wed, Oct 14, 2020 at 7:16 PM Denny Vrandečić dvrandecic@wikimedia.org wrote:
This is a rather technical question. If you are not interested in the inner working of the function model, feel free to safely skip this one.
Currently, a function call is represented as follows (assume, Z142 is the concatenation function): Z1K1: Z7 Z7K1: Z144 Z144K1: "Wiki" Z144K2: "data"
If we use global keys, it would look like this: Z1K1: Z7 Z7K1: Z144 K1: "Wiki" K2: "data"
The local keys in this case get expanded against the Z7K1 value, not the Z1K1 value, as is the case for all other local keys. This makes it very different than all the other objects, and requires special handling.
The suggestion is to change the representation of function calls and make them more unified compared to the other entries, i.e. like this:
Z1K1: Z7 Z7K1: Z1K1: Z144 Z144K1: "Wiki" Z144K2: "data"
So, instead of pulling the values into the Z7 object, we basically instantiate a function just like any other type, and wrap it into a Z7 to say that this is a function call. This needs one extra object, but it leads to much more uniform handling of objects.
Any thoughts?
Cheers, Denny _______________________________________________ Abstract-Wikipedia mailing list Abstract-Wikipedia@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/abstract-wikipedia
So just thinking out loud.
I was thinking about that too - do we even need the Z7?
The advantage of having an explicit Z7 is that we know immediately that this is an object that needs to be treated specially. On the other side, that seems to be only one removed - we just need to look up the type of Z142, and if it is Function, well, there we are!
The other advantage of using an explicit Z7 is that we could use a Z142 without a Z7 embedding it like a quote in lisp. The Z7 unquotes and evaluates it.
So not sure if Z7 is needed. I would love to hear more thoughts. I have the sense that it would be really useful to keep the Z7, but I have trouble to say exactly why.
Regarding the Currying: that should not be a problem either way, though, if I understand right. So assume that we have a function curry Z78 and the concatenate function Z142.
Z1K1: Z1K1: Z7 Z7K1: Z1K1: Z78 Z78K1: Z142 Z78K2: "Wiki" K1: "data"
So here we use curry(concatenate, "Wiki"), which results in a function that takes a single string and prepends "Wiki" to it, so that would be read as curry(concatenate, "Wiki")("data")
Note that the K1 would need to be a local key as there is no global key that could be used, as the function is being created on the fly.
But please correct me if I misunderstood your comment on currying.
Thanks so much for your thoughts!
On Thu, Oct 15, 2020 at 5:34 AM Arthur Smith arthurpsmith@gmail.com wrote:
Hi Denny - this is interesting, but perhaps it means we don't even need the Z7 type at all? That is, just go with:
Z1K1: Z142 Z142K1: "Wiki" Z142K2: "data"
So every instance of Z8 (function type) is itself a type whose instances are function calls? I'm wondering how either approach would allow for currying though... I guess that gets into function implementations? But at some level you'd want a function call that allowed for combining both Z142 keys and the key of the curried function. So there may still be a need for several different key prefixes within the same ZObject?
Arthur
On Wed, Oct 14, 2020 at 7:16 PM Denny Vrandečić dvrandecic@wikimedia.org wrote:
This is a rather technical question. If you are not interested in the inner working of the function model, feel free to safely skip this one.
Currently, a function call is represented as follows (assume, Z142 is the concatenation function): Z1K1: Z7 Z7K1: Z144 Z144K1: "Wiki" Z144K2: "data"
If we use global keys, it would look like this: Z1K1: Z7 Z7K1: Z144 K1: "Wiki" K2: "data"
The local keys in this case get expanded against the Z7K1 value, not the Z1K1 value, as is the case for all other local keys. This makes it very different than all the other objects, and requires special handling.
The suggestion is to change the representation of function calls and make them more unified compared to the other entries, i.e. like this:
Z1K1: Z7 Z7K1: Z1K1: Z144 Z144K1: "Wiki" Z144K2: "data"
So, instead of pulling the values into the Z7 object, we basically instantiate a function just like any other type, and wrap it into a Z7 to say that this is a function call. This needs one extra object, but it leads to much more uniform handling of objects.
Any thoughts?
Cheers, Denny _______________________________________________ Abstract-Wikipedia mailing list Abstract-Wikipedia@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/abstract-wikipedia
Abstract-Wikipedia mailing list Abstract-Wikipedia@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/abstract-wikipedia
In general, it seems better to use explicit typing (via a Z7 object to indicate something is a function call) vs. implicit typing (if Z1K1 is a function call, then this is a function call).
It might potentially lead to simpler error semantics. What if a typo / accidental keystroke changes "Z142" to "Z12" and Z12 were not a function? Then, suddenly the behavior of wherever this object was used would change mysteriously .. in some cases, it might error immediately (because of the context), and in other cases, it might fail downstream and in other cases, it may lead to incorrect output.
With an explicit Z7 type, there is no scope for such confusion and you get immediate failure (assuming validation is enabled) on typos / errors.
Subbu.
On 10/15/20 6:12 PM, Denny Vrandečić wrote:
So just thinking out loud.
I was thinking about that too - do we even need the Z7?
The advantage of having an explicit Z7 is that we know immediately that this is an object that needs to be treated specially. On the other side, that seems to be only one removed - we just need to look up the type of Z142, and if it is Function, well, there we are!
The other advantage of using an explicit Z7 is that we could use a Z142 without a Z7 embedding it like a quote in lisp. The Z7 unquotes and evaluates it.
So not sure if Z7 is needed. I would love to hear more thoughts. I have the sense that it would be really useful to keep the Z7, but I have trouble to say exactly why.
Regarding the Currying: that should not be a problem either way, though, if I understand right. So assume that we have a function curry Z78 and the concatenate function Z142.
Z1K1: Z1K1: Z7 Z7K1: Z1K1: Z78 Z78K1: Z142 Z78K2: "Wiki" K1: "data"
So here we use curry(concatenate, "Wiki"), which results in a function that takes a single string and prepends "Wiki" to it, so that would be read as curry(concatenate, "Wiki")("data")
Note that the K1 would need to be a local key as there is no global key that could be used, as the function is being created on the fly.
But please correct me if I misunderstood your comment on currying.
Thanks so much for your thoughts!
On Thu, Oct 15, 2020 at 5:34 AM Arthur Smith <arthurpsmith@gmail.com mailto:arthurpsmith@gmail.com> wrote:
Hi Denny - this is interesting, but perhaps it means we don't even need the Z7 type at all? That is, just go with: Z1K1: Z142 Z142K1: "Wiki" Z142K2: "data" So every instance of Z8 (function type) is itself a type whose instances are function calls? I'm wondering how either approach would allow for currying though... I guess that gets into function implementations? But at some level you'd want a function call that allowed for combining both Z142 keys and the key of the curried function. So there may still be a need for several different key prefixes within the same ZObject? Arthur On Wed, Oct 14, 2020 at 7:16 PM Denny Vrandečić <dvrandecic@wikimedia.org <mailto:dvrandecic@wikimedia.org>> wrote: This is a rather technical question. If you are not interested in the inner working of the function model, feel free to safely skip this one. Currently, a function call is represented as follows (assume, Z142 is the concatenation function): Z1K1: Z7 Z7K1: Z144 Z144K1: "Wiki" Z144K2: "data" If we use global keys, it would look like this: Z1K1: Z7 Z7K1: Z144 K1: "Wiki" K2: "data" The local keys in this case get expanded against the Z7K1 value, not the Z1K1 value, as is the case for all other local keys. This makes it very different than all the other objects, and requires special handling. The suggestion is to change the representation of function calls and make them more unified compared to the other entries, i.e. like this: Z1K1: Z7 Z7K1: Z1K1: Z144 Z144K1: "Wiki" Z144K2: "data" So, instead of pulling the values into the Z7 object, we basically instantiate a function just like any other type, and wrap it into a Z7 to say that this is a function call. This needs one extra object, but it leads to much more uniform handling of objects. Any thoughts? Cheers, Denny _______________________________________________ Abstract-Wikipedia mailing list Abstract-Wikipedia@lists.wikimedia.org <mailto:Abstract-Wikipedia@lists.wikimedia.org> https://lists.wikimedia.org/mailman/listinfo/abstract-wikipedia _______________________________________________ Abstract-Wikipedia mailing list Abstract-Wikipedia@lists.wikimedia.org <mailto:Abstract-Wikipedia@lists.wikimedia.org> https://lists.wikimedia.org/mailman/listinfo/abstract-wikipedia
Abstract-Wikipedia mailing list Abstract-Wikipedia@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/abstract-wikipedia
So I was wondering, can we list the contexts in which we anticipate function calls happening? There's the definition of another function - an implementation, where the arguments (values for the keys) are derived somehow from the arguments to the function being defined Or in running a test, we call a function with certain arguments and expect a certain result to compare to Or in an actual call context (API?) where an external user wants to use that function to generate a result
Are there other cases we can anticipate now? Maybe we could run through what the ZObjects would look like in each context and then see what's really needed there?
Arthur
On Sun, Oct 18, 2020 at 11:33 PM Subramanya Sastry ssastry@wikimedia.org wrote:
In general, it seems better to use explicit typing (via a Z7 object to indicate something is a function call) vs. implicit typing (if Z1K1 is a function call, then this is a function call).
It might potentially lead to simpler error semantics. What if a typo / accidental keystroke changes "Z142" to "Z12" and Z12 were not a function? Then, suddenly the behavior of wherever this object was used would change mysteriously .. in some cases, it might error immediately (because of the context), and in other cases, it might fail downstream and in other cases, it may lead to incorrect output.
With an explicit Z7 type, there is no scope for such confusion and you get immediate failure (assuming validation is enabled) on typos / errors.
Subbu. On 10/15/20 6:12 PM, Denny Vrandečić wrote:
So just thinking out loud.
I was thinking about that too - do we even need the Z7?
The advantage of having an explicit Z7 is that we know immediately that this is an object that needs to be treated specially. On the other side, that seems to be only one removed - we just need to look up the type of Z142, and if it is Function, well, there we are!
The other advantage of using an explicit Z7 is that we could use a Z142 without a Z7 embedding it like a quote in lisp. The Z7 unquotes and evaluates it.
So not sure if Z7 is needed. I would love to hear more thoughts. I have the sense that it would be really useful to keep the Z7, but I have trouble to say exactly why.
Regarding the Currying: that should not be a problem either way, though, if I understand right. So assume that we have a function curry Z78 and the concatenate function Z142.
Z1K1: Z1K1: Z7 Z7K1: Z1K1: Z78 Z78K1: Z142 Z78K2: "Wiki" K1: "data"
So here we use curry(concatenate, "Wiki"), which results in a function that takes a single string and prepends "Wiki" to it, so that would be read as curry(concatenate, "Wiki")("data")
Note that the K1 would need to be a local key as there is no global key that could be used, as the function is being created on the fly.
But please correct me if I misunderstood your comment on currying.
Thanks so much for your thoughts!
On Thu, Oct 15, 2020 at 5:34 AM Arthur Smith arthurpsmith@gmail.com wrote:
Hi Denny - this is interesting, but perhaps it means we don't even need the Z7 type at all? That is, just go with:
Z1K1: Z142 Z142K1: "Wiki" Z142K2: "data"
So every instance of Z8 (function type) is itself a type whose instances are function calls? I'm wondering how either approach would allow for currying though... I guess that gets into function implementations? But at some level you'd want a function call that allowed for combining both Z142 keys and the key of the curried function. So there may still be a need for several different key prefixes within the same ZObject?
Arthur
On Wed, Oct 14, 2020 at 7:16 PM Denny Vrandečić dvrandecic@wikimedia.org wrote:
This is a rather technical question. If you are not interested in the inner working of the function model, feel free to safely skip this one.
Currently, a function call is represented as follows (assume, Z142 is the concatenation function): Z1K1: Z7 Z7K1: Z144 Z144K1: "Wiki" Z144K2: "data"
If we use global keys, it would look like this: Z1K1: Z7 Z7K1: Z144 K1: "Wiki" K2: "data"
The local keys in this case get expanded against the Z7K1 value, not the Z1K1 value, as is the case for all other local keys. This makes it very different than all the other objects, and requires special handling.
The suggestion is to change the representation of function calls and make them more unified compared to the other entries, i.e. like this:
Z1K1: Z7 Z7K1: Z1K1: Z144 Z144K1: "Wiki" Z144K2: "data"
So, instead of pulling the values into the Z7 object, we basically instantiate a function just like any other type, and wrap it into a Z7 to say that this is a function call. This needs one extra object, but it leads to much more uniform handling of objects.
Any thoughts?
Cheers, Denny _______________________________________________ Abstract-Wikipedia mailing list Abstract-Wikipedia@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/abstract-wikipedia
Abstract-Wikipedia mailing list Abstract-Wikipedia@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/abstract-wikipedia
Abstract-Wikipedia mailing listAbstract-Wikipedia@lists.wikimedia.orghttps://lists.wikimedia.org/mailman/listinfo/abstract-wikipedia
Abstract-Wikipedia mailing list Abstract-Wikipedia@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/abstract-wikipedia
In principle, I would like Z7 to be able to appear almost everywhere. Particularly, they can be a function call to create a different content in some place. (That's something I would like to steal from lisp)
One example: I noticed that one problem with my proposal is that in
Z1K1: Z144
the problem is that Z144 is actually a Z8/Function, not a Z4/Type! But Z1K1 should be types.
So what we would need would be a function that takes a Function and returns a type, say Z824, and that can now help us (in tighter syntax):
Z1K1: Z824(Z144)
(Well, in reality, that would be
Z1K1: Z1K1: Z7 Z7K1: Z1K1: Z7 Z7K1: Z1K1: Z824 Z824K1: Z144
Ah, gnarg, that's recursive!! Z824 is again a function!
And that's when you notice halfway through writing your answer that there is a mistake in your thinking.
In order to break the recursion, at least Z824(Z824) would need to be materialized, so we can call it directly. (And that's why in Lambda Calculus there is a recursion operator)
Sorry for my half-baked thoughts.
On Mon, Oct 19, 2020 at 9:16 AM Arthur Smith arthurpsmith@gmail.com wrote:
So I was wondering, can we list the contexts in which we anticipate function calls happening? There's the definition of another function - an implementation, where the arguments (values for the keys) are derived somehow from the arguments to the function being defined Or in running a test, we call a function with certain arguments and expect a certain result to compare to Or in an actual call context (API?) where an external user wants to use that function to generate a result
Are there other cases we can anticipate now? Maybe we could run through what the ZObjects would look like in each context and then see what's really needed there?
Arthur
On Sun, Oct 18, 2020 at 11:33 PM Subramanya Sastry ssastry@wikimedia.org wrote:
In general, it seems better to use explicit typing (via a Z7 object to indicate something is a function call) vs. implicit typing (if Z1K1 is a function call, then this is a function call).
It might potentially lead to simpler error semantics. What if a typo / accidental keystroke changes "Z142" to "Z12" and Z12 were not a function? Then, suddenly the behavior of wherever this object was used would change mysteriously .. in some cases, it might error immediately (because of the context), and in other cases, it might fail downstream and in other cases, it may lead to incorrect output.
With an explicit Z7 type, there is no scope for such confusion and you get immediate failure (assuming validation is enabled) on typos / errors.
Subbu. On 10/15/20 6:12 PM, Denny Vrandečić wrote:
So just thinking out loud.
I was thinking about that too - do we even need the Z7?
The advantage of having an explicit Z7 is that we know immediately that this is an object that needs to be treated specially. On the other side, that seems to be only one removed - we just need to look up the type of Z142, and if it is Function, well, there we are!
The other advantage of using an explicit Z7 is that we could use a Z142 without a Z7 embedding it like a quote in lisp. The Z7 unquotes and evaluates it.
So not sure if Z7 is needed. I would love to hear more thoughts. I have the sense that it would be really useful to keep the Z7, but I have trouble to say exactly why.
Regarding the Currying: that should not be a problem either way, though, if I understand right. So assume that we have a function curry Z78 and the concatenate function Z142.
Z1K1: Z1K1: Z7 Z7K1: Z1K1: Z78 Z78K1: Z142 Z78K2: "Wiki" K1: "data"
So here we use curry(concatenate, "Wiki"), which results in a function that takes a single string and prepends "Wiki" to it, so that would be read as curry(concatenate, "Wiki")("data")
Note that the K1 would need to be a local key as there is no global key that could be used, as the function is being created on the fly.
But please correct me if I misunderstood your comment on currying.
Thanks so much for your thoughts!
On Thu, Oct 15, 2020 at 5:34 AM Arthur Smith arthurpsmith@gmail.com wrote:
Hi Denny - this is interesting, but perhaps it means we don't even need the Z7 type at all? That is, just go with:
Z1K1: Z142 Z142K1: "Wiki" Z142K2: "data"
So every instance of Z8 (function type) is itself a type whose instances are function calls? I'm wondering how either approach would allow for currying though... I guess that gets into function implementations? But at some level you'd want a function call that allowed for combining both Z142 keys and the key of the curried function. So there may still be a need for several different key prefixes within the same ZObject?
Arthur
On Wed, Oct 14, 2020 at 7:16 PM Denny Vrandečić < dvrandecic@wikimedia.org> wrote:
This is a rather technical question. If you are not interested in the inner working of the function model, feel free to safely skip this one.
Currently, a function call is represented as follows (assume, Z142 is the concatenation function): Z1K1: Z7 Z7K1: Z144 Z144K1: "Wiki" Z144K2: "data"
If we use global keys, it would look like this: Z1K1: Z7 Z7K1: Z144 K1: "Wiki" K2: "data"
The local keys in this case get expanded against the Z7K1 value, not the Z1K1 value, as is the case for all other local keys. This makes it very different than all the other objects, and requires special handling.
The suggestion is to change the representation of function calls and make them more unified compared to the other entries, i.e. like this:
Z1K1: Z7 Z7K1: Z1K1: Z144 Z144K1: "Wiki" Z144K2: "data"
So, instead of pulling the values into the Z7 object, we basically instantiate a function just like any other type, and wrap it into a Z7 to say that this is a function call. This needs one extra object, but it leads to much more uniform handling of objects.
Any thoughts?
Cheers, Denny _______________________________________________ Abstract-Wikipedia mailing list Abstract-Wikipedia@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/abstract-wikipedia
Abstract-Wikipedia mailing list Abstract-Wikipedia@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/abstract-wikipedia
Abstract-Wikipedia mailing listAbstract-Wikipedia@lists.wikimedia.orghttps://lists.wikimedia.org/mailman/listinfo/abstract-wikipedia
Abstract-Wikipedia mailing list Abstract-Wikipedia@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/abstract-wikipedia
Abstract-Wikipedia mailing list Abstract-Wikipedia@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/abstract-wikipedia
OK, I have been thinking more about this, and also reading the comments on-wiki, which have been very enlightening and sketched out a good solution (basically the on Adam hinted at in this thread too).
https://meta.wikimedia.org/wiki/Talk:Abstract_Wikipedia/Function_model#Make_...
So the function call we used as a running example could look like this:
Z1K1: Z7 Z7K1: Z144 Z7K2: Z1K1: Z824(Z144) Z144K1: "Wiki" Z144K2: "data"
Z7K1 points to the Function to be evoked, and has Z8/Function as the value type, and so we can use Z144, which is a Function as the value. Z7K2 points to the arguments. The type of Z7K2 is using the Z824 Function on the Function. Z824 basically takes a Z8/Function and returns a Z4/Type (basically turning the Z17/argument declarations to Z3/keys, mostly).
There's a little bit of repetition (Z144 is mentioned twice, as the value of Z7K1 as well as in the Z1K1 of the Z7K2), but that also allows us to break any potential recursion by materializing the the result of Z824 (which might be necessary to express Z824(Z824) (or not, we'll see)).
I think that should solve this conundrum.
Again thanks everyone. If there are no complaints here or on-wiki, I will update the Function Model after the weekend.
Thanks, Denny
On Mon, Oct 19, 2020 at 6:35 PM Denny Vrandečić dvrandecic@wikimedia.org wrote:
In principle, I would like Z7 to be able to appear almost everywhere. Particularly, they can be a function call to create a different content in some place. (That's something I would like to steal from lisp)
One example: I noticed that one problem with my proposal is that in
Z1K1: Z144
the problem is that Z144 is actually a Z8/Function, not a Z4/Type! But Z1K1 should be types.
So what we would need would be a function that takes a Function and returns a type, say Z824, and that can now help us (in tighter syntax):
Z1K1: Z824(Z144)
(Well, in reality, that would be
Z1K1: Z1K1: Z7 Z7K1: Z1K1: Z7 Z7K1: Z1K1: Z824 Z824K1: Z144
Ah, gnarg, that's recursive!! Z824 is again a function!
And that's when you notice halfway through writing your answer that there is a mistake in your thinking.
In order to break the recursion, at least Z824(Z824) would need to be materialized, so we can call it directly. (And that's why in Lambda Calculus there is a recursion operator)
Sorry for my half-baked thoughts.
On Mon, Oct 19, 2020 at 9:16 AM Arthur Smith arthurpsmith@gmail.com wrote:
So I was wondering, can we list the contexts in which we anticipate function calls happening? There's the definition of another function - an implementation, where the arguments (values for the keys) are derived somehow from the arguments to the function being defined Or in running a test, we call a function with certain arguments and expect a certain result to compare to Or in an actual call context (API?) where an external user wants to use that function to generate a result
Are there other cases we can anticipate now? Maybe we could run through what the ZObjects would look like in each context and then see what's really needed there?
Arthur
On Sun, Oct 18, 2020 at 11:33 PM Subramanya Sastry ssastry@wikimedia.org wrote:
In general, it seems better to use explicit typing (via a Z7 object to indicate something is a function call) vs. implicit typing (if Z1K1 is a function call, then this is a function call).
It might potentially lead to simpler error semantics. What if a typo / accidental keystroke changes "Z142" to "Z12" and Z12 were not a function? Then, suddenly the behavior of wherever this object was used would change mysteriously .. in some cases, it might error immediately (because of the context), and in other cases, it might fail downstream and in other cases, it may lead to incorrect output.
With an explicit Z7 type, there is no scope for such confusion and you get immediate failure (assuming validation is enabled) on typos / errors.
Subbu. On 10/15/20 6:12 PM, Denny Vrandečić wrote:
So just thinking out loud.
I was thinking about that too - do we even need the Z7?
The advantage of having an explicit Z7 is that we know immediately that this is an object that needs to be treated specially. On the other side, that seems to be only one removed - we just need to look up the type of Z142, and if it is Function, well, there we are!
The other advantage of using an explicit Z7 is that we could use a Z142 without a Z7 embedding it like a quote in lisp. The Z7 unquotes and evaluates it.
So not sure if Z7 is needed. I would love to hear more thoughts. I have the sense that it would be really useful to keep the Z7, but I have trouble to say exactly why.
Regarding the Currying: that should not be a problem either way, though, if I understand right. So assume that we have a function curry Z78 and the concatenate function Z142.
Z1K1: Z1K1: Z7 Z7K1: Z1K1: Z78 Z78K1: Z142 Z78K2: "Wiki" K1: "data"
So here we use curry(concatenate, "Wiki"), which results in a function that takes a single string and prepends "Wiki" to it, so that would be read as curry(concatenate, "Wiki")("data")
Note that the K1 would need to be a local key as there is no global key that could be used, as the function is being created on the fly.
But please correct me if I misunderstood your comment on currying.
Thanks so much for your thoughts!
On Thu, Oct 15, 2020 at 5:34 AM Arthur Smith arthurpsmith@gmail.com wrote:
Hi Denny - this is interesting, but perhaps it means we don't even need the Z7 type at all? That is, just go with:
Z1K1: Z142 Z142K1: "Wiki" Z142K2: "data"
So every instance of Z8 (function type) is itself a type whose instances are function calls? I'm wondering how either approach would allow for currying though... I guess that gets into function implementations? But at some level you'd want a function call that allowed for combining both Z142 keys and the key of the curried function. So there may still be a need for several different key prefixes within the same ZObject?
Arthur
On Wed, Oct 14, 2020 at 7:16 PM Denny Vrandečić < dvrandecic@wikimedia.org> wrote:
This is a rather technical question. If you are not interested in the inner working of the function model, feel free to safely skip this one.
Currently, a function call is represented as follows (assume, Z142 is the concatenation function): Z1K1: Z7 Z7K1: Z144 Z144K1: "Wiki" Z144K2: "data"
If we use global keys, it would look like this: Z1K1: Z7 Z7K1: Z144 K1: "Wiki" K2: "data"
The local keys in this case get expanded against the Z7K1 value, not the Z1K1 value, as is the case for all other local keys. This makes it very different than all the other objects, and requires special handling.
The suggestion is to change the representation of function calls and make them more unified compared to the other entries, i.e. like this:
Z1K1: Z7 Z7K1: Z1K1: Z144 Z144K1: "Wiki" Z144K2: "data"
So, instead of pulling the values into the Z7 object, we basically instantiate a function just like any other type, and wrap it into a Z7 to say that this is a function call. This needs one extra object, but it leads to much more uniform handling of objects.
Any thoughts?
Cheers, Denny _______________________________________________ Abstract-Wikipedia mailing list Abstract-Wikipedia@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/abstract-wikipedia
Abstract-Wikipedia mailing list Abstract-Wikipedia@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/abstract-wikipedia
Abstract-Wikipedia mailing listAbstract-Wikipedia@lists.wikimedia.orghttps://lists.wikimedia.org/mailman/listinfo/abstract-wikipedia
Abstract-Wikipedia mailing list Abstract-Wikipedia@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/abstract-wikipedia
Abstract-Wikipedia mailing list Abstract-Wikipedia@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/abstract-wikipedia
No complaints!
I think this logic makes sense. And as you say avoid potential recursion though a bit of repetition but brings "explicit definition". I like it.
Thad https://www.linkedin.com/in/thadguidry/
On Thu, Oct 22, 2020 at 8:07 PM Denny Vrandečić dvrandecic@wikimedia.org wrote:
OK, I have been thinking more about this, and also reading the comments on-wiki, which have been very enlightening and sketched out a good solution (basically the on Adam hinted at in this thread too).
https://meta.wikimedia.org/wiki/Talk:Abstract_Wikipedia/Function_model#Make_...
So the function call we used as a running example could look like this:
Z1K1: Z7 Z7K1: Z144 Z7K2: Z1K1: Z824(Z144) Z144K1: "Wiki" Z144K2: "data"
Z7K1 points to the Function to be evoked, and has Z8/Function as the value type, and so we can use Z144, which is a Function as the value. Z7K2 points to the arguments. The type of Z7K2 is using the Z824 Function on the Function. Z824 basically takes a Z8/Function and returns a Z4/Type (basically turning the Z17/argument declarations to Z3/keys, mostly).
There's a little bit of repetition (Z144 is mentioned twice, as the value of Z7K1 as well as in the Z1K1 of the Z7K2), but that also allows us to break any potential recursion by materializing the the result of Z824 (which might be necessary to express Z824(Z824) (or not, we'll see)).
I think that should solve this conundrum.
Again thanks everyone. If there are no complaints here or on-wiki, I will update the Function Model after the weekend.
Thanks, Denny
On Mon, Oct 19, 2020 at 6:35 PM Denny Vrandečić dvrandecic@wikimedia.org wrote:
In principle, I would like Z7 to be able to appear almost everywhere. Particularly, they can be a function call to create a different content in some place. (That's something I would like to steal from lisp)
One example: I noticed that one problem with my proposal is that in
Z1K1: Z144
the problem is that Z144 is actually a Z8/Function, not a Z4/Type! But Z1K1 should be types.
So what we would need would be a function that takes a Function and returns a type, say Z824, and that can now help us (in tighter syntax):
Z1K1: Z824(Z144)
(Well, in reality, that would be
Z1K1: Z1K1: Z7 Z7K1: Z1K1: Z7 Z7K1: Z1K1: Z824 Z824K1: Z144
Ah, gnarg, that's recursive!! Z824 is again a function!
And that's when you notice halfway through writing your answer that there is a mistake in your thinking.
In order to break the recursion, at least Z824(Z824) would need to be materialized, so we can call it directly. (And that's why in Lambda Calculus there is a recursion operator)
Sorry for my half-baked thoughts.
On Mon, Oct 19, 2020 at 9:16 AM Arthur Smith arthurpsmith@gmail.com wrote:
So I was wondering, can we list the contexts in which we anticipate function calls happening? There's the definition of another function - an implementation, where the arguments (values for the keys) are derived somehow from the arguments to the function being defined Or in running a test, we call a function with certain arguments and expect a certain result to compare to Or in an actual call context (API?) where an external user wants to use that function to generate a result
Are there other cases we can anticipate now? Maybe we could run through what the ZObjects would look like in each context and then see what's really needed there?
Arthur
On Sun, Oct 18, 2020 at 11:33 PM Subramanya Sastry < ssastry@wikimedia.org> wrote:
In general, it seems better to use explicit typing (via a Z7 object to indicate something is a function call) vs. implicit typing (if Z1K1 is a function call, then this is a function call).
It might potentially lead to simpler error semantics. What if a typo / accidental keystroke changes "Z142" to "Z12" and Z12 were not a function? Then, suddenly the behavior of wherever this object was used would change mysteriously .. in some cases, it might error immediately (because of the context), and in other cases, it might fail downstream and in other cases, it may lead to incorrect output.
With an explicit Z7 type, there is no scope for such confusion and you get immediate failure (assuming validation is enabled) on typos / errors.
Subbu. On 10/15/20 6:12 PM, Denny Vrandečić wrote:
So just thinking out loud.
I was thinking about that too - do we even need the Z7?
The advantage of having an explicit Z7 is that we know immediately that this is an object that needs to be treated specially. On the other side, that seems to be only one removed - we just need to look up the type of Z142, and if it is Function, well, there we are!
The other advantage of using an explicit Z7 is that we could use a Z142 without a Z7 embedding it like a quote in lisp. The Z7 unquotes and evaluates it.
So not sure if Z7 is needed. I would love to hear more thoughts. I have the sense that it would be really useful to keep the Z7, but I have trouble to say exactly why.
Regarding the Currying: that should not be a problem either way, though, if I understand right. So assume that we have a function curry Z78 and the concatenate function Z142.
Z1K1: Z1K1: Z7 Z7K1: Z1K1: Z78 Z78K1: Z142 Z78K2: "Wiki" K1: "data"
So here we use curry(concatenate, "Wiki"), which results in a function that takes a single string and prepends "Wiki" to it, so that would be read as curry(concatenate, "Wiki")("data")
Note that the K1 would need to be a local key as there is no global key that could be used, as the function is being created on the fly.
But please correct me if I misunderstood your comment on currying.
Thanks so much for your thoughts!
On Thu, Oct 15, 2020 at 5:34 AM Arthur Smith arthurpsmith@gmail.com wrote:
Hi Denny - this is interesting, but perhaps it means we don't even need the Z7 type at all? That is, just go with:
Z1K1: Z142 Z142K1: "Wiki" Z142K2: "data"
So every instance of Z8 (function type) is itself a type whose instances are function calls? I'm wondering how either approach would allow for currying though... I guess that gets into function implementations? But at some level you'd want a function call that allowed for combining both Z142 keys and the key of the curried function. So there may still be a need for several different key prefixes within the same ZObject?
Arthur
On Wed, Oct 14, 2020 at 7:16 PM Denny Vrandečić < dvrandecic@wikimedia.org> wrote:
This is a rather technical question. If you are not interested in the inner working of the function model, feel free to safely skip this one.
Currently, a function call is represented as follows (assume, Z142 is the concatenation function): Z1K1: Z7 Z7K1: Z144 Z144K1: "Wiki" Z144K2: "data"
If we use global keys, it would look like this: Z1K1: Z7 Z7K1: Z144 K1: "Wiki" K2: "data"
The local keys in this case get expanded against the Z7K1 value, not the Z1K1 value, as is the case for all other local keys. This makes it very different than all the other objects, and requires special handling.
The suggestion is to change the representation of function calls and make them more unified compared to the other entries, i.e. like this:
Z1K1: Z7 Z7K1: Z1K1: Z144 Z144K1: "Wiki" Z144K2: "data"
So, instead of pulling the values into the Z7 object, we basically instantiate a function just like any other type, and wrap it into a Z7 to say that this is a function call. This needs one extra object, but it leads to much more uniform handling of objects.
Any thoughts?
Cheers, Denny _______________________________________________ Abstract-Wikipedia mailing list Abstract-Wikipedia@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/abstract-wikipedia
Abstract-Wikipedia mailing list Abstract-Wikipedia@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/abstract-wikipedia
Abstract-Wikipedia mailing listAbstract-Wikipedia@lists.wikimedia.orghttps://lists.wikimedia.org/mailman/listinfo/abstract-wikipedia
Abstract-Wikipedia mailing list Abstract-Wikipedia@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/abstract-wikipedia
Abstract-Wikipedia mailing list Abstract-Wikipedia@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/abstract-wikipedia
Abstract-Wikipedia mailing list Abstract-Wikipedia@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/abstract-wikipedia
Yes, I fully agree with that, and it answers Thad's questions to me better than I could.
The other thing is that I actually don't think looking up a ZObject is free. The evaluation implementation can basically pass everything that is not a Z7 unchanged on, so no look ups are needed. And that's not only true for the top level of the input, but for every subsequent level and also for every inner evaluation step.
So having an explicit Z7 marker saying "this needs to be evaluated" can speed things up considerably.
Thanks for the thoughts, it helped me quite a bit!
On Sun, Oct 18, 2020 at 8:33 PM Subramanya Sastry ssastry@wikimedia.org wrote:
In general, it seems better to use explicit typing (via a Z7 object to indicate something is a function call) vs. implicit typing (if Z1K1 is a function call, then this is a function call).
It might potentially lead to simpler error semantics. What if a typo / accidental keystroke changes "Z142" to "Z12" and Z12 were not a function? Then, suddenly the behavior of wherever this object was used would change mysteriously .. in some cases, it might error immediately (because of the context), and in other cases, it might fail downstream and in other cases, it may lead to incorrect output.
With an explicit Z7 type, there is no scope for such confusion and you get immediate failure (assuming validation is enabled) on typos / errors.
Subbu. On 10/15/20 6:12 PM, Denny Vrandečić wrote:
So just thinking out loud.
I was thinking about that too - do we even need the Z7?
The advantage of having an explicit Z7 is that we know immediately that this is an object that needs to be treated specially. On the other side, that seems to be only one removed - we just need to look up the type of Z142, and if it is Function, well, there we are!
The other advantage of using an explicit Z7 is that we could use a Z142 without a Z7 embedding it like a quote in lisp. The Z7 unquotes and evaluates it.
So not sure if Z7 is needed. I would love to hear more thoughts. I have the sense that it would be really useful to keep the Z7, but I have trouble to say exactly why.
Regarding the Currying: that should not be a problem either way, though, if I understand right. So assume that we have a function curry Z78 and the concatenate function Z142.
Z1K1: Z1K1: Z7 Z7K1: Z1K1: Z78 Z78K1: Z142 Z78K2: "Wiki" K1: "data"
So here we use curry(concatenate, "Wiki"), which results in a function that takes a single string and prepends "Wiki" to it, so that would be read as curry(concatenate, "Wiki")("data")
Note that the K1 would need to be a local key as there is no global key that could be used, as the function is being created on the fly.
But please correct me if I misunderstood your comment on currying.
Thanks so much for your thoughts!
On Thu, Oct 15, 2020 at 5:34 AM Arthur Smith arthurpsmith@gmail.com wrote:
Hi Denny - this is interesting, but perhaps it means we don't even need the Z7 type at all? That is, just go with:
Z1K1: Z142 Z142K1: "Wiki" Z142K2: "data"
So every instance of Z8 (function type) is itself a type whose instances are function calls? I'm wondering how either approach would allow for currying though... I guess that gets into function implementations? But at some level you'd want a function call that allowed for combining both Z142 keys and the key of the curried function. So there may still be a need for several different key prefixes within the same ZObject?
Arthur
On Wed, Oct 14, 2020 at 7:16 PM Denny Vrandečić dvrandecic@wikimedia.org wrote:
This is a rather technical question. If you are not interested in the inner working of the function model, feel free to safely skip this one.
Currently, a function call is represented as follows (assume, Z142 is the concatenation function): Z1K1: Z7 Z7K1: Z144 Z144K1: "Wiki" Z144K2: "data"
If we use global keys, it would look like this: Z1K1: Z7 Z7K1: Z144 K1: "Wiki" K2: "data"
The local keys in this case get expanded against the Z7K1 value, not the Z1K1 value, as is the case for all other local keys. This makes it very different than all the other objects, and requires special handling.
The suggestion is to change the representation of function calls and make them more unified compared to the other entries, i.e. like this:
Z1K1: Z7 Z7K1: Z1K1: Z144 Z144K1: "Wiki" Z144K2: "data"
So, instead of pulling the values into the Z7 object, we basically instantiate a function just like any other type, and wrap it into a Z7 to say that this is a function call. This needs one extra object, but it leads to much more uniform handling of objects.
Any thoughts?
Cheers, Denny _______________________________________________ Abstract-Wikipedia mailing list Abstract-Wikipedia@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/abstract-wikipedia
Abstract-Wikipedia mailing list Abstract-Wikipedia@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/abstract-wikipedia
Abstract-Wikipedia mailing listAbstract-Wikipedia@lists.wikimedia.orghttps://lists.wikimedia.org/mailman/listinfo/abstract-wikipedia
Abstract-Wikipedia mailing list Abstract-Wikipedia@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/abstract-wikipedia
Regarding the Currying: that should not be a problem either way, though, if I understand right. So assume that we have a function curry Z78 and the concatenate function Z142.
Z1K1: Z1K1: Z7 Z7K1: Z1K1: Z78 Z78K1: Z142 Z78K2: "Wiki" K1: "data"
So here we use curry(concatenate, "Wiki"), which results in a function that takes a single string and prepends "Wiki" to it, so that would be read as curry(concatenate, "Wiki")("data")
Is there need for an explicit currying function? Can currying fall out naturally out of the implementation? i.e. Z142("Wiki") might itself return a Z-object which is a Z8?
Subbu.
Yes, I was thinking about that, and the Abstracttext implementation used to allow for implicit currying.
The advantage of *not* allowing implicit currying is that we have a stronger shape of the function call that we can test.
So, if implicit currying is forbidden, then any function call with fewer than the expected number of arguments becomes a validation error. We catch them early.
If implicit currying is allowed, all of these wouldn't be errors, but instead of an integer (or whatever), you suddenly get a function back.
I think the latter is potentially confusing and requires even beginners to be exposed to, well, curried functions and anonymous functions as return values.
If we require explicit currying, we don't lose any of the functionality - everything we could do before we still can do - but we lose some notational convenience for currying (which is kinda of a poweruser feature) but will probably catch much more errors than we would otherwise.
That would be my thoughts on implicit currying.
Denny
On Sun, Oct 18, 2020 at 8:47 PM Subramanya Sastry ssastry@wikimedia.org wrote:
Regarding the Currying: that should not be a problem either way, though, if I understand right. So assume that we have a function curry Z78 and the concatenate function Z142.
Z1K1: Z1K1: Z7 Z7K1: Z1K1: Z78 Z78K1: Z142 Z78K2: "Wiki" K1: "data"
So here we use curry(concatenate, "Wiki"), which results in a function that takes a single string and prepends "Wiki" to it, so that would be read as curry(concatenate, "Wiki")("data")
Is there need for an explicit currying function? Can currying fall out naturally out of the implementation? i.e. Z142("Wiki") might itself return a Z-object which is a Z8?
Subbu.
Abstract-Wikipedia mailing list Abstract-Wikipedia@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/abstract-wikipedia
Why 7? What does 7 mean?
I guess that it's some basic important ZObject, but where is it defined? Is it documented anywhere? Is the number 7 arbitrary, or is there a natural reason that it's 7?
-- Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי http://aharoni.wordpress.com “We're living in pieces, I want to live in peace.” – T. Moore
בתאריך יום ה׳, 15 באוק׳ 2020 ב-2:16 מאת Denny Vrandečić < dvrandecic@wikimedia.org>:
This is a rather technical question. If you are not interested in the inner working of the function model, feel free to safely skip this one.
Currently, a function call is represented as follows (assume, Z142 is the concatenation function): Z1K1: Z7 Z7K1: Z144 Z144K1: "Wiki" Z144K2: "data"
If we use global keys, it would look like this: Z1K1: Z7 Z7K1: Z144 K1: "Wiki" K2: "data"
The local keys in this case get expanded against the Z7K1 value, not the Z1K1 value, as is the case for all other local keys. This makes it very different than all the other objects, and requires special handling.
The suggestion is to change the representation of function calls and make them more unified compared to the other entries, i.e. like this:
Z1K1: Z7 Z7K1: Z1K1: Z144 Z144K1: "Wiki" Z144K2: "data"
So, instead of pulling the values into the Z7 object, we basically instantiate a function just like any other type, and wrap it into a Z7 to say that this is a function call. This needs one extra object, but it leads to much more uniform handling of objects.
Any thoughts?
Cheers, Denny _______________________________________________ Abstract-Wikipedia mailing list Abstract-Wikipedia@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/abstract-wikipedia
Why 7? What does 7 mean?
I guess that it's some basic important ZObject, but where is it defined?
Is it documented anywhere? Is the number 7 arbitrary, or is there a natural reason that it's 7?
It refers to the Blues song, of course! https://www.youtube.com/watch?v=llOo7OmnmYA :)
---
My naive understanding is that it is just the sixth type of ZObject enumerated in https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Function_model — the first type being "Z2/Persistent object." https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Function_model#Z1/ZObjects
See https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Function_model#Z7/Functio... in particular.
Thanks,
Chris Cooley
On Fri, Oct 16, 2020 at 5:07 AM Amir E. Aharoni < amir.aharoni@mail.huji.ac.il> wrote:
Why 7? What does 7 mean?
I guess that it's some basic important ZObject, but where is it defined? Is it documented anywhere? Is the number 7 arbitrary, or is there a natural reason that it's 7?
-- Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי http://aharoni.wordpress.com “We're living in pieces, I want to live in peace.” – T. Moore
בתאריך יום ה׳, 15 באוק׳ 2020 ב-2:16 מאת Denny Vrandečić < dvrandecic@wikimedia.org>:
This is a rather technical question. If you are not interested in the inner working of the function model, feel free to safely skip this one.
Currently, a function call is represented as follows (assume, Z142 is the concatenation function): Z1K1: Z7 Z7K1: Z144 Z144K1: "Wiki" Z144K2: "data"
If we use global keys, it would look like this: Z1K1: Z7 Z7K1: Z144 K1: "Wiki" K2: "data"
The local keys in this case get expanded against the Z7K1 value, not the Z1K1 value, as is the case for all other local keys. This makes it very different than all the other objects, and requires special handling.
The suggestion is to change the representation of function calls and make them more unified compared to the other entries, i.e. like this:
Z1K1: Z7 Z7K1: Z1K1: Z144 Z144K1: "Wiki" Z144K2: "data"
So, instead of pulling the values into the Z7 object, we basically instantiate a function just like any other type, and wrap it into a Z7 to say that this is a function call. This needs one extra object, but it leads to much more uniform handling of objects.
Any thoughts?
Cheers, Denny _______________________________________________ Abstract-Wikipedia mailing list Abstract-Wikipedia@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/abstract-wikipedia
Abstract-Wikipedia mailing list Abstract-Wikipedia@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/abstract-wikipedia
Hi Amir,
thanks for the question for clarification. As stated in the original post, this is about the function model. The function model is described here:
https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Function_model
On Fri, Oct 16, 2020 at 2:07 AM Amir E. Aharoni < amir.aharoni@mail.huji.ac.il> wrote:
Why 7? What does 7 mean?
I guess that it's some basic important ZObject, but where is it defined? Is it documented anywhere? Is the number 7 arbitrary, or is there a natural reason that it's 7?
-- Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי http://aharoni.wordpress.com “We're living in pieces, I want to live in peace.” – T. Moore
בתאריך יום ה׳, 15 באוק׳ 2020 ב-2:16 מאת Denny Vrandečić < dvrandecic@wikimedia.org>:
This is a rather technical question. If you are not interested in the inner working of the function model, feel free to safely skip this one.
Currently, a function call is represented as follows (assume, Z142 is the concatenation function): Z1K1: Z7 Z7K1: Z144 Z144K1: "Wiki" Z144K2: "data"
If we use global keys, it would look like this: Z1K1: Z7 Z7K1: Z144 K1: "Wiki" K2: "data"
The local keys in this case get expanded against the Z7K1 value, not the Z1K1 value, as is the case for all other local keys. This makes it very different than all the other objects, and requires special handling.
The suggestion is to change the representation of function calls and make them more unified compared to the other entries, i.e. like this:
Z1K1: Z7 Z7K1: Z1K1: Z144 Z144K1: "Wiki" Z144K2: "data"
So, instead of pulling the values into the Z7 object, we basically instantiate a function just like any other type, and wrap it into a Z7 to say that this is a function call. This needs one extra object, but it leads to much more uniform handling of objects.
Any thoughts?
Cheers, Denny _______________________________________________ Abstract-Wikipedia mailing list Abstract-Wikipedia@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/abstract-wikipedia
Abstract-Wikipedia mailing list Abstract-Wikipedia@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/abstract-wikipedia
abstract-wikipedia@lists.wikimedia.org