To be fair, this sort of situation, where you have to surround an operator with spaces to ensure correct parsing, is not that unusual. Which is not to say I think it's okay. It's ugly and tricky and should be a last resort. And I don't think it's usually necessary. The operators should be chosen to avoid ambiguity (usually - I don't mind in the case of unary minus, for instance*). For some languages, that might not be so easy (eg., Haskell, which has a shitload of operators, including arbitrary user-defined ones, plus a number of other uses of non-alphanumeric characters), but most languages only use modest number of operators and have every non-alphanumeric character except underscore available (for operators and other syntax), so there's really no excuse.
So I don't like <- as an operator in a typical language. But if assignment were a statement
, I think it would work a lot better to require spaces around it. In that you wouldn't have (for example) an assignment parenthesized in the middle of a complex expression, where you might want to write it compactly. Plus, I find it less offensive to special-case a statement than an operator.* Unless the language has an extremely regular syntax that needs to be preserved, eg. J, which uses _ as the negative sign in numeric literals
troyp wrote:That's a somewhat persuasive argument, although I do think it's specific to C-like languages.
I don't agree here. I think other languages minimize the impact of = and == through means such as preventing assignments in conditions, but in a bit hyperbolic fashion I'd say that all they're doing is hiding the bad decision -- treating the symptom rather than the disease. (Of course, you might want to prohibit assignment in conditions for other reasons than "it's easy to accidentally put it there", so it'd also be reasonable to fix both problems.)
It depends on "assignment instead of equality" being a potentially trickier bug to find than vice versa (after all, a novice programmer is just as used to using = for assignment as for equality).
I disagree with this statement. I'll say more about this later, but personally I think that the only significant place where you'd have people committing the opposite bug is when they're coming from current languages that use = for assignment. (It's for this reason that I say I might go with Yakk's idea of := and == if I were to design a language, though I'm not sure. Like assignments in conditions, it would also be possible to mostly prevent the opposite bug through other syntactic restrictions, e.g. making a top-level expression a == b
syntactically invalid. Unlike assignments in conditions, I would hyperbolically say that this decision is hiding the bad decisions made in other
languages rather than this one.
I have to admit, I didn't really question my assumptions about this. Considering more carefully, I'm inclined to agree with you, and your observation that we're used to = as equality from arithmetic from a young age, well before we encounter algebra, adds further weight to the argument.
Second, statements like let x = x + 1 I suspect are very rare within formal maths. At least in my experience, you'd see either (1) a new variable, (2) no "assignment" used and just x+1 in the future, or (3) in an iterated context, a subscripted version of x a la let xi+1 = xi + 1. My impression is that programming-style assignment where you change the value of an existing variable is seen as bad form.
I accept this as an argument that = as assignment is unintuitive, but I don't think it detracts from my claim that assignment is basically the imperative mood of equality.
I think the reason you don't see this sort of statement in math is just that math is usually based on a declarative approach, whereas reassignment is inherently imperative (in PL terms now, not just grammatical*). In that sense, math is more like FPLs, which don't permit reassignment either (unless you count rebinding a variable, which math does too). When math does need to describe things imperatively, it either (1) uses natural language, possibly augmented with bits of declarative math (classical description of algorithms), (2) uses pseudocode or an actual PL (modern description of algorithms) or (3) convert the imperative description into declarative form (simple cases, like converting a loop into recursive sequence).* There is clearly a strong similarity between the imperative/declarative distinction in programming and the imperative/indicative distinction in grammar. You could claim that in a declarative approach you don't really have statements that are grammatically imperative: that declarative assignment is not really setting a variable, but rather asserting the truth of an equality. That's true in some sense, but the fact remains that you're still "setting" or "fixing" something. An assignment is not a statement of what is already true, nor a question. It is instructing the system to make something true. So I'd say that assignment in declarative programming is grammatically imperative. Which is unfortunate, terminologically - hence this footnote to clarify.
Urghh! It looks like an identity matrix or something. I'm starting to think you're not as attached to your single-letter variables as I am
But even if I was, I'd never use I
as a variable name -- it starts with upper-case.
Although I usually reserve initial uppercase for things like classes, I'm (slightly reluctantly) willing to except single-letter identifiers. It's not like I usually want a single letter class name anyway. Of course, that decision depends on several things, most of all whether the language will even allow
me to use a capitalized identifier for a variable.General thoughts on operator naming and syntax and the need for standardized transformations:
I mentioned above, that it would be nice if editors/IDEs would substitute unicode symbols for things like !=. I'd go further and say it would be awesome if there was some kind of standard markup language for specifying stylistic variants of a language. It would (a) control transformation of a programmer's input into valid source code; and (b) control the display of source code, like a CSS for PLs.
The input transformation part would be a some kind of simple source code transformation system. Nothing sophisticated, that you'd use for metaprogramming or code generation; it would just permit simple cosmetic changes that could be used to create stylistic variants. Things like changing unpopular operators, converting between significant indentation and braces, "literate" syntax, etc.
In many cases the output transformations would just be the inverse of the input transformations, but there could be differences, eg. "snippet"-like capabilities could be added, where you type an abbreviation and see the full text appear. Beyond the core capabilities, there would be additional possibilities for output beyond plain text. eg. substituting images for certain operators, or enclosing block comments in coloured boxes. There could be additional "plugins": composable transformations that could be applied afterwards for custom output, like an output transformation to produce HTML output displaying the source with syntax highlighting.
There would be a standard tool, like a macro processor, to handle the textual transformations, and additional tools for other kinds of outputs. Editors/IDEs could make use of these or implement the functionality themselves. Ideally, they would all support the text transforms and offer varying support for graphical and other output. Each tool would have it's own approach for handling integration and user interaction. Some may perform transformations when you press a button, others on the fly, with support for highlighting graphical output and having the textual source copied to clipboard. And so on.
I think some sort of system like this would really help to provide both languages and tools with some basic flexibility they could take for granted, without having to worry about decisions that should be trivial and in the user's hands. So if := and == are least confusing for assignment and equality, you could just use them, and people who want the easier-to-type = could just use the trivial =-to-:= stylesheet. Similarly with Python3 deprecating <> for inequality. We'd still have these sort of debates on forums, but hopefully they could stay off development mailing lists, at least.