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

221–230 of 288 posts

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

#221

Post by skrishnamurthi »

mercurial wrote: post #124
skrishnamurthi wrote: post #77

Earlier quoted context omitted.

It's actually widely used in Racket already. Yesterday a lead programmer at a major financial institution told me that he liked that style so much, he'd incorporated it into his company's OCaml system, and they use it in their production systems (lots of high-volume trading). Hardly "failure"s. Nevertheless, perhaps you could provide some pointers to the "many" projects that have tried it before? Assertions are not t…

This might work better for pure functions. I can't imagine it working very well for complex, stateful code which requires mocking and resetting the state between tests.

This is why a test block is a block. Writing inline tests for stateful functions in Racket was a bit painful because it is so heavily expression-oriented. We want to make this feel more natural.

(Another virtue of test blocks: you can write little local helper functions. There's an example of this on the Pyret home page.)

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

#222

Post by skrishnamurthi »

vidarh wrote: post #157
skrishnamurthi wrote: post #78

Earlier quoted context omitted.

Not even remotely in just about any respect.

Really? The concept of a block that specifies a contract does not sound similar to the design by contract capabilities of Eiffel. Care to enlighten us why not? Perhaps you think I was referring to something other than the quote in the comment I replied to.

Contracts are fundamentally different from tests. Contracts are abstract specifications about values while tests are concrete specifications about values. The concrete vs abstract distinction is fundamental, as I hope is clear.

That's why Pyret has both tests and contracts (for now, in the form of refinements). This is a distinction that has been explored extensively in Racket also, all fully aware of Eiffel DBC.

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

#223

Post by skrishnamurthi »

vidarh wrote: post #188
ufo wrote: post #172

Earlier quoted context omitted.

Eiffel contracts are relatively primitive compared to the more modern Racket and Pyret contracts. Eiffel contracts are basically limited to assertions and don't support contracts on higher order function arguments, refinements, etc. There is also the whole dynamic typing thing. Eiffel is still fully statically typed.

None of which changes what I wrote earlier. In terms of my opinion of Racket/Pyret, though, there's been a number of Ruby projects to do similar stuff to this over the years, since it's trivial to add (just add a class method that redefines a method and wraps it in code to execute the contracts), and a lot of Ruby newbies try to find ways of adding back the restrictions they've lost when moving from statically typed…

This "static" vs "dynamic" distinction is largely artificial. Every program has parts that make sense to think of as "static" and parts that will be very "dynamic", and the ratio of these two differs from program to program (and even within a program, from day to day).

The same goes for making statements about programs.

Therefore, in Pyret, we recognize that there are lots of different levels at which we make statements about our programs: from tests through types to specifications, spanning both static and dynamic aspects. They not only aren't in conflict, they're even related. Most languages include only a subset of them or make them appear to be disjoint. In contrast, in Pyret, we're already working on linking these to one another, and are going to keep pushing in this direction.

Languages that leave out one or more of these end up forcing users to reinvent these wheels for themselves (because they're each good ideas that people inevitably want). But by forcing people to reinvent a wheel, they end up giving users ad hoc versions of these tools, and also introduce friction between these parts. (E.g., as Robby Findler found several years ago, just about every single bolted-on DBC system had significant limitations or errors.)

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

#224

Post by colanderman »

skrishnamurthi wrote: post #214
colanderman wrote: post #199

Earlier quoted context omitted.

Why replace Racket with Pyret? Is this purely to stop students from being able to complain about syntax or is there a deeper strategic reason behind this? Refinement types are nice. I really wish those were more common.

Your second paragraph answered your first paragraph (-:. 1. We have a different view of static typing than Racket. 2. We have a different view of the type language than Racket. 3. Long term, we are working on smoothly integrating testing, types, and specification [as a spectrum -- perhaps even as a cycle -- rather than as three different things]. Refinements are an instance of this. Another is our plan for how to do…

I am also convinced that parenthetical syntax has real problems that I can't completely ignore.

What brought you to this conclusion? Experience from Bootstrap (in which I found arithmetic and parenthesis counting to be the biggest stumbling blocks) or just personal reflection?

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

#225

Post by skrishnamurthi »

alexatkeplar wrote: post #174
skrishnamurthi wrote: post #80

Earlier quoted context omitted.

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

I would like it if the `where` tests supported DataTables for a slightly more declarative style. Here's an example from Scala/Specs2: https://github.com/snowplow/snowplow/blob/master/3-enrich/ha...

The fact that they don't now doesn't mean they can't in future!

One of the advantages of having a separate block for tests is we can do things in that block that won't necessarily pervade the whole language where it might not make sense (which we already do: eg, the keywords "is" and "satisfies"). We've all done some sort of "here's a list of tuples, now map the prefix of this as arguments and the suffix as the expected value over this function", so it is something on our mind.

But I've struggled a bit to find a good way of writing it. We've written a few things where it looked truly "naked" to have these tuples without the surrounding function call. So it's as much a matter of syntax design as anything else.

I must say that the code on that page does not look like something I want to copy; it looks like a good compromise, but with emphasis on both words. We don't need to compromise.

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

#226

Post by skrishnamurthi »

ufo wrote: post #170
skrishnamurthi wrote: post #79

Earlier quoted context omitted.

Some of the Pyret designers are part of the Racket community, and know these ideas well. Where Pyret differs is that Racket has two different languages (for the purposes of this discussion), Racket and Typed Racket, and a program has to live in one or the other. Whereas Pyret takes a different "gradual" philosophy to type annotations, so a program doesn't have to move between the two languages.

I was just trying to point out that Pyret is not inventing the contract-checking and that Racket, the language Pyret owes a lot to, already has the contract system terhechte was looking for. Maybe I should have been more clear. That said, I'm going to take the opportunity to ask a question: does Pyret's gradual typing cover parametric polymorphism and mutable data structures? Those usually are specially though to do…

Sorry, lost track of what you were responding to.

Re. your other question, yes, this is a wide-open problem, and we're trying to not get bogged down in research issues like this. We actually have one answer about what to do, presented in a paper we wrote some time ago (http://cs.brown.edu/~sk/Publications/Papers/Published/gmfk-r...), but we don't really want to do that. But because we're working on a (curious) type inference story, we may be able to carve up this problem in a very different way.

Sorry for the non-answer. You're right, and we're working on it.

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

#227

Post by skrishnamurthi »

colanderman wrote: post #200

I can't find any documentation on the type system. In particular, I'm interested in how objects are typed (that they're both structurally typed and may be abstract is novel), and the capability of the type refinements. I loathe template-based OO due to the possibility of monkey-patching but the fact that objects are immutable looks like it might ease this. (Generating efficient code might still be difficult.) I don't…

The type system hasn't been published yet.

We don't have monkey-patching. We've been burned too much by JavaScript and the like.

Cyclic structures: think about trying to teach graph algorithms. Let's say you believe it's important to write tests. Many graph algorithms aren't inherently mutational. But you need mutation just to create examples of your data. The graph construct gets around this problem entirely, so mutation and graph algorithms become orthogonal topics. In general, I'm a big believer in eliminating unnecessary curricular dependencies. Having taught graph algorithms this way for a few years now, I can't imagine going back.

See the notes on graphs in PAPL (papl.cs.brown.edu/2013/).

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

#228

Post by skrishnamurthi »

e12e wrote: post #202
skrishnamurthi wrote: post #194

Earlier quoted context omitted.

Nope. Virtually nobody uses Smalltalk as the first language any longer anyway, to the best of my knowledge.

Well, I'm guessing not that many are using Pyret as a first language (yet) either... (Actually, I think a few people are still using Squeak to teach kids programming, so that's not even true)? Anyway, I was more curious if you'd done such a study because a) It's a very concise and consistent syntax, and b) with all the great work that appears to go into Pharo Smalltalk it would seem to be viable option (again). And y…

Sorry, my point was not to get into a popularity pissing match. I do believe popularity and quality are largely unrelated.

What I meant is, since most people have stopped teaching with Smalltalk, it's really hard to do the kind of research I'm talking about! We had no trouble doing it for Racket because we were able to get lots of data and from it measure for statistical significance.

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

#229

Post by acjohnson55 »

skrishnamurthi wrote: post #175
lmm wrote: post #164

Earlier quoted context omitted.

I'd be interested in seeing some more explicit examples of the differences, because I get a very scala-like vibe from all the examples in the article (I accept that dynamic vs static is a fundamental difference that doesn't really show up in syntax).

Scala is a great language with a rich excursion into type system design (and other things). Pyret is designed to reinforce specification (more general than types) and to do so through a combination of static and dynamic means. That much I've already said. Let me point to testing as an example of where we differ. Testing is really important to us. As you've seen, we have lightweight, in-place test cases. In addition:…

That's pretty fascinating. (static) Type inference based on tests sounds like an ill-posed problem, or at least one that can't produce human-meaningful annotations. That is to say, If one function has spec A for a generic parameter, and another function has spec B, it doesn't seem like it's possible to generate in general the spec for their composition in "closed-form".

Like, what's the type spec of "map" where the monad argument is a list of even numbers and the function to be lifted maps numbers to uppercase strings? It doesn't seem like we can meaningfully talk about the "type" of the function's result with any sort of specificity beyond List[String] or maybe List[String[Uppercase]], even though the real type is quite a bit more specific. 

How does inference work downstream of this point? Can we get reasonable errors before run-time?

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

#230

Post by ufo »

skrishnamurthi wrote: post #226
ufo wrote: post #170

Earlier quoted context omitted.

I was just trying to point out that Pyret is not inventing the contract-checking and that Racket, the language Pyret owes a lot to, already has the contract system terhechte was looking for. Maybe I should have been more clear. That said, I'm going to take the opportunity to ask a question: does Pyret's gradual typing cover parametric polymorphism and mutable data structures? Those usually are specially though to do…

Sorry, lost track of what you were responding to. Re. your other question, yes, this is a wide-open problem, and we're trying to not get bogged down in research issues like this. We actually have one answer about what to do, presented in a paper we wrote some time ago ( http://cs.brown.edu/~sk/Publications/Papers/Published/gmfk-r... ), but we don't really want to do that. But because we're working on a (curious) type…

Thanks, in a way the non-answer is more useful than a real answer for me :)
Post reply on HN