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.



On Thu, Oct 15, 2020 at 6:17 PM Denny Vrandečić <vrandecic@gmail.com> wrote:
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.

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-functions/

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" ?



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