EngineerJoe posted:

Super interesting thread. It's neat to see the thought that goes into designing a language that will be as important as Swift. My question is will we be able to get the string representation of enums?

Doh004 posted:

I think he was trying to be nice by not revealing what her heard because, as rjmccall had mentioned earlier, they try to keep their non released names quiet?

rjmccall posted:

I have spent an amusing amount of time talking about making a monad protocol recently.

I don't understand how your C# example works. It looks to me like it both (1) shouldn't type-check because you're not applying the same number of arguments consistently to your protocol and (2) erases the concrete monad type across bind.

Monad is an example of a higher-kinded protocol: the thing that conforms to the protocol is not a type, it's a type function (generally, an unapplied generic type). That's feasible to add as a feature, but seeing as, frankly, the only use I've ever seen for that even in Haskell is Monad, it is not something we are going to fall over ourselves rushing into the language.

rjmccall posted:

ultramiraculous posted:

http://www.jessesquires.com/apples-to-apples-part-two/

drat, ladies. Things are getting Swift!

rjmccall posted:

Basically, three reasons. (Also, in this particular case the "you" is specific: this is primarily my design.)

Code proximity is the first. In the common case where a cleanup is mandated by some specific action, you can immediately see that the cleanup is necessary instead of having to carefully analyze the rest of the control flow from that point. Now, this advantage is in inherent tension with code sequencing, because defer makes the compiler inject implicit code along exits from the scope, whereas finally appears in its proper order if you think of the jump as passing through the finally block. However, that's a bit of a leap, and I don't think it matches the way most programmers really think about it, at least not for jumps other than fall-through (e.g. return); they just think of the finally block executing, rather than thinking specifically about control flowing forward in the program. And that's fair, because finally is still pretty magical; the only code structure that's really 100% faithful to the execution flow is crappy, error-prone code duplication.

The second is that try/finally doesn't really get the scoping right. Suppose you create something, and you want to make sure it gets destroyed. In the common acquire/release pattern, there's often a variable whose scope should exactly match the lifetime of the resource. try introduces a scope, but you can't declare the variable in it, because it's out of scope in the finally and because you don't actually want to release if there was an error during acquisition. So you declare the variable outside the scope, which breaks the property we want. You could use a C#-like using feature instead, but then the cleanup is no longer ad hoc (you have to make a disposable type) and it's not always a clean fit; that doesn't mean we for-sure will never add that feature, but it's not as core as defer.

The third is that finally doesn't really compose very well. defer actions just pile up as statements in a single scope, but finally blocks have to be nested — either that, or you have to hoist variables and conditionalize the logic in the finally, and potentially even add more finally blocks there.

quote:

Does someone have a pet NLP project they want to incorporate into a compiler?

rjmccall posted:

It's a bug in the lexing of hex literals. The problem is that there is a floating-point hex literal format, and what follows the dot is, in fact, more hex digits; so we're slurping up the '.' and the 'a' and then failing to backtrack correctly when we see the 's'.