4 ms·

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 Ka

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.
- rabarbers 5y ago
  Tuples require object deconstruction syntax. KatLang does not have object deconstruction feature. KatLang has simply deconstructed the function into input and output. In KatLang you define algorithms by specifying inputs and outputs. If You use implicit parameter, then the algorithm has an input. If You do not use implicit parameters, then the algorithm has only output and it is more like a data structure rather than a function. 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.
  - chrismorgan 5y ago
    Minor technical correction: tuples don’t require deconstruction syntax; x[0] takes the first element of a tuple in Python, and x.0 in Rust (though it is fun to note that Rust only got that in late 2014, before which pattern matching was the only way of pulling values out of a tuple). For the rest, I maintain my position. :-)
    - rabarbers 5y ago
      I am mainly inspired by C#. Ok, I can agree, that some things depends on the interpretation. You can think about several returned values as a tuple. In designing Algorithm concept, I was thinking how to decompose or deconstruct a mathematical function - to be able to operate with parameters, to transform input into output. Here You will say that it is the definition of function. Well, I went little bit further. In KatLang it is very important if you use brackets () or {}. Both brackets defines an algorithm, but () cannot hold implicit parameter. Maybe thinking from this perspective will help you see some more value in KatLang. What I wanted to say is that in KatLang I 'destroyed' or 'decomposed' mathematical function and used the parts to construct a concept that in KatLang is called an algorithm.

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.

rabarbers 5y ago
Tuples require object deconstruction syntax. KatLang does not have object deconstruction feature. KatLang has simply deconstructed the function into input and output. In KatLang you define algorithms by specifying inputs and outputs. If You use implicit parameter, then the algorithm has an input. If You do not use implicit parameters, then the algorithm has only output and it is more like a data structure rather than a function. 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.
- chrismorgan 5y ago
  Minor technical correction: tuples don’t require deconstruction syntax; x[0] takes the first element of a tuple in Python, and x.0 in Rust (though it is fun to note that Rust only got that in late 2014, before which pattern matching was the only way of pulling values out of a tuple). For the rest, I maintain my position. :-)
  - rabarbers 5y ago
    I am mainly inspired by C#. Ok, I can agree, that some things depends on the interpretation. You can think about several returned values as a tuple. In designing Algorithm concept, I was thinking how to decompose or deconstruct a mathematical function - to be able to operate with parameters, to transform input into output. Here You will say that it is the definition of function. Well, I went little bit further. In KatLang it is very important if you use brackets () or {}. Both brackets defines an algorithm, but () cannot hold implicit parameter. Maybe thinking from this perspective will help you see some more value in KatLang. What I wanted to say is that in KatLang I 'destroyed' or 'decomposed' mathematical function and used the parts to construct a concept that in KatLang is called an algorithm.