Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Pyret: A new programming language from the creators of Racket

pyret.org

Post reply on HN
Print view View original

141–150 of 288 posts

Re: Pyret: A new programming language from the creators of Racket

#141

Post by jdnier »

> Most “scripting” languages don't support annotations for checking parameters and return values

PEP 3107 introduced function annotations to Python 3. The following syntax is valid:

    >>> def square(n: int) -> int:
    ...     return n * n
    ...
    >>> square(3)
    9
Nothing is done with annotations by default. Here's an article discussing this "unused feature": http://ceronman.com/2013/03/12/a-powerful-unused-feature-of-...

Re: Pyret: A new programming language from the creators of Racket

#143

Post by skrishnamurthi »

jdnier wrote: post #141

> Most “scripting” languages don't support annotations for checking parameters and return values PEP 3107 introduced function annotations to Python 3. The following syntax is valid: >>> def square(n: int) -> int: ... return n * n ... >>> square(3) 9 Nothing is done with annotations by default. Here's an article discussing this "unused feature": http://ceronman.com/2013/03/12/a-powerful-unused-feature-of-...

Unless I'm missing something, all the examples in that PEP are first-order. There's no discussion of what the semantics is in the higher-order case. Pyret's annotations are perfectly well-defined and draw on a long history of research of getting these very subtle cases right (starting with Findler and Felleisen's ICFP 2002 paper). There's much more to this than just syntax.

Re: Pyret: A new programming language from the creators of Racket

#144

Post by e12e »

ash wrote: post #28
6ren wrote: post #16

Earlier quoted context omitted.

It clutters the code. Tests are a form of documentation, but too much in the code, like too many comments, obscures. Higher level unit tests (acceptance tests) can be quite long, especially if there's a lot of setup - unlike their example code. Literate programming tried embedded documentation, but didn't catch on (even with Knuth's backing). Embedding tests makes them easier to keep in sync, but tests are already ke…

> Literate programming… didn't catch on I would argue literate programming is experiencing a renaissance, thanks to docco: https://github.com/jashkenas/docco

I think literate coffeescript might be a better example of popularizing literate programming:

http://ashkenas.com/literate-coffeescript/

There also seems to be some traction for literate Haskell:

http://www.haskell.org/haskellwiki/Literate_programming

I experimented a bit with literate programming on an introductory course in programming using java. It's an interesting experience -- it's very easy to produce a very readable language that is still pretty poor java code, as it becomes so easy to split out fragments and "procedures", rather than follow the more common java class-oriented object orientated way of doing things.

Re: Pyret: A new programming language from the creators of Racket

#145

Post by e12e »

jpolitz wrote: post #93
tinco wrote: post #6

Why the superfluous syntax? I think remembering syntax like this is orthogonal to the goal of being easy to learn. The syntax is basically Ruby + Python + Haskell. Each of those languages has a lighter, more intuitive and memorable syntax. Why would the syntax be: data BinTree: | leaf | node(value, left, right) end Instead of just data BinTree = leaf | node(value, left, right) The whole colon thing in Python is a mis…

You can actually use ";" as an alias for "end" in Pyret, so you could write: data BinTree: | leaf | node(value, left, right); We use "end" or ";" in order to have unambiguous delimiters for the ends of syntactic forms and avoid needing to depend on whitespace (we added some discussion on pyret.org about our philosophy on indentation and why we don't want to depend on whitespace). Making that leading pipe optional is…

I realize it's a trade-off -- but I think having ";" as an alias for "end" (or vice-versa) is a pretty bad idea. I personally prefers python's indentation-for-blocks syntax, but I understand why you want semantics to be decoupled from indentation. But when using explicit end-markers, I'd prefer to match them to the start, maybe even introducing some verboseness, like: end-case, end-if etc -- maybe taking it further and allow/demand naming of blocks:

    check:
      4 + 5 is 9
      1 / 3 is 2 / 6
      9 - 3 is 6
      5 > 4 is true
    end
Then becomes, not wrapped in end-check, but:

    check(arithmethic-test):
      4 + 5 is 9
      1 / 3 is 2 / 6
      9 - 3 is 6
      5 > 4 is true
    end(arithmethic-test)
Or something similiar. This makes mis-matching "end"s (either typos or artifacts from cut'n'paste coding) explicit errors that are easy to spot, and identify.

It would add a lot of verbosity, of course. As for ";"/"end", consider (the presumably valid):

    check:
      4 + 5 is 9
      1 / 3 is 2 / 6
      9 - 3 is 6
      5 > 4 is true
    ;
That trailing ";" is going to trip someone up. Also consider (cut'n'paste-with-quick-edit):

    check:
      4 + 5 is 9
      1 / 3 is 2 / 6;
      9 - 3 is 6
      5 > 4 is true;
    end
Is this valid?

Re: Pyret: A new programming language from the creators of Racket

#146

Post by seanmcdirmid »

6ren wrote: post #16
terhechte wrote: post #3

"""Pyret makes testing a natural part of the programming process. Functions can end in a where: clause that holds unit tests for the function. These assertions are checked dynamically.""" Fantastic idea! I'll keep that in mind, should be fairly easy to extend Lisps or other AST-Macro enabled languages (Elixir, Julia, Python) with such a functionality. I really like that. It makes it easy to work on a function and cod…

It clutters the code. Tests are a form of documentation, but too much in the code, like too many comments, obscures. Higher level unit tests (acceptance tests) can be quite long, especially if there's a lot of setup - unlike their example code. Literate programming tried embedded documentation, but didn't catch on (even with Knuth's backing). Embedding tests makes them easier to keep in sync, but tests are already ke…

> It clutters the code.

Modern IDEs/code editors can support code folding as well as projections fairly easily. I don't see a problem.

Re: Pyret: A new programming language from the creators of Racket

#147

Post by skrishnamurthi »

akkartik wrote: post #106
skrishnamurthi wrote: post #80

Earlier quoted context omitted.

Everything is fixable in a new language (-:. Say more!

One of my favorite things about tests is that they let me read a new codebase more interactively. If I don't understand why a function is built like this and not that I can rewrite it the new way, run the tests. Without names I'd know I broke something, but with a good name I'll often realize why that something matters in the big picture. (I think about tests a lot: http://akkartik.name/post/tracing-tests )

I understand your point. One thing I pushed for initially, dropped because we had bigger fish to fry, and will revisit later, is the idea that you should be able to name everything: not just tests but an individual variant in your data definition, lines of code, etc. And this should be intrinsic to the language.

That said, I couldn't see what your post had to do with this concept; if I've missed something, please explain. (As an aside, I believe this -- http://cs.brown.edu/~sk/Publications/Papers/Published/mcskr-... -- generalizes the idea in your tracing post.)

Re: Pyret: A new programming language from the creators of Racket

#148

Post by e12e »

skrishnamurthi wrote: post #137
clhodapp wrote: post #115

Earlier quoted context omitted.

Lines really aren't much of a thing: they are a single keypress, which generates a newline character and some autogenerated indentation from your editor. There's no real difficulty in breaking things up across two lines versus typing any other extra character (this touches on another issue, which is that I am of the opinion that the concept of code brevity estimation by line count comparison is fundamentally flawed,…

From the very beginning we have debated whether or not to make the initial stick optional. We wanted at least a semester of code to review before we made a decision. I personally lean toward making it optional and just have to persuade the others (-:. With that, you would be able to write data Color: Red | Black | Green; We did also initially discuss using = instead of : in places where we were defining things (funct…

Please don't use equal for assignment, unless you do something along the lines of prolog etc:

    (a, 2a) = (1, b)
    > b == 2

Re: Pyret: A new programming language from the creators of Racket

#149

Post by skrishnamurthi »

tbenst wrote: post #86

I took CS019 with Shriram a few years back and immediately guessed the authors based on paradigms like making testing a natural part of the language and the encouragement to use annotations. In the class, we were taught a design process for Racket that will work very well for Pyret: 1. Identify the data - create data definitions (You are gixen x and expected to produce y) 2. Write concrete examples of the data (This…

Well done, T.B.! The same idea applies to recursive data in any language; you'd use exactly this to write a tree-walker in Java, for instance. And likewise in Racket. E.g.:

  fun f(l :: List):
    cases (List) l:
      | empty => ...
      | link(f, r) => ... f ... f(r) ...
    end
  end
Note that because you can put type annotations in the cases statement, you can remind yourself of the type of the locals:

  fun f(l :: List):
    cases (List) l:
      | empty => ...
      | link(f :: T, r :: List) => ... f ... f(r) ...
    end
  end
which further nudges you towards a possibly recursive solution.

Re: Pyret: A new programming language from the creators of Racket

#150

Post by acjohnson55 »

clarkevans wrote: post #8
tinco wrote: post #6

Why the superfluous syntax? I think remembering syntax like this is orthogonal to the goal of being easy to learn. The syntax is basically Ruby + Python + Haskell. Each of those languages has a lighter, more intuitive and memorable syntax. Why would the syntax be: data BinTree: | leaf | node(value, left, right) end Instead of just data BinTree = leaf | node(value, left, right) The whole colon thing in Python is a mis…

I think the colon isn't a mistake, it clearly delineates an indented block; I think it's a great marker that indented languages might want to standardize on. Perhaps syntax issue is that it has both a colon and an "end" marker? The former indicates indentation-based syntax, the latter is often used in white-space agnostic contexts. The result of using both is confusion.

But if indentation matters, and it's pressent, then why do you need the colon?
Post reply on HN