I have no idea what "a military conflict between what would become Western Canada and what used to be Upper Canada" refers to unless you meant the northwest and Red River rebellions, in which case it really stretches my (anglo) mind how that has more to do with Quebec separatism than any of the other grievances.
Chinese characters being unsuitable for QWERTY typewriters and early computers' limitations didn't "almost kill character-based Chinese", it just meant Chinese computing lagged behind. Inputing Chinese characters with a limited key set wasn't even conceptually novel, given the long history of structural decomposition and phonetic representation of Chinese characters, but it just couldn't be implemented before computers were powerful enough.
It is a fact that Mao supported romanization. <https://np.reddit.com/r/todayilearned/comments/54ky8m/til_th...> Presumably, had the PRC switched decades ago, no doubt Taiwan would today cite its sticking with the traditional written language as yet more proof of it being the "real" China, while the PRC would no doubt point to the millions of illiterates who were taught to read in the Western alphabet as proof of the superiority of its approach. (And vice versa, of course, had Taiwan been the one that chose to romanize.)
I think "countably infinite" makes no sense to you because you have a different idea of countable than a mathematician (disclaimer: not a mathematician).
A mathematician compares the size of two sets of stuff by pairing off items from each set, but this is not a mechanical process taking a finite or even unbounded amount of time: they just need to show such a mapping exists or that nonexistence would lead to a contradiction; they don't need to actually carry out the process mechanically. By definition (according to mathematicians), something is countable if it is the same size as the set of natural numbers {0, 1, 2, ...} or smaller, and "countably infinite" just means it is the same size as the naturals (and not smaller, which would make it finite).
A small minority of mathematicians hold the position that proof-by-contradiction is not good enough, and that you really do need to positively prove something. They are called intuitionists.
Presumably, an even smaller minority of mathematicians hold the position that this proof must (theoretically) be able to be carried out in a mechanical manner. They're some flavor of constructivists, but maybe they're better called programmers. <- This is where you are.
Even assuming that works, getting it to make its whole way through your whole tech stack is no easier (and more HTML-specific) than having spans with their own encoding.
This isn't about multiple encodings, this is about the one encoding, UTF-8, being able to represent multiple languages. Which is mostly can, except for han characters.
In my reply here, I can type in english and russian at once. Привет, мир.
Yet, if I try to type chinese on one line, and japanese on the next, I cannot do it. Hacker news does not let me enter "lang" tags, so I can only type either the chinese or the japanese variant of a kanji.
so yes it is about pages with multiple encodings. A span's smaller than a page!
The Unicode answer is "variation selectors" which are used for some historical variant kanji, but not for whole language switching. I suppose they could be used for that too though.
I don't know about HTML specifically; I meant spans as a general concept rather than a literal <span> tag. If the web stack has actually implemented mixing languages on the same page to the point where you can use it in a "normal" application then that's very cool (and if they've done it with their lang tags rather than by allowing mixed encodings, well, fine), but I've yet to see a site that actually has that up and running.
I can't read it, but there will be hundreds of articles on Japanese Wikipedia covering Chinese literature etc that have text in both languages, all in Unicode.
<html lang="ja">
Japanese text ...
<span lang="zh">
Chinese quote
</span>
...
</html>
is much easier than mixing encodings. With the above entirely in Unicode, it will be handled reliably by anything that can handle Unicode, and is still reasonably readable even if the Chinese text is shown in a Japanese font. Reading just the fourth line without the third will still show something 'OK'.
> if I have a good match where I did better than expected, the system responds to that by putting me in a much harder game, where I'm expected to lose
No, the system puts you in an easier/harder game, where you're expected to play _with and against_ people of your skill level (including if you want to play strictly meta or if you want to play with only one hand or whatever).
I've been playing one of the most popular (for PC anyway) online game for 10+ years now and it only has skill-based matchmaking, in both ranked and casual mode. While plenty of people rail against the fairness of its matchmaking, I've rarely heard anything against the concept of skill-based matchmaking. It's the only kind of matchmaking that makes any sense to me. Why would I want to play against people that are way better/worse than me where I have no chance to have a good game either way?
While my friends no longer play it regularly, when they used to play we'd just... play however we wanted in casual mode. Why does it matter if some people are better/worse or meta/casual? You can play the most random stuff you want and you eventually get matched against people of your skill level. Or if you don't enjoy the current match for whatever reason (winning/losing too much, or trying too much/little), just go next and let matchmaking do its thing until you get games at your level, wherever that level happens to be.
If anything, your complaints sound to me like the developers care too little (rather than too much) about competitive balance/integrity across the entire playerbase.
The way this used to get solved, was that people hosted servers, and there was always an empty one lying around for people who wanted to play with their own group, or you could just go figure out if you liked the particular server community or not.
Then game companies took total control, made you play on their servers and introduced all these problems.
> when they used to play we'd just... play however we wanted in casual mode.
Well, when you're on a 5-person team on Counterstrike and your fifth player doesn't want to buy guns and even try to complete the objective, they just want to run around and knife chickens and hide in corners the whole game, it can be a little frustrating to the other 4 players.
Like, I get its casual, and you shouldn't necessarily expect everyone to always try as hard as they possibly can to win, but when one person not even trying to do the objective of the game it sours the experience for the other four.
But this is kind of true of any team-based game. Imagine playing Spades or Rummy where your teammate is just always purposefully playing junk and never even trying to play their hand properly. Or a baseball game where whenever the second baseman gets the ball he just throws it up in the air to himself and never bothers to get the runner out. Or baseketball where one person on the team just wants to try and spin the ball on their finger instead of playing the game. If you're trying to actually play the game, its going to be frustrating having a player like that on your team.
In causal its definitely forgivable to make mistakes and try something different, but if you're just in a casual match to sniff the proverbial flowers in the game you end up ruining the experience for your teammates. Ultimately in a team based match-made game all players really should at least try and observe the objectives of the match to some level, at least in my opinion.
If it's +(1 2 3) then the language is no longer homoiconic and you will lose the primary leverage of being a Lisp. The fact that Lisp code consists entirely of Lisp data literals (code as data) is what enables Lisp macros and the superior REPL experience.
Can you elaborate what about +(1 2 3) makes it not homoiconic? Isn't it trivial for a hypothetical Lisp implementation to treat +(1 2 3) as the list [+, 1, 2, 3]?
Not sure if I am missing something. This is an honest question.
First of all, that place is where the reader macros go, so the spot is already taken.
Second of all, notwithstanding interference with reader macros, then no, it isn't completely trivial unless what you're suggesting is just pointless string substitution, which would also make e.g. 1(2 3) be equal to (1 2 3).
If what you're suggesting is having an enforced hard split between lists and function/macro invocation, that pretty much just makes everything harder to do with no perceivable gain, other than looking a bit more like C-based languages. It's a bit like enforcing that any strings that are parsed as numbers somewhere in the source code must be defined using "..." while strings that aren't must use '...' instead.
The entire point is that you can manipulate code as data structures. You can rewrite the rules of the language by returning data structures. There's no reason to make this more complex.
Homoiconicity in Lisp means that it is written on top of the data syntax.
Sure you can put other parsers in front, which might just convert a different notation into Lisp data. The difference is then, that the primitive datastructure itself has a different syntax. In Lisp we use the syntax of the primitive data notation (-> s-expressions) to encode both data AND code.
Try replacing the + with a more complicated expression. ((if t + -) 1 2 3) and (if t + -) (1 2 3). In your notation it is much harder to determine which expressions are intended to be evaluated.
(+ 1 2 3) vs +(1 2 3) is just a small syntactic difference and has no bearing on whether the language is homo-iconic or not. The translation from code to data is equally trivial for both syntaxes.
is a data structure, which knows nothing about Lisp. It's just a nested list.
paris(berlin london)
does not make any sense as a list of symbols. Why is paris written outside of the list?
Lisp chooses to write programs as nested lists of symbols.
If you start to define a specific syntax which violates the simple syntax for nested lists, then the code is no longer read by reading a simple data expression.
I think you're wrong if (+ 2 3) means apply the + function with the 2 3 arguments then
(Paris Berlin London) means apply the Paris function with the Berlin London arguments..
AFAIK if you want a list either you use (list a b c) or you use '(a b c)
which I find less regular than +(1 2) or (1 2) which is equal to list(1 2)
Often, it will be interpreted to be a function call or a macro invocation in the eval step (the E in REPL).
You can sidestep this behaviour using the ' reader macro (i.e. quote) as you mentioned yourself. Quoting disables this behaviour for the form that the reader macro applies to. Reader macros occur in the R step (i.e. before the E in REPL).
It is a list data structure. There are many examples of lists which are never interpreted as function calls in Lisp, since macros run before evaluation and can change the default behaviour, e.g. in
(defun increment (x) (+ x 1))
the (x) is not a function invocation, it's a list of named function parameters.
Remember: the specific feature of a typical Lisp is that it is written as s-expressions. S-expressions are a notation for data (similar to XML, JSON, ...). This notation is independently useful for all kinds of purposes - like a list of city names: (paris berlin london).
But the specific feature of Lisp is this: code is data and data can be code. Some use the word homocionic -> the program is written in its own data syntax. S-expressions are the data syntax used by Lisp and the programs are written as s-expressions.
> (+ 2 3) means apply the + function with the 2 3 arguments
Depending on the context (a b c) can have different meanings.
As a list it is a list of three items. As a top-level item it is a function call. In (let (a b c) ...) it means a list of variables.
Lisp is based on s-expressions. S-expressions is a simple syntax for data:
an symbolic expression is:
a symbol: foo, bar, 1, 2 paris, +, -, delta, bear, G1345
an empty list: NIL or ()
a non-empty list: ( s-expressionn1 ... s-expression-n)
That's basically it.
Lisp has three functions to work with those: READ, PRINT and EVAL. READ reads a textual s-expression to data, PRINT takes data and prints it as an s-expression, EVAL takes data and evaluates it.
Thus the toplevel of Lisp is something like
(loop (print (eval (read))))
It reads a Lisp expression in form of an s-expression, evaluates it and prints the result.
> AFAIK if you want a list either you use (list a b c) or you use '(a b c) which I find less regular than +(1 2) or (1 2) which is equal to list(1 2)
(a b c) is a list. It's an s-expression. It is valid data. It's only valid Lisp, if A is an operator.
(quote (a b c)) is also a nested list AND a valid Lisp program.
But READ reads all kinds of nested lists, not just Lisp programs. It does that, because S-expressions are a general data syntax.
Compare that with most other programming languages. Their programs are not written on top of a general data-structure notation like nested lists, nested vectors, nested tables, ...
No, the real reason you want (f x y) rather than f(x y) is so you can parse it with no lookahead.
It is actually possible to extend Lisp's syntax to allow f(x y) using the hack that if there is no whitespace between a symbol and an open-paren then treat that like a function call, i.e. you can tweak the Lisp parser so that:
(list f(x y) f (x y))
will read as
(list (f x y) f (x y))
and so kinda sorta do the Right Thing if you like traditional function call syntax. But that is pretty hacky and fragile.
Even with lookahead, it seems like there are ambiguous cases. I think the "hacky and fragile" level is so high, that it rises to a level of "practically required" to avoid ambiguity. (In the sense of "if John McCarthy had proposed it the other way in an early draft, it would have been peer reviewed out before the first implementation.")
In a sequence of expressions, how would I [or the computer] know how to evaluate the following
g (a b) h (c d)
If g (a b) returns a function f and h (c d) returns a value v, should the result of that evaluation be v or f(v)?
Does our intuition change if I write it as:
g (a b)
h (c d)
If the default is for the result to be v, and I do want it to be f(v), it's not obvious to me how to re-write it, whereas it's obvious if the first element in a list is a function call:
Because parsing +(1 2 3) requires lookahead. You want to be able to type X into a REPL and get back the value of X, but you can't do that if there is a possibility that an open paren after the X will change its semantics into a function call.
Also, what should be the result of:
(defvar f ...)
(defun f (x) ...)
(length (list f (g x) f(g x)))
?
>someone outside of politics [...] holds the final red line about whether or not an election must be called
This seems like only a theoretical red line. If/when the GG does anything against the advice of the PM it's a crisis moment. There was a bit of a media fuss in 2008 but then the GG just did as she was told, no?
The TLDR is that nothing was ever said about implied threats to sue, and it was all about "windows/virtual desktops are hard, let's _simplify_ everything!" Also, netbooks/iPhones were all the rage then, so you see where the modal design (for small screens) and giant padding (for touch input) came from in order to accommodate any possible convergence in the future or whatnot.
oh I had a typo in my original comment. I meant *without* a notebook UI. i.e. I don't want to see a cell UI like a notebook. I want it to be just a normal Python file where the output shows up in line.
I'm not aware of any schools teaching multiplication tables in kindergarten, but I did memorize the 9x9 table when I was in kindergarten because my older siblings' Big Kids Notebooks all had the times table on the back and it formed a rhyme/ditty in the local language. After it was explained to me that multiplication was repeated addition, that made perfect sense.
But don't ask me about division, my siblings/parents/whoever tried to explain it as "the opposite of multiplication", which was complete nonsensical gibberish and I didn't learn division until years later.
