jnhnum1

Lost me when they got the definitions of semigroups and monoids wrong.

Semigroups are not required to have any identity, and the monoidal identity needs to be both a left and right identity.

The answer is no: every time you apply Human(), you reduce by one the number of legal moves at every given game state. After some finite number of iterations, there are no longer any legal opening moves.

Or by packing the Supreme Court...

Actually, the full title is "Things I love in Haskell that don't exist elsewhere at all"

> Completely ignore the credit collection agencies. They are utterly impotent, especially when it comes to medical debt which has no effect on your credit score.

Source? Googling for medical debt and credit score seems to indicate that it will in fact impact your credit score once they hand the bill over to a third party collections agency.

^ or me

Yes, it could be bad, but at the same time the "@case" isn't the only indicator that this class is special. A case class definition can be very visually distinct compared to a normal class.

One thing case classes let you do is implement functionality externally to a class using pattern-matching functions. When you do this, your case class definition will consist of nothing but empty class definitions:

  @case
  class List:
    class Nil():  pass
    class Cons(x, xs): pass

In any case, Python's enums will use fully qualified names, so we may change our current system for compatibility and consistency.

Yes, probably if you're starting from scratch. But I think in general it's good to have a flexible language which lets you write code in any reasonable style. Hopefully this library (the AST transformation part, not the specific macros) is making Python even more Pythonic! Although I suspect Guido would disagree with me

Other author here: Like lihaoyi said, it's true that the way we defined things doesn't match standard Python namespacing, but it saves some typing and I think it's easy to get used to the semantics of our case classes. Our macro just transforms the "namespace tree" that you would normally get from writing code like that into an "inheritance tree", where all the subclasses' names are at the level of the top class. If you wanted to do something like this with proper namespaces, you can probably do something similar without macros using metaclasses.

It looks like the API doesn't give access to the whole shape of a ship - only its centroid position and the direction of the sharpest vertex. Do the other vertices not matter? In any case, we should probably be able to compute which edge we would be splitting and stuff like that.