6 ms·

Looks good. Curious about the syntax of function declaration - i.e.: A = x * y + x And then I invoke it by: A(2, 3) Implicitly using the order of whi

Looks good. Curious about the syntax of function declaration - i.e.: A = x * y + x And then I invoke it by: A(2, 3) Implicitly using the order of which the parameters were used in the function declaration. Rather than having it explict either via: A = (x, y) => x * y + x Or via named parameters: A(x = 2, y = 3) Why this design?

rabarbers 5y ago
I was obsessed with the perfect syntax. Declaring method parameters in method parameters list is redundant, because the parameters appear in the method body anyway. This approach is not the best in all situations, but for short expressions, like lambda expressions, it is perfect (in my opinion). Check my paper on comparing lambda expression implementation: https://www.bjmc.lu.lv/fileadmin/user_upload/lu_portal/projekti/bjmc/Contents/6_1_02_Vanags.pdf https://www.bjmc.lu.lv/fileadmin/user_upload/lu_portal/proje...
- throwaway4good 5y ago
  It creates the situation where these two functions appear to be identical but they are not: A = x * y + x A = y * x + x It is an interesting subject, and in general you would want to balance usability, people's expectations, and succinctness.
  - rabarbers 5y ago
    It is not the same. A1 = x * y + x A2 = y * x + x A1(1, 2), A2(1, 2) returns results 3, 4 If You want to change parameter order, You can use Grace~ operator like this: A1 = x~ * y + x it moves parameter x one position towards the end of the parameters list. Sorry, I do not know how to post code snippets in HN properly.
    - throwaway4good 5y ago
      Indent with 3 spaces or more.
      - chrismorgan 5y ago
        (Two, actually.)
    - geocar 5y ago
      I think they meant: A1 = x * y + x A2 = y * x + y
      - rabarbers 5y ago
        A1 in Javascript pseudocode would be: function A1(x, y) {return x*y + x; } But A2 would be: function A2(y, x) {return y*x + y; } If you do not like the default order of implicit parameters, you can always use Grace~ operator to move x or y. Prefix form moves the parameter one position towards the beginning of the parameters list, postfix form moves one position towards the end of the parameters list: A1 = y~ * x + y or A1 = y * ~x + y or [Edit] A1 = y * x + y~ In the last example take into consideration, that without Grace~ operator y is the first parameter, so, you need to move it one position towards the end of the parameters list - therefore use postfix form of Grace~ operator.
- chrismorgan 5y ago
  I don’t think you got the perfect syntax. Being both implicit and order-based is just begging for mistakes. Your Grace~ operator is esoteric, making it quite impossible for a casual reader to understand what’s going on, and being just another unusual thing for the reader to keep in mind about the language. This sort of thing is slightly mitigated by tooling support (an IDE-like thing that reminds you of the order), but it’s generally a bad idea to depend on such tooling for sane operation. Meanwhile, `A(x, y) = x * y + x` is only slightly more verbose, but extremely clear as it matches standard practice in mathematics and is easily familiar to programmers as well. I think it’s fairly unambiguously a superior syntax for use. Short and non-repeating is not all there is to life.
  - rabarbers 5y ago
    Modern math syntax is relatively new, it started to form in 18th century. It is not too late to make some changes. Implicit parameters is only one feature in KatLang. Classic math functions can return only one value, that is why in KatLang there are no functions. In KatLang everything is an algorithm - concept which can return several outputs. Yes, some programming languages have syntactic sugar for that too, but still there are no accepted general syntax. Lambda is special case for an algorithm! Even natural languages have experienced a lot of changes. For example, Latvian language grammar changed in only 10 years. Maybe You are right about implicit parameters, but I believe, that implicit parameters are useful and I will try to convince the world about it. We will see how it will turn out ;).
    - chrismorgan 5y ago
      Few programming languages actually support returning multiple values, and those that do are I think all quite old: the usual course these days is just to support record or tuple/list types and some kind of destructuring syntax, with the completely incidental effect of simulating returning multiple values, typically without any syntax sugar (unless you count destructuring, which is normally strictly sugar, but it’s often more a fundamental language feature and not really related to multiple return values). KatLang’s algorithms look to me to just be functions that return tuples. Am I wrong? Requiring that the reader read the entire expression before they can know the arguments they need to provide and the order they need to provide them in is not a good thing. Add the Grace~ operator and they have to parse even more, maintain a list of arguments in their head and even reorder them mentally! That’s massive cognitive overhead. If people start using this for anything of even moderate size, you will observe people writing the signature in comments—or perhaps, if I’ve read your docs properly, writing `A = #x, #y, x * y + y`. There’s a reason why serious programming languages all specify the signature separately from the body.
- Zababa 5y ago
  There's at least one type of lambda missing from your paper, the OCaml function. After using the keyword `function`, you can directly go into a match: let toto = function | 0 -> 'a' | _ -> 'b' About the contents of the paper, I'm not sure that I agree with you. There is a clear distinction between lambdas with shorthands and lambdas with named parameters, and I think it exists for a good reason. You seem to base your reasoning on the following: > The number of symbols is a fundamental aspect of code readability (Tashtoush et al., 2013). In general, the shorter and more compact the code, the higher the code readability factor. Therefore, the perfect lambda syntax makes lambda expressions more readable and improves code editability factor (Blow, 2014) allowing programmers to be more productive in their work. I'm not convinced that it's true. From the abstract of Tashtoush et al., 2013: > The survey responses were analyzed using SPSS statistical tool. Most of proposed code features showed to have significantly positive impact on enhancing readability including: meaningful names, consistency, and comments. On the other hand, fewer features such as arithmetic formulas, nested loops, and recursive functions showed to have a negative impact. That doesn't seem to agree with what you said. Also: > In general, the shorter and more compact the code, the higher the code readability factor. I'm not sure where that comes from, but I'm also not convinced that it's true. Try limiting yourself to only one or two characters for name and you will quickly discover that it's probably not generally true. As an aside, is this a common thing in academia to call something "perfect"? I personally find it weird and even a bit unprofessional but maybe I'm not used to how people talk in papers. Edit: after thinking about it a bit more, I found why I don't like the type of lambda you proposed. In programming, a lot of people (me included) have the belief that you should be able to sometimes only know the interface of something, not the implementation behind it. Naming your parameters properly is a way to separate that interface and that implementation. Both "sides" agree on what is exchanged, and part of that "contract" is in the name of the parameters. However, as with all things, there are trade-offs. Sometimes you don't need a strong separation between the two. Lambda expressions are often used in that case: you don't name the function, as you're the one directly using it. However, just because you don't name the function doesn't mean you also don't want to name the parameters, at least all the time. The name of the parameters are often an important part of an interface: the interface of the higher order function you are using. I often use reduce or fold, in a wide variety of language, and I always have trouble remembering if the accumulator is the first or the second parameter of the function I'm passing to reduce. But when I read code that use "acc" and "el", it's very easy to see which is which. All of that to say that your perfect lambda syntax seems to be a small improvement over the existing positional lambda, and doesn't replace lambdas with named parameters, that have a place. Elixir has both anonymous functions with named parameters and anonymous functions with positional parameters. Both have their use. Example taken from https://elixirschool.com/en/lessons/basics/functions/ https://elixirschool.com/en/lessons/basics/functions/: sum = fn (a, b) -> a + b end sum.(2, 3) sum = &(&1 + &2) sum.(2, 3)
- Joker_vD 5y ago
  > parameters appear in the method body anyway Captured variables too appear in the method body. How do I tell those apart?
  - rabarbers 5y ago
    You need to carefully pick the right brackets () or {}. You can define an algorithm with both of the brackets, the difference is that () does not capture the parameter, but {} captures the parameter which is used inside the brackets. When You define a property, then property body is automatically interpreted as defined in {} brackets.
chrismorgan 5y ago
I expected `A(x, y) = x * y + x`, in line with standard mathematical function notation.
- rabarbers 5y ago
  When you have A=xy+x from math perspective it looks like assigning a value to a variable. When You use A(x,y)=xy+x it looks like math function definition. You can look at it as if used variable assignment syntax and changed underlying semantics to the function definition syntax. I suppose, people are familiar with classic math syntax and it will be difficult to change their beliefs. But I also believe, that smartphone usage can change people habits. When function body defines the function signature, it is much easier to move around the function definition on small screen devices, define function, edit, and so on... I advice to watch promotional video for KatLang predecessor - https://www.youtube.com/watch?v=ya8beSCx1IA https://www.youtube.com/watch?v=ya8beSCx1IA It is still available on Windows Phone marketplace as IlCalculus app. Next goal is to develop Android app and I believe then it will be much easier to convince you, that implicit parameter declaration is the future feature of the clalculator.
  - chrismorgan 5y ago
    OK, for typing on a mobile device I can see such a thing, but I think it’d be better to leave the language doing the clear, explicit thing and having the mobile app assist you in some way with converting an expression to a function declaration with automatic parameter ordering.
geocar 5y ago
Without trying to speak to why "katlang" does what it does, there are other languages that do this and I can speak to how useful it is when you already prefer functions of low arity: It repeatedly demonstrates a substantial improvement in bug/defect reduction and code. APL does this; a function like {ω×α+ω} and assigns omega to the right-argument, and alpha to the left-argument. They also have ωω for the right-side function and αα for the left-hand function for writing higher-order functions. Dyadic expressions tend to modify their right-hand argument, and not the left, so for the times that the arguments are "backwards" this can usually be fixed with the commute operator (⍨) which looks similar to katlang's "grace" operator (~) so I assume at least some influence. k/q does something more similar: a function like {x*y+x} assigns the first argument to x, the second to y, the third to z. The author seems inspired by this behaviour (even mentioning it in a linked paper). In q, when the function is in the q context, x is the left-argument and y is the right-argument when called dyadically. Sadly, q and k don't have commute.
- rabarbers 5y ago
  I will do some research on APL and your mentioned 'commute operator', cannot comment on it now. But regarding languages: k/q the issues with them is that they use x, y and z as keywords for the parameters. x is always the first parameter, y - second, z - third. In KatLang parameter names are not predefined keywords, you can pick almost any parameter names you like.
  - geocar 5y ago
    > But regarding languages: k/q the issues with them is that they use x, y and z as keywords for the parameters. x is always the first parameter, y - second, z - third. In KatLang parameter names are not predefined keywords, you can pick almost any parameter names you like. They aren't in q either: x can be redefined to whatever you like. How does KatLang determine which argument is first? Is it merely the first free variable?
    - rabarbers 5y ago
      Yes, the first unknown identifier becomes the first parameter, next unknown identifier becomes next parameter and so on...

rabarbers 5y ago

I was obsessed with the perfect syntax. Declaring method parameters in method parameters list is redundant, because the parameters appear in the method body anyway. This approach is not the best in all situations, but for short expressions, like lambda expressions, it is perfect (in my opinion). Check my paper on comparing lambda expression implementation: https://www.bjmc.lu.lv/fileadmin/user_upload/lu_portal/projekti/bjmc/Contents/6_1_02_Vanags.pdf https://www.bjmc.lu.lv/fileadmin/user_upload/lu_portal/proje...

throwaway4good 5y ago
It creates the situation where these two functions appear to be identical but they are not: A = x * y + x A = y * x + x It is an interesting subject, and in general you would want to balance usability, people's expectations, and succinctness.
- rabarbers 5y ago
  It is not the same. A1 = x * y + x A2 = y * x + x A1(1, 2), A2(1, 2) returns results 3, 4 If You want to change parameter order, You can use Grace~ operator like this: A1 = x~ * y + x it moves parameter x one position towards the end of the parameters list. Sorry, I do not know how to post code snippets in HN properly.
  - throwaway4good 5y ago
    Indent with 3 spaces or more.
    - chrismorgan 5y ago
      (Two, actually.)
  - geocar 5y ago
    I think they meant: A1 = x * y + x A2 = y * x + y
    - rabarbers 5y ago
      A1 in Javascript pseudocode would be: function A1(x, y) {return x*y + x; } But A2 would be: function A2(y, x) {return y*x + y; } If you do not like the default order of implicit parameters, you can always use Grace~ operator to move x or y. Prefix form moves the parameter one position towards the beginning of the parameters list, postfix form moves one position towards the end of the parameters list: A1 = y~ * x + y or A1 = y * ~x + y or [Edit] A1 = y * x + y~ In the last example take into consideration, that without Grace~ operator y is the first parameter, so, you need to move it one position towards the end of the parameters list - therefore use postfix form of Grace~ operator.
chrismorgan 5y ago
I don’t think you got the perfect syntax. Being both implicit and order-based is just begging for mistakes. Your Grace~ operator is esoteric, making it quite impossible for a casual reader to understand what’s going on, and being just another unusual thing for the reader to keep in mind about the language. This sort of thing is slightly mitigated by tooling support (an IDE-like thing that reminds you of the order), but it’s generally a bad idea to depend on such tooling for sane operation. Meanwhile, `A(x, y) = x * y + x` is only slightly more verbose, but extremely clear as it matches standard practice in mathematics and is easily familiar to programmers as well. I think it’s fairly unambiguously a superior syntax for use. Short and non-repeating is not all there is to life.
- rabarbers 5y ago
  Modern math syntax is relatively new, it started to form in 18th century. It is not too late to make some changes. Implicit parameters is only one feature in KatLang. Classic math functions can return only one value, that is why in KatLang there are no functions. In KatLang everything is an algorithm - concept which can return several outputs. Yes, some programming languages have syntactic sugar for that too, but still there are no accepted general syntax. Lambda is special case for an algorithm! Even natural languages have experienced a lot of changes. For example, Latvian language grammar changed in only 10 years. Maybe You are right about implicit parameters, but I believe, that implicit parameters are useful and I will try to convince the world about it. We will see how it will turn out ;).
  - chrismorgan 5y ago
    Few programming languages actually support returning multiple values, and those that do are I think all quite old: the usual course these days is just to support record or tuple/list types and some kind of destructuring syntax, with the completely incidental effect of simulating returning multiple values, typically without any syntax sugar (unless you count destructuring, which is normally strictly sugar, but it’s often more a fundamental language feature and not really related to multiple return values). KatLang’s algorithms look to me to just be functions that return tuples. Am I wrong? Requiring that the reader read the entire expression before they can know the arguments they need to provide and the order they need to provide them in is not a good thing. Add the Grace~ operator and they have to parse even more, maintain a list of arguments in their head and even reorder them mentally! That’s massive cognitive overhead. If people start using this for anything of even moderate size, you will observe people writing the signature in comments—or perhaps, if I’ve read your docs properly, writing `A = #x, #y, x * y + y`. There’s a reason why serious programming languages all specify the signature separately from the body.
Zababa 5y ago
There's at least one type of lambda missing from your paper, the OCaml function. After using the keyword `function`, you can directly go into a match: let toto = function | 0 -> 'a' | _ -> 'b' About the contents of the paper, I'm not sure that I agree with you. There is a clear distinction between lambdas with shorthands and lambdas with named parameters, and I think it exists for a good reason. You seem to base your reasoning on the following: > The number of symbols is a fundamental aspect of code readability (Tashtoush et al., 2013). In general, the shorter and more compact the code, the higher the code readability factor. Therefore, the perfect lambda syntax makes lambda expressions more readable and improves code editability factor (Blow, 2014) allowing programmers to be more productive in their work. I'm not convinced that it's true. From the abstract of Tashtoush et al., 2013: > The survey responses were analyzed using SPSS statistical tool. Most of proposed code features showed to have significantly positive impact on enhancing readability including: meaningful names, consistency, and comments. On the other hand, fewer features such as arithmetic formulas, nested loops, and recursive functions showed to have a negative impact. That doesn't seem to agree with what you said. Also: > In general, the shorter and more compact the code, the higher the code readability factor. I'm not sure where that comes from, but I'm also not convinced that it's true. Try limiting yourself to only one or two characters for name and you will quickly discover that it's probably not generally true. As an aside, is this a common thing in academia to call something "perfect"? I personally find it weird and even a bit unprofessional but maybe I'm not used to how people talk in papers. Edit: after thinking about it a bit more, I found why I don't like the type of lambda you proposed. In programming, a lot of people (me included) have the belief that you should be able to sometimes only know the interface of something, not the implementation behind it. Naming your parameters properly is a way to separate that interface and that implementation. Both "sides" agree on what is exchanged, and part of that "contract" is in the name of the parameters. However, as with all things, there are trade-offs. Sometimes you don't need a strong separation between the two. Lambda expressions are often used in that case: you don't name the function, as you're the one directly using it. However, just because you don't name the function doesn't mean you also don't want to name the parameters, at least all the time. The name of the parameters are often an important part of an interface: the interface of the higher order function you are using. I often use reduce or fold, in a wide variety of language, and I always have trouble remembering if the accumulator is the first or the second parameter of the function I'm passing to reduce. But when I read code that use "acc" and "el", it's very easy to see which is which. All of that to say that your perfect lambda syntax seems to be a small improvement over the existing positional lambda, and doesn't replace lambdas with named parameters, that have a place. Elixir has both anonymous functions with named parameters and anonymous functions with positional parameters. Both have their use. Example taken from https://elixirschool.com/en/lessons/basics/functions/ https://elixirschool.com/en/lessons/basics/functions/: sum = fn (a, b) -> a + b end sum.(2, 3) sum = &(&1 + &2) sum.(2, 3)
Joker_vD 5y ago
> parameters appear in the method body anyway Captured variables too appear in the method body. How do I tell those apart?
- rabarbers 5y ago
  You need to carefully pick the right brackets () or {}. You can define an algorithm with both of the brackets, the difference is that () does not capture the parameter, but {} captures the parameter which is used inside the brackets. When You define a property, then property body is automatically interpreted as defined in {} brackets.

chrismorgan 5y ago

I expected `A(x, y) = x * y + x`, in line with standard mathematical function notation.

rabarbers 5y ago
When you have A=xy+x from math perspective it looks like assigning a value to a variable. When You use A(x,y)=xy+x it looks like math function definition. You can look at it as if used variable assignment syntax and changed underlying semantics to the function definition syntax. I suppose, people are familiar with classic math syntax and it will be difficult to change their beliefs. But I also believe, that smartphone usage can change people habits. When function body defines the function signature, it is much easier to move around the function definition on small screen devices, define function, edit, and so on... I advice to watch promotional video for KatLang predecessor - https://www.youtube.com/watch?v=ya8beSCx1IA https://www.youtube.com/watch?v=ya8beSCx1IA It is still available on Windows Phone marketplace as IlCalculus app. Next goal is to develop Android app and I believe then it will be much easier to convince you, that implicit parameter declaration is the future feature of the clalculator.
- chrismorgan 5y ago
  OK, for typing on a mobile device I can see such a thing, but I think it’d be better to leave the language doing the clear, explicit thing and having the mobile app assist you in some way with converting an expression to a function declaration with automatic parameter ordering.

geocar 5y ago

Without trying to speak to why "katlang" does what it does, there are other languages that do this and I can speak to how useful it is when you already prefer functions of low arity: It repeatedly demonstrates a substantial improvement in bug/defect reduction and code. APL does this; a function like {ω×α+ω} and assigns omega to the right-argument, and alpha to the left-argument. They also have ωω for the right-side function and αα for the left-hand function for writing higher-order functions. Dyadic expressions tend to modify their right-hand argument, and not the left, so for the times that the arguments are "backwards" this can usually be fixed with the commute operator (⍨) which looks similar to katlang's "grace" operator (~) so I assume at least some influence. k/q does something more similar: a function like {x*y+x} assigns the first argument to x, the second to y, the third to z. The author seems inspired by this behaviour (even mentioning it in a linked paper). In q, when the function is in the q context, x is the left-argument and y is the right-argument when called dyadically. Sadly, q and k don't have commute.

rabarbers 5y ago
I will do some research on APL and your mentioned 'commute operator', cannot comment on it now. But regarding languages: k/q the issues with them is that they use x, y and z as keywords for the parameters. x is always the first parameter, y - second, z - third. In KatLang parameter names are not predefined keywords, you can pick almost any parameter names you like.
- geocar 5y ago
  > But regarding languages: k/q the issues with them is that they use x, y and z as keywords for the parameters. x is always the first parameter, y - second, z - third. In KatLang parameter names are not predefined keywords, you can pick almost any parameter names you like. They aren't in q either: x can be redefined to whatever you like. How does KatLang determine which argument is first? Is it merely the first free variable?
  - rabarbers 5y ago
    Yes, the first unknown identifier becomes the first parameter, next unknown identifier becomes next parameter and so on...