3 ms·

Hello, I guess I should have been more explicit. I'm sorry for the confusion. First, Tamgu is a language in which the recipient variable defines the context i

Hello, I guess I should have been more explicit. I'm sorry for the confusion. First, Tamgu is a language in which the recipient variable defines the context in which the instruction is evaluated. If your recipient variable is an integer then everything on the right side of your assignment will be treated as an integer. If it is a string, well everything will be treated as a string. We use this approach in many other instances: int pos; vector v; string s="This is a testing case"; pos = "i" in s; //we are looking for "i" in the string In this case, pos==2. v = "i" in s; //we are looking for all positions of "i" in the string v == [2,5,14]

tempguy9999 7y ago
oof. I see what you say about the LHS defining how the RHS is evaluated but that attaches expression evaluation to assignment. You can't do one without the other. Also the target type may be obscure to the programmer. What's the behaviour with string s="This is a testing case"; println("i" in s); But separately your example now looks even worse. It's quite reasonable to expect 'in' to behave the same way for both cases; that they both return [2,5,14] - now you've added another complication. No offence but without some overriding principle, and a justification for that principle (that "things are demonstrably easier if you do it this way"), you've just dumped and extra load on the programmer which I do not need!.
- clauderoux 7y ago
  None taken... :-) Well, I did my fair share of programming over the years in so many different languages (Pascal, Cobol, C, C++, Java, Python, APL, Lisp, Prolog, Basic, Small Talk, various assemblers) that I honestly cannot remember all of them. Tamgu is the result of this experience and my choice was always towards compactness and readability, with Perl being my personal nemesis. The advantage of this approach is that you don't need to remember a long list of operators, they are simply re-interpreted in context and the re-interpretation is pretty consistent over most of the code. But, well as the adage goes: Of tastes and colors...
- clauderoux 7y ago
  By the way, you can easily enforce whatever interpretation you want with a cast: println(vector("i" in s));
dkersten 7y ago
I personally value clarity and this seems to obscure meaning. I'm ok with operator overloading when its super clear (eg + is addition, so having it overloaded to also do vector addition is clear to me, but overloading it to do string concatenation is less clear). I guess my worry is that this adds unnecessary cognitive load for minor convenience. Having said that, if it works for you, awesome. Don't let me tell you otherwise, not everything has to be to my taste, after all.

tempguy9999 7y ago

oof. I see what you say about the LHS defining how the RHS is evaluated but that attaches expression evaluation to assignment. You can't do one without the other. Also the target type may be obscure to the programmer. What's the behaviour with string s="This is a testing case"; println("i" in s); But separately your example now looks even worse. It's quite reasonable to expect 'in' to behave the same way for both cases; that they both return [2,5,14] - now you've added another complication. No offence but without some overriding principle, and a justification for that principle (that "things are demonstrably easier if you do it this way"), you've just dumped and extra load on the programmer which I do not need!.

clauderoux 7y ago
None taken... :-) Well, I did my fair share of programming over the years in so many different languages (Pascal, Cobol, C, C++, Java, Python, APL, Lisp, Prolog, Basic, Small Talk, various assemblers) that I honestly cannot remember all of them. Tamgu is the result of this experience and my choice was always towards compactness and readability, with Perl being my personal nemesis. The advantage of this approach is that you don't need to remember a long list of operators, they are simply re-interpreted in context and the re-interpretation is pretty consistent over most of the code. But, well as the adage goes: Of tastes and colors...
clauderoux 7y ago
By the way, you can easily enforce whatever interpretation you want with a cast: println(vector("i" in s));

dkersten 7y ago

I personally value clarity and this seems to obscure meaning. I'm ok with operator overloading when its super clear (eg + is addition, so having it overloaded to also do vector addition is clear to me, but overloading it to do string concatenation is less clear). I guess my worry is that this adds unnecessary cognitive load for minor convenience. Having said that, if it works for you, awesome. Don't let me tell you otherwise, not everything has to be to my taste, after all.