Hacker News Reader

Comment by evincarofautumn | Hacker News Reader

Some curious things about the language:

• All operators have equal precedence, so parentheses are required when mixing operators. I guess they’ve seen one too many bugs from precedence confusion.

• It doesn’t have dependent types; rather, it uses a proof checker with some built-in knowledge about the language, and a way to specify preconditions, postconditions, and invariants that the checker can reason about.

• There is limited effect typing: functions can be marked pure, impure (!), or impure coroutine (?).

• There doesn’t appear to be any kind of polymorphism—over types, effects, refinements, or proofs.

View on HN

> I guess they’ve seen one too many bugs from precedence confusion.

Yep. I just filed a precedence bug at https://github.com/jbangert/nail/issues/7 for Nail, which is a security-concious project. (It was presented at LangSec 2014).

> It doesn’t have dependent types.

Yep. Programming language theorists love type systems, and dependent types are one way to prove bounds safety, but they're not the only way. Puffs is an imperative language, not functional (for the reasons described in https://github.com/google/puffs/blob/master/doc/related-work...). With mutable state, a Puffs variable's within-bounds-ness can change over that variable's lifetime, but its type does not.

> There is limited effect typing: functions can be marked pure, impure (!), or impure coroutine (?).

Yep. That's the current design, although I'll probably revise that based on recent experience. The question mark denotes a coroutine, as you noted, but also whether that function can (very roughly speaking) throw an exception. I think we will need separate syntaxes for those two concepts, since I've wanted the latter without the former.

> There doesn’t appear to be any kind of polymorphism—over types, effects, refinements, or proofs.

Yep. Haven't needed it yet, and I've erred on the side of simplicity and leaving things out.

> All operators have equal precedence, so parentheses are required when mixing operators.

Doesn't that mean it rejects precedence? In a language equal precedence (e.g. Smalltalk), operators would just be executed from LTR or RTL.

I agree, although I suppose different operators could still have different associativity in a language without precedence. I took that phrasing from the “Puffs the Language” documentation.

> I suppose different operators could still have different associativity in a language without precedence

That… is true, and I have a hard time computing how it would even work.

Think exponentiation, where 2^3^4 might be 2^(3^4), but where subtraction 2-3-4 is (2-3)-4.

Consider:

  2-3^4

Since there is no precedence in this (hypothetical) language that would be an invalid expression.

One way to do it would be to have a default associativity between different operators, but chains of the same operator can override it, e.g. suppose “⧺” means concatenation (rightward), “×” means repetition (leftward), and the default is leftward:

      [1, 2] ⧺  [3, 4] ⧺ [5, 6]   × 2  × 3
    (([1, 2] ⧺ ([3, 4] ⧺ [5, 6])) × 2) × 3

    [ [ [1…6], [1…6] ],
      [ [1…6], [1…6] ],
      [ [1…6], [1…6] ] ]

I dunno how good an idea that would be in practice, though.

What I mean is that you can't write "2 + 3 * 4", not even with implicit LTR, you have to write either "(2 + 3) * 4" or "2 + (3 * 4)".

See e.g the "precedence bug" comment I wrote elsewhere on this page.

My point is that's not "equal precedence". Smalltalk has equal precedence, "2 + 3 * 4" parses as "(2 + 3) * 4". If you reject the expression entirely you don't have equal precedences, you have unmixable operators or precedences (the latter being if "2 + 3 - 4" is still allowed).

OK, I'll change the wording. Thanks.

The best way to solve precedence confusion (IMHO) is to have your IDE show you how the expression is going to get parsed. Possible ways to achieve this include highlighting subexpressions, underlines, light-colored parenthesis, showing a tree, etc. This could be done only on mouse-over to not burden the overall UI.

An aside: I'm writing a toy language without operator-specific precedence and it's surprisingly readable. One trick is to treat expressions without spaces (a+b) as higher precedence than expressions with spaces (a + b). This is enough to write many formulas in an intuitive way, with few parentheses.

> "All operators have equal precedence, so parentheses are required..."

Just to play devil's advocate (aka be annoying); parentheses are operators.

Ref: https://softwareengineering.stackexchange.com/a/208354/69247

I don't find that link convincing. For one thing, the premise is assumed in the question. Secondly, when it says "they also include ()[] as operators" is implies it is talking about language-specific terminology rather than a general term.

WP describes: https://en.wikipedia.org/wiki/Operator_(computer_programming...

> Occasionally parts of a language may be described as "matchfix" or "circumfix" operators, either to simplify the language's description or implementation.

Bu then, the term "operator" seems to also have mathematical roots: https://en.wikipedia.org/wiki/Operator_(mathematics)

The relevant part seems to be the definition refering to syntax, or denotation:

> Operator is also used for denoting the symbol of a mathematical operation. This is related with the meaning of "operator" in computer programming

Now, whether "the symbol" implies a singular symbol, and excludes delimiter symbols might be a matter of semantics ;-)

A devil's advocate is not an annoying person but someone who argues against something he truly believes in or hopes to be true in order to provide a debate and help prove the point in stronger ways and show onlookers that contrary opinions were considered.

It comes from canonization process in Vatican where someone (who is not an actual satan worshiper or against the church) argued in favor of the devil (against the candidate) to force the other pro-sainthood side to provide good solid proof of the sainthood, miracles done, etc. of the candidate.

What you're doing is just being annoying by nitpicking the casual wording. There is no debate to be had from "parentheses are kinda operators" and the meaning of the original line was understandable, even if you consider parentheses operators.

Reply on news.ycombinator.com