Show HN: KatLang – Language for Calculations
katlang.org
katlang.org
Curious about the syntax of function declaration - i.e.:
A = x * y + x
A(2, 3)
Rather than having it explict either via:
A = (x, y) => x * y + x
A(x = 2, y = 3)
A = x * y + x
A = y * x + x
A1 = x * y + x
A2 = y * x + x
A1(1, 2), A2(1, 2) A1 = x~ * y + x Sorry, I do not know how to post code snippets in HN properly.
A1 = x * y + x
A2 = y * x + y function A1(x, y) {return x*y + x; }
function A2(y, x) {return y*x + y; }
A1 = y~ * x + y
A1 = y * ~x + y
A1 = y * x + y~
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.
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.
I agree, that parameter ignorance operator # is ugly. I do not like it. The plan is to remove it in the future versions, but it requires some research.
About expression reading and parsing... Your argument is correct, but KatLang expressions are relatively short. I do not expect that KatLang will replace general purpose programming languages. KatLang is just a simple language for calculations. Main goal was to redesign the calculator and KatLang is good for that.
For the rest, I maintain my position. :-)
let toto = function
| 0 -> 'a'
| _ -> 'b'
> 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/:
sum = fn (a, b) -> a + b end
sum.(2, 3)
sum = &(&1 + &2)
sum.(2, 3) function(x) {return x; }
x
Thanks for the elixir examples.
It does! Elixir (coming from Erlang) and Haskell have the same thing, both through pattern matching of a function to different definitions. OCaml (and most other languages using pattern matching) pattern match inside a single definition.
> In mathematics exists many different concepts which are called perfect. For example, perfect numbers.
I personally only know about perfect numbers. I'm not sure if it's a great name for them, or if it's just a "fun" name like sexy prime https://en.wikipedia.org/wiki/Sexy_prime that doesn't mean much.
For your example about the identity function, I think it's great, but I'm personally more in favour of positional lambdas like &1 in Elixir.
> The question is: can you remove one more symbol without changing the meaning of the expression? If no, then, the identity function definition 'x' is symbols perfect according to my definition.
Maybe "minimal" would be a better name then? Or "shortest"? Many people could argue on what makes the perfect lambda, but it's hard to argue that yours isn't the most minimal or shortest.
Captured variables too appear in the method body. How do I tell those apart?
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.
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?
{y+x*z}[1;2;3]
5
And in Q you cannot define implicit parameters with names, for example,: a, b, c. But You can define parameters explicitly:
{[a;b;c]a+b*c}[1;2;3]
In KatLang there are no predefined implicit parameter names. The user is the one who defines implicit parameters by declaring the implicit parameter names.
x:42;
f:{[a]x+a}
x=42;
f=function(a){return x+a} x:42
{x+1}[5]
6
a:42
{[a]a+1}[5]
a=42;
f=function(a){return a+1}
f:{[g] {g+x}}
Depending on how you host, the easiest solution might be to use the caddy web server which has letsencrypt built in.
But that's not something that even client-side code supplied by HTTP should be capable of ensuring, considering that somebody could have intercepted it somewhere on the route and replaced it with something that does send it somewhere.