Replies: 12 comments 15 replies
-
|
In my opinion, doing this makes the program lose its flexibility. A successful programming language is one that is most efficient with the least variety of syntax |
Beta Was this translation helpful? Give feedback.
-
|
I appreciate you sharing your opinion and point of view on the subject. As for what constitutes a successful programming language, that would depend on what one means by successful, or rather what you're considering it to be successful at. By one way of looking at it, writing in pure machine language fits that description, and I've done quite a bit of that, but it seems not to generally catch on so I wouldn't consider that type of "programming language" to be very successful at all by that standard, but it's quite successful in the sense that all human written computer programs inevitably end up written in one machine language or another. I'm merely suggesting a way that humans could write some of their Mojo language using a form that they many people could recognize and understand without having to first learn anything specific about Mojo language. For example, most people know that × is a multiplication symbol and ÷ is a division symbol and how to use those two symbols even if they have never seen or for that matter never heard of a computer programming language. I know it's often hard for computer programmers to imagine there are such people, but there are actually quite a lot of them. It's a bit like the way many English speakers think most people speak English, but in fact it's only roughly 10% of those humans who speak any language at all. In fact, that's a generous estimate and counts people who barely speak the language. I asked Wolfram Alpha https://www.wolframalpha.com/input?i=Percentages+of+languages+spoken+worldwide for an opinion and it says 5.1%. |
Beta Was this translation helpful? Give feedback.
-
|
This is the same approach as some languages like APL. But I don't see the benefit and only drawbacks:
|
Beta Was this translation helpful? Give feedback.
-
|
I appreciate your feedback, and constructive criticism. I'll attempt to balance it with some observations of my own. I used to have excellent eyesight, actually good enough that most people wouldn't believe it's even possible, but it's not so good anymore and not good at all up close even with my reading glasses on, yet I would point out that the fewer characters it takes to represent the same thing, the larger font can be displayed and still fit the same thing on the screen. Yes, anything you can write with a single character you can write as more than one character, but by that reasoning rather than writing "z = x / y" we should be writing "z equals x divided by y" and instead of writing "z = x // y" we should be writing "z equals the floor integer of the result of x divided by y". I don't think that's preferable. My suggestion is that we should be able to write such things as "z = ⌊x ÷ y⌋" or "z = ⌈x ÷ y⌉" to get an integer division as specified or write "z, r = x ÷ y" to get a division with a remainder, or write "z = x ÷ y" to get a division without a separating out a remainder, which would be easily understood without having to know what something like divmod(x, y) means. No, an onscreen keyboard would not be the only option for getting such characters. Some programming editors could be set up to allow a person to type something the long way and let the editor shorten it for them, for example. Also, there would be no need to use such forms if you know another way of writing the same thing. It would be a choice. But what if one wants to write ⌈x ÷ y⌉ in a computer programming language and does not know how to translate that obvious form into something like math.ceil(x / y) complete with the necessary import? I think it would likely be easier for that person to copy and paste the needed characters or pick it from an onscreen keyboard so thy can continue programming rather than go looking for what is the language specific form expected by the computer programming language they have to be using. Yes, people would have to remember what such symbols do in order to understand the code they wrote. The same can be said of every function and class name, the "//" operator, the "^" operator, and so on. In fact, many programmers will see "x ^ y" and think "x to the y power" rather than "x exclusive or y". Speaking of which, since Python uses the "" operator for multiplication and the "**" operator for exponentiation, and since Unicode currently has no exponentiation symbol, it would make sense to allow "×" to be a synonym for "" and "××" to be a synonym for "". Although it is not an actual Unicode exponentiation symbol, the character "↑" is often used for that purpose in a sequence such as x+y (addition), x*y (multiplication), x↑y (exponentiation), x↑↑y (tetration), x↑↑↑y (pentation), x↑↑↑↑y (hexation) and so on. In that sense, we could say that the sequence would be: x↑y = x××y, x↑↑y = x×××y, x↑↑↑y = x××××y, x↑↑↑↑y = x×××××y) and so on, and perhaps back-translate that to allow x***y to represent a hexation operation, when someone doesn't have an easy way to type the "×" character or the "↑" character. The point is that there would be logical extensions of such things, which actually would make the language more flexible and suggest logical paths for expanding functionality. There is no logical extension to something like "divmod(x, y), but there is a logical progression for the inverse operations of the sequence of hyper-0 (counting), hyper-1 (addition), hyper-2 (multiplication), hyper-3 (exponentiation), that inverse being the one that includes the so-called “hypooperations” or “superroots”. That is, hypo-0 (counting backward), hypo-1 (subtraction), hypo-2 (division), and so on. That is, x-1, x-y, x÷y, and from there we could make the same continuation based on the form on the Python "**" operator, so make x-1, x-y, x÷y, x÷÷1, x÷÷÷y, x÷÷÷÷y, but we cannot do that with "-" because "--" pretty much means "+", and we can't do it with "/", because "//" means "/" with the fractional part thrown away. However, just as the "↑" character is commonly used for hyperoperations, the "↓" character is commonly used for hypooperations. Someone who know what "x↓↓y" means and knows what "x↓↓↓y" means would likely be able to figure out what "x↓↓↓↓y" means and even come up with it on their own without ever having encountered it. In contrast, the radical character "√", which is a standard Unicode operator symbol character, is expected to be preceeded by a superscripted number to extend it and that number is assumed to be 2 if not explicitly shown, so while one could write the square root of x as something like "√x" of "√(x)" it doesn't naturally extend to cubed roots and beyond. So I could say that "ʸ√x" is equal to "x↓y", but the form "ʸ√x" is not easily extended and not all letters have Unicode superscript or subscript counterparts, so I would NOT recommend that. However, allowing "√" to represent square root would cost next to nothing, and allowing both "÷÷" and "↓" as ways of expressing "to the root of" (hypo-operation 2) has a logical extension into other hypo-operations. I would argue that such added potential for logical extension of operations would not in fact make the language less flexible. |
Beta Was this translation helpful? Give feedback.
-
|
This is definitely something worth investigating, Swift has the ability to define custom operators, even unicode ones: That said, we're focused on building out the core language, not adding sugar in the immediate future. |
Beta Was this translation helpful? Give feedback.
-
|
Of course. I'm not trying to side-track anything. Just trying to get the community to discuss such things as a way of collectively thinking ahead. Being able to make custom operators has its advantage but, of course, then a decision has to be made whether to allow such assignments to overwrite built-in ones, and if not then will somebody's code get broken if a new built-in operator is added which conflicts with their custom one. In other words, do we want to allow someone to write their code such that "+" is used for subtraction and "-" is used for addition, or do we want to make it so that if someone uses y√x to mean ʸ√x, it would get broken if some day officially "y√x" became a built-in way of writing "y times √x". But such dilemmas are exactly why I think now is the time to get such discussions going, rather than wait until Mojo natively runs everything that Python natively runs. Does that make sense to you? I hope so, because if it doesn't, that probably means I did a crappy job of explaining it. DAK |
Beta Was this translation helpful? Give feedback.
-
From that page, here's how Swift handles which characters can or can't be used for custom operators and in what ways... If Mojo eventually adds both builtin Unicode operators (alias or otherwise) and support for custom operators, some similar solution will be needed, so it's good to look at and discuss cases like this in advance where such issues have already been addressed in one or more existing programming languages. |
Beta Was this translation helpful? Give feedback.
-
|
Maybe an editor plugin could display operators as Unicode while in reality they are written as ASCII. |
Beta Was this translation helpful? Give feedback.
-
|
This is typically done with programmer fonts with programming ligatures, plenty of those available to map characters to unicode equivalents displayed, for example see Fira Code. |
Beta Was this translation helpful? Give feedback.
-
|
That can be done, of course, but it would not accomplish what I am aiming for. Such ligatures could however be made interchangeable with the actual Unicode characters from the viewpoint of the language compiler itself, but of course, that would mean people reading code written with such ligatures but without the software which displays them as Unicode counterparts would have to learn or figure out what each ligature means. I'm not saying that's unacceptable, but rather just pointing out a fact. I appreciate the discussion and I hope it continues. Perhaps people could bring up and show some specific examples of some such ligatures that have been used in any case and what Unicode character (or characters) they might be displayed as or treated as equivalent to. |
Beta Was this translation helpful? Give feedback.
-
From the Fira Code readme file at https://github.com/tonsky/FiraCode/blob/master/README.md I would like to highlight the following quote in this context:
I agree with the statement that (Edited in an attempt to improve formatting, and to add a bit at the end) |
Beta Was this translation helpful? Give feedback.
-
|
Okay I get what you are going for. but I think the usable characters are pretty limited imo. I'm just going off APL since languages like that take full advantage of these characters and imo the following code is just completly unreadable. Also when you take a symbol in a vacuum sure You could make the argument that the paradigm of APL makes it unreadable but think the symbols stand |
Beta Was this translation helpful? Give feedback.
-
|
Yes, ALP should be a good source of inspiration. Unfortunately that language having been around slightly longer than I have very much predates Unicode and I'm not sure all of its code points made it into the Unicode standard, and of course not all of those that did will necessarily have glyphs in all fonts. Regardless, it was designed to be a very concise language which originally ran on mainframes with kilobytes of memory, not megabytes or gigabytes. Well, technically now they're supposed to be called kibibytes, but that's a long story, and not everybody goes along with it. If people choose to write difficult-to-read programs, they don't need many characters to do that. My first computer programming language was BASIC and I started using the variables "I" and "O" right away, partially because I liked the challenge of the fact that they could easily be mistaken for "1" and "0", and partially because they seemed like nice names for the index variables of outer and inner loops. It's been decades since I have written any BASIC but without looking it up I can still tell you that the first thing I tried on every new computer back then to figure out how its flavor of BASIC worked and to get a look at what it was thinking was to write something like... But of course, I could easily have used the variable names "OUTER" and "INNER" and I didn't have to write all of my line numbers as if the line numbering was in binary, and I could have used space characters where they were allowed but not required. I chose to program that way. I suspect that's what you are seeing as the paradigm of APL making program code unreadable. ...but I don't know of a way to make sure the pointer for the variable MEMORY would point to memory location 0. Of course, BASIC wasn't challenging enough but it did provide the POKE command to change a memory location, and depending on the version of BASIC a command such as SYS or USR to change the address of the execution pointer of the processer to begin executing at a specified location. For example, in ATARI BASIC it seems to me the USR function took a parameter in parentheses as a memory address to begin machine language execution and returned the value in the accumulator, so I taught myself machine language... on one computer after another, by figuring out for myself what each number did and writing my own languages to think of them in. So, I've written lots of machine language, some in pure hexadecimal, some in pure decimal, some in pure octal, and even some in pure binary, and much in some mixture of number systems, often but not always interspersed with some assembly language or macro-assembly language of my own, even before I had ever heard of an assembler or an assembly langauge, let alone knew what one was. In fact, I once lost out on a job working for Vid Kids programming arcade games because Eugene asked if I knew assembly language and I answered that I didn't know what that was... but I did not know at the time I had written my own several times already and could have easily learned whatever one he wanted me to, so we both lost out. But consider how easy or difficult it would be for most people to read program code written entirely in binary or hexadecimal. Having more characters available doesn't make the programs harder to read. It's just more to learn and more options once it's learned. Also, regardless of whether a particular operator symbol is introduced as a synonym of some built-in function or introduced with new functionality of its own, there's no reason any of them can't have some alternative way to be represented in ASCII to provide an easy way of typing that functionality on most keyboards. |
Beta Was this translation helpful? Give feedback.
-
|
Imo, this would not be used for production. This operators is used im math, no doubts, but mojo is primary is It's not really comfortable and everyone is getting used to write I can understand you, it's cool to see that, but it's not really practical and comfy for coding. Programming languages designed to be as close to natural language as possible :) |
Beta Was this translation helpful? Give feedback.
-
|
That's not the case for a scientist (virtual keyboard with special characters). |
Beta Was this translation helpful? Give feedback.
-
|
Yes, @elisbyberi, many people who use such characters on a regular basis already have ways of easily making use of them, because getting ways of easily making use of them had the potential to help them get much more done. No, @toiletsandpaper, (cool name, by the way), not everybody is getting used to such conventions as writing floor(x + y) rather than ⌊x + y⌋, largely because not everyone writes computer programs, but also because not all computer programming languages represent that the same way. For example, Python doesn't... unless you import something first or write something first to make it do so. If you 'import math' in Python, then assign |
Beta Was this translation helpful? Give feedback.
-
|
FWIW, this isn't something we are pursuing in the near future, we are building out the core language. :) |
Beta Was this translation helpful? Give feedback.
-
|
Yep. I know. Thanks for saying though, just the same. Now is the time for the community to discuss it. When it's time to implement it would be a bit late for starting such a discussion. |
Beta Was this translation helpful? Give feedback.
-
|
I really don't like this. What a way to make a language hard to read, extremely hard to write, and difficult to use, when it doesn't even improve it in any meaningful way and is used nowhere else. Simplicity is beneficial sometimes, and this is one of those instances. |
Beta Was this translation helpful? Give feedback.
-
|
I understand, but I would like to point out that you could have written that as "·sǝɔuɐʇsuᴉ ǝsoɥʇ ɟo ǝuo sᴉ sᴉɥʇ puɐ 'sǝɯᴉʇǝɯos lɐᴉɔᴉɟǝuǝq sᴉ ʎʇᴉɔᴉldɯᴉS ·ǝslǝ ǝɹǝɥʍou pǝsn sᴉ puɐ ʎɐʍ lnɟƃuᴉuɐǝɯ ʎuɐ uᴉ ʇᴉ ǝʌoɹdɯᴉ uǝʌǝ ʇ,usǝop ʇᴉ uǝɥʍ 'ǝsn oʇ ʇlnɔᴉɟɟᴉp puɐ 'ǝʇᴉɹʍ oʇ pɹɐɥ ʎlǝɯǝɹʇxǝ 'pɐǝɹ oʇ pɹɐɥ ǝƃɐnƃuɐl ɐ ǝʞɐɯ oʇ ʎɐʍ ɐ ʇɐɥM ·sᴉɥʇ ǝʞᴉl ʇ,uop ʎllɐǝɹ I" and yet you were not forced to simply by having that option. I learned to read upside-down as a baby, before I was old enough for anyone to tell me it was upside down, or even to suspect that I was actually reading and not just enjoying looking at pages in a book, so for me that is no more difficult to read than the way you wrote it, but if it's more difficult for you to read that way it makes sense for you not to write it that way. If you find... ...to be easier to read than If you find If you find that... ...is easier for you to read than If you find When dealing with sets, if you would rather write --- Edited to correct a typo. Probably missed several other typos I haven't edited it to fix. |
Beta Was this translation helpful? Give feedback.
-
|
Personally I need a programming language, in its entirety, to be typeable on a MacBook ASCII keyboard for it to be useful to me. I feel like a parser could handle the task of displaying |
Beta Was this translation helpful? Give feedback.
-
|
Well, if you are limited to not being able to make any use of something with features that would benefit other people, I can understand you not advocating for such features. Of course, I don't understand why you could not be able to simply leave non-ASCII characters where you find them until you need to edit that part of the code, and when you edit it, simply do what you can rather than be held back by what other people can do, but I'm guessing you have your reasons. Most likely one I can come up with is using a text reader that can't read non-ASCII characters. If that's the case, a text reader that can read Unicode characters outside of ASCII should be helpful, and a conversion program that converts a Mojo program to an all-ASCII form would probably be even more helpful. Between the two, I would think you should be able to get your usefulness out of the language in spite of having features that you would have to do without or even occasionally work around. |
Beta Was this translation helpful? Give feedback.
-
|
To add to this from another perspective since all of the comments expressing their distaste for the suggestion are met with an extended versions of "if you can't benefit from this why not anyone else". there are a few extra points I would like to make: Just like mojo is going to be a superset of python I think it should therefore carry the burden of some python philosophies, as expressed in the Zen of Python (PEP 20), advocates for simplicity and clarity. A key tenet is: "There should be one—and preferably only one—obvious way to do it." This is central to Python's ethos, and it has been instrumental in making Python one of the most loved and widely used programming languages. Most code is not written alone. When accessibility points have been brought up these have been pretty much brushed off. But just like we have code formatters that keep the line length (79 pep) (88 black) in check, we should also keep in mind the wide array of developers who will be working with this code. while it is important to explore and innovate, we must also ensure that the soul of Python is not lost in the process. We need to strike a balance between incorporating new ideas and maintaining the philosophy that has made Python so successful and widely adopted. Let's focus on ways to enhance Mojo while preserving the principles that have inspired its creation. |
Beta Was this translation helpful? Give feedback.
-
|
That is a very good point, and I thank you for sharing it. My replies are not intended to belittle anyone's point of view, but rather to respond as well as I can and encourage the discussion to continue. It is of course early for the idea my post proposes to be implemented (if ever) in Mojo, and even more early to begin making a new branch or superset of Mojo in which to include it, but people who see benefits, people who see a downside, people who see neither, and people who see both are all welcome to participate in the conversation. If I tend to be verbose, it is because I value the discussion enough to put in the time it takes to give a thorough response. If I fail to do so, it is because I either missed something completely, had little or nothing to say about it, or simply lacked the time or didn't feel I had a response that I could present well enough to be a positive contribution to the discussion. Anyway, I have more to say but I'll stop here for now and just end with this... Thanks for adding value to the conversation. I hope you and others will continue to do so because in my opinion there is much to be gained through working out the details well before a decision is made about what, if anything, to do with the possibilities discussed. |
Beta Was this translation helpful? Give feedback.
-
|
When can I use emojis as custom operators struct thing:
fn __🔥__(lhs, rhs) -> Self:
return max(0, lhs * rhs)
Print(thing1 🔥 thing2) |
Beta Was this translation helpful? Give feedback.
-
|
This is a Python Unicode issue for variable use as well:
So maybe when Python supports Unicode characters (multi-byte) in future this could be looked at. |
Beta Was this translation helpful? Give feedback.
-
|
I can't tell if I'm joking or not |
Beta Was this translation helpful? Give feedback.
-
Unicode Logical and Mathematical Operators in Mojo: A Discussion
Introduction
I'm starting this discussion to explore the potential benefits of incorporating Unicode logical and mathematical operator characters into the Mojo language. This could provide a concise, less ambiguous alternative to the existing representations and might even introduce new functionality.
Proposed Unicode Operators
Here are a few examples of the Unicode operators we could consider:
Note that in Python calling int(n+m) rounds n+m toward zero if it's not already an integer value regardless of whether n+m is negative or non-negative. In contrast, ⌈n+m⌉ would always round n+m upward when it's not already an integer value, while ⌊n+m⌋ would always round n+m downward when it's not already an integer value.
There are of course many more to be considered. A comprehensive list can be found at the Unicode charts: Mathematical Operators and Miscellaneous Technical.
Potential Use Cases
To illustrate the potential benefits, let's consider the multiplication operator. In Python, the asterisk (*) is used for multiplication. However, if we're multiplying several numbers in a Markdown formatted text, we need to escape the asterisk characters. Using the Unicode multiplication operator (×) would circumvent this problem.
Current syntax: result = 5 * 7 * 9
Proposed syntax: result = 5 × 7 × 9
Potential Issues
While there's potential for this feature, we also need to consider potential challenges. These could include compatibility issues with different systems or programming languages that Mojo might get embedded into or in some other way have to deal with, confusion with similar looking Unicode characters such as the similarity of the Unicode multiplication operator symbol "×" to the letter "x" making it possible that some people might think they could use "x" as a multiplication symbol, and the impact on the learning curve for new programmers finding more than one way of writing the same thing having been used in different programs or different parts of the same program. Perhaps programs or editor features could be constructed to find and deal with or help deal with such potential issues.
Questions and Discussion
I'd love to hear your thoughts on this proposal. Are there any other Unicode characters you think would be beneficial? What do you think of the idea of having these as alias operators, as an option for those who wish to use them? How do you think this might be best implemented to work well with potentially allowing Mojo programmers to add their own operators?
Conclusion
While I don't expect this feature to be a priority at this stage in development, it would be nice to plan ahead to allow for it. Let's discuss the potential advantages, and challenges, and how such a feature might be best implemented.
Summary and Reference Links:
I would like to encourage discussion of adding Unicode alias operators for such things as mathematical and logical operations for which there is an established unambiguous Unicode operator character or enclosing operator, such as any of ¬, ±, ×, ÷, ⁻, ∀, ∅, ∈, ∉, ∋, ∌, ∏, ∐, ∑, −, √, ∝, ∞, ∧, ∨, ∩, ∪, ∫, ∴, ∵, ∶, ∷, ≃, ≄, ≅, ≆, ≇, ≠, ≡, ≢, ≣, ≤, ≥, ⊂, ⊃, ⊄, ⊅, ⊆, ⊇, ⊈, ⊉, ⊊, ⊋, ⊨, ⊭, ⊻, ⊼, ⊽, ⌈⌉, or ⌊⌋, for example, to allow for more conciseness and less ambiguity and perhaps in some cases even to introduce new functionality. Of course, I don't expect any such thing to be a priority at this stage in development, but it would be nice to plan ahead a bit to allow for it. Many and likely most such characters can be found with their descriptive name and Unicode code point at https://unicode.org/charts/nameslist/n_2200.html and https://unicode.org/charts/nameslist/n_2300.html online.
DAK
Beta Was this translation helpful? Give feedback.
All reactions