Pyret: A new programming language from the creators of Racket

http://www.pyret.org

by sergimansilla • 13 years ago

396 283 13 years ago

tel8• 13 years ago

Python-like syntax with pattern matching and recursive ADTs!? What a great idea!

rhizome31• 13 years ago

This looks a lot like the language I've been dreaming about. I actually like the explicit `end` keyword to materialize the end of blocks. The lambda expression syntax, as illustrated by the filter/map/fold example, looks like Ruby blocks with a much simpler syntax. A couple of questions to the crew:

Why advertise it as a teaching language ? As a working programmer this looks very appealing to me. Are there limitations that don't make it a good language for practical programming (other than the fact that it's not ready yet, of course)?

Are you planning to provide a tutorial more approachable than the language reference?

tel8• 13 years ago

It's not my language, so I can't really talk to those questions. I think it's fair to say that the Racket group has always been focused on teaching languages not to exclude "production languages" but instead because it's of their personal interest and lets them focus on certain aspects of the language to exclusion of others. They don't need to build performant standard libraries---they need to cleanly introduce good programming concepts.

mageofmath3• 13 years ago

It still has some performance issues that I say would make it hard to put into an industry environment.

I think the teaching language part is in reference to Captain Teach, an IDE++ that the developers are using in the classes to support code review, automatic backups, and more.

Pyret is being designed with the goal of encouraging good code, with tests being an integral part of every function, and clear differentiation between mutation and simple let bindings. I would teach this language just for those features, so my students would see how easy it is to get lost in spooky action at a distance, or in debugging the wrong portion of your code.

ricw• 13 years ago

I'd disagree with the "end" keyword. You could add more whitespace, which our brains naturally deal with very well, or you add more "cruft" which we have to actively think about. In typography white space is what makes good layout work. And here we're going back to replacing white space with a word. So from those perspectives I think the "end" keyword is a regression.

Having said that, it's the first language that I prefer from a typographical perspective to python. So very well done on everything else.

jpolitz11• 13 years ago

Thanks for the questions!

As to why we're advertising it as a teaching language: Our group has a design sense of how to do this, and Pyret's success in the classroom is what we're able to study, measure, and focus on improving. That doesn't mean we won't be thinking about managing million-line codebases or getting great performance out of the runtime, but those concerns won't necessarily be the main guide of our design decisions. We may very well end up with something that's a superb general-purpose language, but I'm not yet willing to give folks that expectation, or do so at the expense of the learning experience. Make sense?

EDIT to add: One thing that the Racket community has very successfully done is separate teaching languages from the main Racket language. A probable future for Pyret is splitting it into teaching and professional versions. I'd love to hear feedback about what more you'd like to see in Pyret, with this split in mind.

The getting started guide (http://www.pyret.org/getting-started/) and tour (http://www.pyret.org/tour/) is the best reference for getting started right now. If you didn't see those then they probably need more prominent placement.

jpolitz11• 13 years ago

There's another response to this that I didn't mention. Shriram is writing a textbook that includes all the material for our advanced intro course and our programming languages course. There's a lot of good examples here:

http://papl.cs.brown.edu/2013/

rdtsc• 13 years ago

Did you know about Elixir? It has a Ruby like syntax, pattern matching, functional, has macros so can build DSLs with it. Also most importantly, runs on BEAM VM (Erlang's VM).

http://elixir-lang.org/

lmm2• 13 years ago

If you're looking for a more mature language that feels like that, I very much recommend scala.

skrishnamurthi75• 13 years ago

Scala is statically typed through-and-through. Pyret is designed to always offer a dynamic account of the language. We do have a static type checker under development (it's all-but-ready to release), but it will always work over a language where type annotations are optional. We also have a radically different idea about type inference, which we are currently trying out. In short, Pyret and Scala are already quite different and will grow even more so soon.

terhechte• 13 years ago

"""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 code tests down without switching contexts (files, workspaces, etc)

jacques_chester• 13 years ago

D has something like this[1]. It might have come from a still-earlier language.

[1] http://dlang.org/unittest.html

sparkie3• 13 years ago

My biggest gripe with these is the inability to name the tests. What exactly is a unittest block testing for? You need to rely on comments or read the test code where none exists. Doesn't seem like Pyret fixed that issue.

ash2• 13 years ago

Making tests part of language syntax is an interesting idea.

Of course it's not equivalent, but Python doctest module at least allows you to keep tests close to the code. Here's Pyret example, ported to doctest:

  def sum(l):
      """
      >>> sum([])
      0
      >>> sum([1, 2, 3])
      6
      """
      return reduce(lambda x, y: x+y, l, 0)

  if __name__ == "__main__":
      import doctest; doctest.testmod()

laureny• 13 years ago

Making tests part of language syntax is an interesting idea.

It's been tried many times before and it has always failed. A few reasons:

- It clutters the code

- If you need simple tests, asserts suffice

- If you need more sophisticated tests, write functional tests, separately

The approach offered by Pyret (along with similar ones, such as design by contract) are compromises that are the worst of both worlds.

pjmlp4• 13 years ago

Contracts?

skrishnamurthi75• 13 years ago

Every time you write a refinement on a type, you're actually writing a contract. You can gracefully move between types and contracts this way, and also between thinking of them as checked assertions vs tested ones. The goal is to make this migration more and more seamless.

GhotiFish• 13 years ago

That really caught my eye!

Does anyone have any experience with workflows like this? Are tests next to code a pragmatic technique?

qiemem• 13 years ago

Python has them in the form of doctests. They are generally frowned upon as they tend to significantly clutter up code and documentation when they actually provide comprehensive testing. That said, Pyret's format may escape that fate as they are given their own section which most modern editors should be capable of folding.

Doctests: http://docs.python.org/2/library/doctest.html

keppy2• 13 years ago

I use this in clojure where I am interacting with the code from the repl. run-tests will execute tests for function defns wrapped with the with-test macro. This is fast and no external file or namespace needs to load just type run-tests; http://richhickey.github.io/clojure/clojure.test-api.html

6ren• 13 years ago

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 kept in sync by (hopefully) failing when not. However, their idea of automatically running tests is interesting, so there's no infrastructure to set-up, run etc (though you'd want to be able to disable them).

Nice for teaching.

ash2• 13 years ago

Literate programming… didn't catch on

I would argue literate programming is experiencing a renaissance, thanks to docco:

https://github.com/jashkenas/docco

stiff2• 13 years ago

I don't think the story of literate programming can be of any help predicting how well this idea here can work out.

Literate programming is not "embedding documentation". The main idea was to separate the order in which the code is read from the order in which the compiler sees it, and it embeds the code in the documentation, not vice versa. It was a very idiosyncratic thing, hard to imagine a team of programmers in a typical current commercial setting, developing a nice LaTeX essay around the actual code of the next social network web-app. As the program grows larger it also gets harder and harder to maintain the "story" around it.

tel8• 13 years ago

I think that Python's doctests have shown this to be a greyer area than this. Not all tests can fit nicely next to function definitions, but a few well-chosen ones are both fantastic documentation and not too cluttery.

driax• 13 years ago

On the other hand, inline test does make it easier to write tests while writing the function. Besides many well-written programs already contains inline documentation (not comments) that can be a lot longer than the function they describes.

Code folding in a IDE goes a long way to make this bearable.

msutherl• 13 years ago

You would think we'd have editors by now that could, say, hide all the tests to declutter the code while you're reading it.

skrishnamurthi75• 13 years ago

You don't have to put the tests right in the middle of code. The `where` form goes with the definition, but a `check` form can float freely. So if you prefer a <Lang>Unit style of testing, where your tests reside in a separate file, you can do that with `check` blocks just fine.

However, the `where` tests play into the type-inference story for the language!

qznc• 13 years ago

I think you are both right. D even takes it to the next logical step: Present the unit tests as examples in the API documentation (like Doxygen,Javadoc). It means the API examples are kept in sync.

http://qznc.github.io/d-tut/testing.html

acjohnson555• 13 years ago

If the tests are pages long, that might be a sign that the function could be refactored. Also, the optional type annotations and refinements seem to decrease necessary testing quite a bit, compared to the typical scripting language. I would use this all the time.

And as other people mentioned, you can always use the check statement out of band, too.

seanmcdirmid• 13 years ago

It clutters the code.

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

wuschel• 13 years ago

Interesting. Could you propose such an extension by posting a code sample e.g. in scheme?

ek4• 13 years ago

Sure. These are basically simple contracts. Contracts are implemented in Racket: http://docs.racket-lang.org/reference/contracts.html

ufo5• 13 years ago

Racket has a very powerful contract system that you might want to out. It also has support for higher-order contracts on functions (contracts that have delayed checks instead of being just assertions) and they also have a typed version of Racket (Typed Racket) built using the contract system.

skrishnamurthi75• 13 years ago

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.

eliben• 13 years ago

I'm not sure I like having tests in the same file with the code. In real code bases it's very common to just read the code, and cluttering that with huge swaths of unit-tests is counter-productive.

That said, Pyret appears to be aimed at education so this may make more sense.

skrishnamurthi75• 13 years ago

Then you can put your tests in a `check` block and move them elsewhere. You don't have to use `where` except when it makes sense.

reeses• 13 years ago

This is bouncing against the perpetual "code as text" problem.

Put the tests and docs in with the code and you end up going into "scanning" mode. The actionable information density per character is lower.

Put the tests and docs outside the code and you (or that obnoxious guy who just changed > to >=) don't update the tests or the docs. In the worst case (cough functional web tests) people tend to disable the tests because it's too much work to get them to conform to the changes and everyone is on fire and babies are dying and this needs to be done in production now.

vidarh6• 13 years ago

Sounds like Eiffel:

http://en.wikipedia.org/wiki/Eiffel_(programming_language)#D...

skrishnamurthi75• 13 years ago

Not even remotely in just about any respect.

rmc• 13 years ago

AST-Macro enabled languages (... Python)

What?! You can't write macros in Python? (right? have I missed something?)

anonymous• 13 years ago

Indeed you can https://github.com/lihaoyi/macropy

mck-• 13 years ago

I was thinking exactly the same thing after I read that :)

keppy2• 13 years ago

in clojure:

  (with-test
      (defn my-function [x y]
      (+ x y))
    (is (= 4 (my-function 2 2)))
    (is (= 7 (my-function 3 4))))

tinco• 13 years ago

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 mistake, it should have never been in Python, and it definitely not be repeated in other languages..

clarkevans• 13 years ago

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.

sirclueless• 13 years ago

Pyret doesn't actually have an indentation-based format (so far as I know) it just happens to look like python.

acjohnson555• 13 years ago

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

ek4• 13 years ago

I would encourage you to view the syntax as "Python, but repaired", for the following reasons:

1. Pyret comes out of Shriram's group's expertise with pinning down exactly what Python and other dynamic scripting languages do right, and (mostly) do wrong. Check out their recent paper Python: The Full Monty: A Tested Semantics for the Python Programming Language http://cs.brown.edu/~sk/Publications/Papers/Published/pmmwpl... for more context.

2. Ruby is far and away not the originator of 'end' to end blocks -- this comes from Pascal and is in other languages that have nothing to do with Ruby, like Lua.

3. Languages that aren't Haskell have ADTs too; it happens that they've lifted an ML-style syntax for defining them.

4. Python is widely used pedagogically, so for better or for worse, students are already being familiarized with the colon, which I agree is a bit anomalous.

cwzwarich• 13 years ago

Ruby is far and away not the originator of 'end' to end blocks -- this comes from Pascal and is in other languages that have nothing to do with Ruby, like Lua.

The use of 'end' comes from Algol, not Pascal.

timtadh• 13 years ago

Thanks for the link to that paper. Super interesting to see actual semantics for python come out. It would be nice if this leads to better tooling for analysis of the language. Currently, it is pretty hard to bootstrap anything for the language in comparison with what you can do for the JVM.

clhodapp3• 13 years ago

I think you mean that it's in opposition to their goal of being easy to learn, not that it's orthogonal, as that would mean "it doesn't interfere".

Anyway, it seems to me that the only real difference between your code examples is that the second one lacks an ending designator and uses an equals-sign instead of a colon. However, in order to make the lack of an ending designator work, you need a more complex parser (it needs to infer block-ends from indention or some other context). Leaving off ending designators also increases mental overhead for the user, as they must keep block-end inference rules in mind in writing code. Using colons versus using equals-signs is simply a matter of taste (not weight, as you seem to claim).

That said, I do see some waste in their datatype definition syntax. First, I'd prefer curly braces over the colon/end pairs that they went with, as that saves a few characters. Second, newlines are a fine separator, so why also require pipes? This requires the user to type three characters (newline, pipe, space after pipe) when just one would have done fine.

ek4• 13 years ago

Newlines are not a fine separator; what if you have a definition that you intend to span multiple lines? In any case, the pipes go all the way back to EBNF, since what you are really doing when you specify an ADT is specifying a grammar of types.

I admit to also being a brace weenie; I would very much prefer if all the languages I had to use had them. However, Pyret exists in a tradition of many successful, braceless languages like Python, ML, and Lua.

jpolitz11• 13 years ago

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 a good idea. I made an issue for it, we'll think about if it'll break or confuse anything and add it if it doesn't:

    https://github.com/brownplt/pyret-lang/issues/106

e12e7• 13 years ago

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?

gizmo2• 13 years ago

Pyret looks like a there's a lot going on, based on the examples. It has implicit returns, special purpose syntax for data structures, iterators, assertions, refinements, etc. Having support for more stuff makes it less suitable as a teaching language, not more. Pyret looks like a has the good bits of Python plus a whole bunch of other cool stuff. But the language is pretty complex as a result.

Cool? Yup! Good for teaching? Probably not.

Take a look at the grammar and judge for yourself: https://github.com/brownplt/pyret-lang/blob/master/src/lang/...

saosebastiao• 13 years ago

Edit: deleting snark.

Oz is one of the best languages ever for learning CS.

xfs• 13 years ago

Actually Brown teaches Intro to Programming Languages using Pyret. http://cs.brown.edu/courses/cs173/2013/software.html

legutierr• 13 years ago

By looks of the course number, this is a third or fourth year elective for undergrads. It seems that what is being taught here is the design and engineering of programming languages, not programming itself.

fgoodman2• 13 years ago

They also teach the Accelerated Intro to Computer Science (the first cs course some students take) using Pyret. http://cs.brown.edu/courses/cs019/2013/

PhineasRex• 13 years ago

By that logic, assembly is the best language to learn programming.

Presumably it is easier to learn about concepts with a language that has them.

gizmo2• 13 years ago

Obviously I'm not suggesting that assembler is the best teaching language. I could also take your logic and use it to conclude that C++ is the best programming language to learn first because with C++ you can learn about the implications of heap corruption when improperly handling exceptions in constructors. C++ allows functional, procedural and OO and many more programming styles. It supports manual and automatic memory management. It can be used to teach high level and low level programming constructs. But I think we're all in agreement that C++ is not a good first language to learn despite (or because of) its versatility.

I think Python is a very accessible programming language that still has enough depth to go into a lot of interesting CS subjects. That Python doesn't have manual memory management or support for true multiple inheritance means that you can't teach those things effectively with Python, and I'm completely OK with that trade-off.

tokenrove2• 13 years ago

Actually, there's a (devil's advocate) argument for teaching assembly first. After all, TAOCP is all assembly for good reason. Many programmers who never learn any assembly language lack a kind of procedural literacy, as well as a mechanical sympathy, which are a big part of the craft of programming.

But, as you state, there are a lot of higher-level programming concepts you can't effectively learn in assembler (one imagines a bizarrely circuitous route around learning to build compilers in assembly (via Forth perhaps) in order to teach lexical scoping or similar).

tel8• 13 years ago

My understanding is that it's a relatively simple place to learn about how to manipulate data (as in algebraic data type style, FP data) and has all of the conveniences of syntax that allows someone to think fluently about that concept.

So it's syntactic complexity might be high, but it's conceptual complexity is rather low.

jkscm• 13 years ago

Language complexity may not matter much.

"He speculated that the size of programming languages might confuse many students trying to learn to program. Java, the teacher’s programming language of choice at the end of the 20th century and at the beginning of the 21st, is defined loosely but at great length in several hundred pages.4 Natural Deduction, on the other hand, can be defined precisely on a single side of a single A4 sheet, in a normal font size. It is small and conceptually simple: surely it can be taught! Well, up to a point it can, but the results were depressingly familiar. Figure 14 shows the results from an in-course exam on formal logical proof. Unlike the examinations of section 3, students were strongly discouraged from guessing, with negative marks for wrong answers in multiple-choice questions and extensive unseen proof problems. As a consequence, two humps are clearly visible, with one at 33-40 (about 50%) and another at 65-72 (about 85%). (This data was collected long before Dehnadi’s test was developed, so we can’t analyse it further)."

Saeed Dehnadi - The camel has two humps (working title): http://mrss.dokoda.jp/r/http://www.eis.mdx.ac.uk/research/Ph...

jpolitz11• 13 years ago

Thanks for your comments!

I have two responses:

1. You're right that exposing too much, too soon is a recipe for disaster. People can only fit so many new concepts in their head at once, and blasting them with refinement types from day one isn't a great idea. However, there's two things at work here: the role of the curriculum and the role of the language. Pyret is careful to allow a gradual transition to more and more complex features. Annotations are not necessary on day 1, and neither are iterators. We write untyped, recursive-descent functions on lists in the beginning, and build up to types and the pleasant terseness of "for" loops. If Pyret required introducing these concepts to write any programs, that would indeed be a problem, but we've put thought into the dependencies between curricular concepts and the needed language constructs to mitigate exactly this concern.

2. I think that some of the features you listed are actually a huge necessity in early programming, particularly special purpose syntax for data structures. Teaching the definition and implementation of a balanced binary tree to folks without language experience in Python or Java requires a huge amount of boilerplate explanation. You need to describe classes, fields, and constructors just to do the equivalent of Pyret's "data". The alternative (at least in Python) is to encode everything in lists and dictionaries, but hopefully in 2013 we've moved beyond writing all our data structures that way :-)

colanderman5• 13 years ago

Joe, any plans to push this out in Kathi's intro course at WPI?

dragonwriter• 13 years ago

I don't see why a complex language can't be good for teaching if its designed in such a way that the complexity is optional, and you can use a focussed subset for pedagogical purposes (especially when the language supports using different focussed subsets depending on the specific focus of pedagogy.)

I mean, even if you look at how language like Scheme/Racket, or Python, or pretty much any other language is used in teaching, you don't usually use the whole thing in any one teaching context.

skrishnamurthi75• 13 years ago

This is true of all educational settings -- except that the language subset then becomes an unenforced (and hence very leaky) abstraction. Students inadvertently step outside the subset and get either bizarre errors or, worse, their program runs and produces strange errors.

DrRacket pioneered the notion of "language levels" that grow with the student's needs. Pyret will end up taking some variant of this route. It's just too early to design those levels yet.

skrishnamurthi75• 13 years ago

The language is in use in introductory courses, with a gradual introduction of these topics. It's no different from using any other modern programming language in education.

Our goal is to eventually create language levels, pioneered by DrRacket, based on what we learn from observation. This is a research project in addition to a development one, where the research is into human factors.

colanderman5• 13 years ago

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.

skrishnamurthi75• 13 years ago

DrRacket pioneered the notion of "language levels" that grow with the student's needs. Pyret will end up taking some variant of this route. It's just too early to design those levels yet. Once we have more experimental data about what kinds of inadvertent mistakes students make, we'll be in a position to say, "Oh, yeah, that was a bad thing to release on day 1", etc.

carterschonwald2• 13 years ago

The grammar can be described with a single page in actual BNF. Thats AMAZING. The only languages have shorter grammars are core lisp/scheme. Ruby is fundamentally impossible to describe with a BNF.

vidarh6• 13 years ago

Thats AMAZING. The only languages have shorter grammars are core lisp/scheme.

It's nice, but I'm not sure I'd go with amazing. Most or all of Niklaus Wirth's languages have shorter grammars, for example. I'd imagine quite a few others do as well.

E.g. Oberon-2 has 33 EBNF productions: http://en.wikipedia.org/wiki/Oberon-2_(programming_language) - that fits fully on screen for me with my default font size...

Regarding Ruby, I agree. I'm working on a Ruby compiler, and "decoding" the MRI parser into something closer to optimal will still leave an awful mess no matter what you do. I love programming Ruby, but implementing it is hell (and one of the reasons I'm trying it...)

masklinn• 13 years ago

The only languages have shorter grammars are core lisp/scheme.

Smalltalk would like to have a word with you: http://chronos-st.blogspot.be/2007/12/smalltalk-in-one-page....

justincormack• 13 years ago

And Lua http://parrot.github.io/parrot-docs0/0.4.5/html/languages/lu...

klrr2• 13 years ago

This project seems really promising, but I got one concern. Lisp's syntax have been one of its strength for beginners. Easy to learn, easy to solve common errors. I don't see the point of having Python-like syntax really, the user could learn other syntax after they've understood programming.

andybak• 13 years ago

My jaw dropped slightly to see someone suggest Lisp syntax would be a better starting place for beginners than Python's syntax. Is it just me or is that a fairly unorthodox point of view?

f7t7ft72• 13 years ago

MIT used to teach intro to CS using Scheme, I thought. It's significantly simpler than Python.

adrusi• 13 years ago

No that's fairly normal. It's the whole reason the scheme language, the second most popular lisp, was created. it's lost favor to python and java and c++ because those languages have more of a foothold outside of academia and might be more useful to students who only take a couple cs courses.

klrr2• 13 years ago

Lisp syntax is (<operator> <args...>) with a few special forms (def, if, cond etc.). This is really easy to understand and allows the user to go straight forward and learn about the semantics and general programming practice immediately.

chongli3• 13 years ago

The key word is beginners. The people who have the most trouble with Lisp syntax are those already accustomed to other languages. Beginners pick it up with no trouble at all.

sparkie3• 13 years ago

I'd say the real trouble is teaching any syntax at all to beginners, because their first language really taints them for life. Most people will think of successive languages in terms of their first, until they learn many and are able to think more generally.

Lisp has the advantage that it really teaches the general semantics of programming languages, because it's syntax is just the syntax tree, and it basically only has one form, which is function application. There's some "special forms" built into the implementation of a lisp to make it useful, but those shouldn't be confused with syntax. In fact, the parenthesis and space between function and arguments shouldn't be considered the lisp syntax either - it's just one way to represent a tree structure in linear text.

I think the real issue is the confusion in teaching is between Computer Science and Computing as a vocation. Nobody teaches the former any more, because it's less useful in the real world. As a result, we have languages which try to make a distinction between "programmer" and "programming language implementer", where the programmer generally knows less about what he is doing because someone has imposed a specific, narrow set of ideas on him.

mageofmath3• 13 years ago

At Brown (the place this research is coming from) one of the main CS intro courses is taught in Racket. It's worked really well and people enjoy the simplicity in getting programs running quickly. People with previous programming experience have more trouble than true beginners at that point in the course.

The course later moves into 3 other languages (OCaml, Scala, and Java) to try and get the beginners not focused on any particular language, though there is some debate on whether that effectively teaches the beginners any language particularly well.

Pyret would definitely be a candidate for replacing OCaml in that sequence as anything with better error messages would be very welcome.

ek4• 13 years ago

Like it or not, universities have started to move away from teaching Scheme to introductory CS students. You may remember that much was made of MIT and Berkeley switching away from Scheme for Python. I think Pyret comes out of a precedent of Python as the new standard, so in that light, it's certainly an improvement.

stass• 13 years ago

That's because they stopped teaching CS, it's not that they replaced Scheme with Python in CS courses. How can you possible teach metacircular interpreters, constraint propagation languages, ambiguous computation and similar constructs using Python when you need to be able to easily define a completely different language semantics using language at hand? In that sense, Pyret will allow them to teach a bit more CS than possible using ordinary Python but still is in no way fit for something on the level of SICP.

jpolitz11• 13 years ago

Syntax is tricky and contentious, and our team members do love our Schemes. Members of the Pyret team have actually done some research on the issue of parenthetical expressions in introductory programming, and seen that parens aren't necessarily the best:

http://cs.brown.edu/~sk/Publications/Papers/Published/mfk-va...

One issue is that it's too regular: since open-paren means so many different things (start of a "defun", start of a function application, start of an argument list in a "defun", start of a syntactic form like "cond" or "if", start of a clause of "code", the list goes on), a typo can easily and drastically change the kind of error message you get.

More closely matching syntactic forms to the type of behavior the expression has will hopefully let us improve error messages and grokkability of the difference between concepts. We're collecting data about common syntax errors and actively asking what we can do better in syntax design based on what we observe about Pyret's use.

e12e7• 13 years ago

Did you ever do any research/tests/courses with Smalltalk as the first language?

acjohnson555• 13 years ago

I wish this could be upvoted so much more.

As someone who hasn't spent much of my time in Lisp world, most of my time when I come across some supposedly elegant implementation of an algorithm in Lisp, what my brain sees is impenetrable parenthesis soup. One incredible win of Python is the resemblance of the syntax to pseudocode, and how easy that has apparently been for new developers to absorb. I'm glad to see your team has taken that to heart for a language that's supposed to be pedagogical. And that is beautifully said about how a misplaced parenthesis can lead to all sorts of errors.

Error reporting, debugging, and documentation are in that "meta" tier of programming ergonomics that few people care to reason about, and yet they are oh so important to allowing actual human beings to learn programming languages and use them to produce rereadable and maintainable code.

skrishnamurthi75• 13 years ago

I've programmed in and taught Lisp syntax for 24 years, much of it exclusively in that syntax. I've also extensively researched errors in parenthetical languages.

The simplicity of parens is widely regarded as a strength, but I believe it is also a weakness. There is too much regularity in the syntax, resulting in numerous errors. Programmers, especially beginning programmers, need more "guideposts" in their programs. Additionally, parsers also benefit from this when producing errors.

kudu• 13 years ago

end

-.-

takikawa• 13 years ago

Pyret has lots of nice ideas, looking forward to see it evolve.

That said, the title of this post is a bit misleading so I wanted to correct it. The group of people who develop Racket and Pyret are mostly disjoint. I'm not trying to diminish Pyret at all, but wanted to make sure the right people get the credit. You can find out who develops Pyret here: http://www.pyret.org/crew/

pekk• 13 years ago

Looks more like Ruby than Python, why the comparison to Python?

L8D• 13 years ago

Where Ruby usually denotes code blocks with a `do` and an `end`, Python denotes code blocks with a `:` and an outdent. But also, Ruby has a lot more implicit syntax and uses methods as operators(`1 + 1 == 1.+(1)`). There are a few more things that wouldn’t be obvious, like how it is still indentation sensitive yet you still need to use an `end`. Also, you can avoid the `end` keyword is you include it on the same line, like so:

    fun square(n): n * n

skrishnamurthi75• 13 years ago

Okay, there's a Ruby example on the home page now, and probably one more on the way.

skrishnamurthi75• 13 years ago

Second Ruby example is in place now.

k_bx• 13 years ago

Python-inspired syntax for functions
fun to-celsius(f):
(f * (5 / 9)) - 32
end

Wait a minute..

garysweaver2• 13 years ago

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

I coded in Java for many years and Ruby for the last several, the lack of explicit type checking in method signatures or via annotations built into Ruby has not gotten in the way enough where I felt I needed to add something to decorate methods to do some generic form of type checking in Ruby. When I really need to check the type of an object sent into a method, it is typically a method that can handle different types, and in that case, I'll use respond_to?(...) to see that an object passed in as an argument responds to a method, use a case statement, is_a?(...), etc. but that is certainly not on every method- probably more like 1 in 20-30 methods.

Also, in the comparison section of the doc, OCaml and Python were represented, but not Ruby. As of late 2013, there are more jobs containing "Ruby" in the job description than "OCaml": http://www.indeed.com/jobtrends?q=ocaml%2C+ruby&l= So, imo it should give Ruby some love with a comparison.

skrishnamurthi75• 13 years ago

As you wish! We now have two Ruby examples on the home page. You may not call it love. <-:

garysweaver2• 13 years ago

Thanks, but may want to correct:

method_as_fun = o.my-method

which should be:

method_as_fun = o.my_method

and the examples themselves just look a little crazy, imo. Not crazy because of what you are trying to do, but in how you are trying to do it. What was the intent of calling a method that defines an argument without an argument? That's not a problem of the language; that's just an error in coding. There are all kinds of things in Ruby to handle method definition. Arguments can have defaults. You can use splat and unsplat to handle unspecified arguments and composing arguments of various # on the fly. You can pass in blocks specifically (&something) or optionally (yield, etc.). Procs allow argument sillyness and returning the parent method by explicit return in the proc body, lambdas don't, etc. Ruby is a great language, and you should give it a college try for several months to get the hang of it.

By the same token, I have no clue what you are trying to do here:

def f(x); def g(y); x + y; end; g(2); end; f(2) # undefined local variable or method `x'

You can define methods on object instances, if that is what you are getting at (define_method/class_eval/etc.), and getting familiar with blocks, procs/lambdas might help. It isn't JavaScript, but I can't think of that much that I couldn't do in Ruby (barring high performance, compile-time type checking, etc.)

mrcactu5• 13 years ago

it sounds great to blend Python and Lisp!

sparkie3• 13 years ago

Except it abandons most of the benefits of lisp.

skrishnamurthi75• 13 years ago

If s-expressions constitute "most" of the benefits of Lisp, that's a pretty sad statement for Lisp. I don't see any other benefits that it gives up.

kolev• 13 years ago

I lot more Ruby-like than Python. Not sure why it both has ":" and "end" and the "|" is kinda ugly the way it's used.

kerryritter• 13 years ago

This doesn't seem like it would be easy for novices to grasp, though it looks like a solid language. For teaching, I think Quorum (http://www.quorumlanguage.com) seems like a stronger alternative (disclosure, I am a member of a CS senior project team building their web system).

dragonbonheur• 13 years ago

Those "new" languages keep looking more and more like BASIC.

gosub• 13 years ago

We should have been using very different dialects of BASIC, since I can't remember mine having algebraic data types, pattern matching, integrated testing, first class functions, high order functions and bignums.

mageofmath3• 13 years ago

I also like the fact that you can put unit tests for helper functions that are inside of other functions. This means you can use the inputs to your outer function as part of the tests for an inner function, which has been hard to do in the past.

symbaton• 13 years ago

Wow, I didn't think of that. That is actually amazing.

tbenst• 13 years ago

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 is hard and takes time)

3. Write contract, purpose, header for functions (contract and header are annotations in Pyret, purpose should be a commented statement)

4. Write concrete examples of the function (This is hard and takes time. This means test cases!)

5. Write the template (This may only apply to recursion in Racket, but the idea is if you're dealing with a cons, you always have the same structure of checking if a cons? or empty? and must recur)

6. Fill in the template (ie, complete the function)

sesm• 13 years ago

There is a book about this approach (http://htdp.org/), as well as a MOOC on Coursera (https://www.coursera.org/course/programdesign)

m_for_monkey• 13 years ago

The second edition of How to Design Programs is not finished yet, but I recommend it anyway: http://www.ccs.neu.edu/home/matthias/HtDP2e/index.html

oahziur• 13 years ago

htdp was my first programming book, and it is really helpful.

agumonkey• 13 years ago

Can't suggest these enough for any programming student.

skrishnamurthi75• 13 years ago

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<T>):
    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<T>):
    cases (List) l:
      | empty => ...
      | link(f :: T, r :: List<T>) => ... f ... f(r) ...
    end
  end

which further nudges you towards a possibly recursive solution.

JulianMorrison• 13 years ago

This looks like it could be useful as a way to prototype a real program.

zem• 13 years ago

I really love the surface design decisions taken here. Particularly

* ML-like syntax for algebraic datatypes and matching. ML got it right; it always seems a bit off when languages try to make ADTs look like some other syntactic construct

* the cyclic and graph declarations

* accessing datatype variants using an OO-like syntax. simply brilliant.

* non-significant whitespace. for all the pros and cons, autoindenting is something i hate to give up.

kazagistar3• 13 years ago

Somehow, it looks a lot more like lua with a bunch of type-checks and tests added then like python. No named parameters, no generators, no comprehensions that I can see, no focus on iteration in general, no significant indentation, etc.

Instead: "end" syntax, unified number type, all blocks produce new scopes (not just functions), local variables are explicit instead of default, etc.

jpolitz11• 13 years ago

That's a useful comparison, thanks. While we were certainly inspired by Pythonic syntax, we have ended up somewhere slightly different.

The note about local variables is particularly important; we actively don't want Python's model of variables and scope.

kazagistar3• 13 years ago

Note: this wasn't a criticism of your language: I rather prefer lua's way of doing numbers, co-routines, and even scoping to some degree. I was more criticizing your comparison.

The language itself looks pretty slick, and I am a sucker for gradual/optional typing. Do the type annotations result in performance/compiler optimization, as in Julia?

rayiner• 13 years ago

Its shocking to me that so many languages designed after Scheme get variable scoping wrong.

pygy_2• 13 years ago

Indeed, but apparently, it doesn't have multiple return values, and I don't know if there is an equivalent to metamethods.

skrishnamurthi75• 13 years ago

It's easy to obtain the equivalent of multiple return values by using a literal object.

I've been burned by multiple return values numerous times in Scheme and Racket. They're very subtle and hard to make performant. It's one of those language features that very much does _not_ pay its own way, so you have to really, really need it to want to put it in your language. My view is that its uses are not many, and most (all?) can easily be achieved with literal objects. That's why Pyret doesn't have them and is unlikely to get them.

jdnier• 13 years ago

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-...

skrishnamurthi75• 13 years ago

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.

pcmonk• 13 years ago

I wonder how well this integrates with Racket? I see that it's built with Racket, but I'd be curious if I could mix and match this with all my Racket code.

skrishnamurthi75• 13 years ago

That is not an explicit design goal, because we feel that would be too restrictive -- we may even diverge semantically. We are in fact working on compilers for the language that don't involve going through Racket (though Racket is so awesome, it's not a given that this will be any better -- these are all just experiments in progress). But without Racket's #lang, which is absolutely a rock star language creation mechanism, Pyret probably wouldn't exist.

In short, though, sorry, we can't commit to helping you interop with your existing Racket code. But you're already in Racket, so life is probably as good as it's ever going to get. (-:

jimktrains2• 13 years ago

Mostly OT: I've been working on the spec for a lang I'd like to implement at some point and would like feed back if anyone cares to give any?

https://github.com/jimktrains/k5

yashodhan• 13 years ago

dashes in function names! I'm in love.

b6fan2• 13 years ago

The Ruby examples are unfair.

Ruby intentionally makes parenthesis optional. So `do_something` is `do_something()`.

For the first example,

  - method_as_fun = o.my-method
  - method_as_fun(5) # not reached
  + method_as_fun = o.method(:my_method)
  + method_as_fun.call(5) # or method_as_fun[5]

And for the lexical scope thing,

  def f(x)
    g = ->y {x + y}
    g[2]
  end
  f(2)

Or, explicitly use class variables,

  def f(x)
    @x = x
    def g(y); @x + y; end
    g(2)
  end
  f(2)

skrishnamurthi75• 13 years ago

If one has to rewrite code like this, you're making our point.

b6fan2• 13 years ago

The Ruby way is:

  1. common (not all) things are simple / elegant.
  2. Advanced things are doable, usually require a slightly more complex syntax.

For example, Ruby allows one "block" (anonymous function) per method. Why not 2 or more blocks? Because Matz has studied common lisp (likely, maybe something else) standard library and noticed that in ~97% (maybe not exact number) cases, one anonymous function is enough. But you can use more anonymous functions using a different syntax.

And here is the same case. People call methods much more often than to get the method. Therefore Ruby makes it default to call the method, but not stop you from getting the method object. It's just unfair to say Ruby cannot do these things.

colanderman5• 13 years ago

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 see the use cases for the cyclic structure as presented. If your data at all resembles a database relation, then (a) you have scalar keys anyway so you don't need language support, and (b) you probably need to key off of more than one column.

The "method-as-fun" semantics seem weird. Given this code:

    o = { x(self): self.y end, y: 10 }
    f = o.x

f() returns 10, as per the examples on the front page. But then:

    p = o.{y: 15}
    q = { x: o.x, y: 15 }

Clearly p.x() should return 15, but what does q.x() return? It doesn't seem clear whether it should return 10 or 15. (Without reading through the reference manual (it's late), my guess would be that method definition is special-cased, so that the answer would be 10.)

skrishnamurthi75• 13 years ago

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/).

colanderman5• 13 years ago

But you need mutation just to create examples of your data.

OK, I'll buy this.

breezydon• 13 years ago

Pyret is so hot these days.

fedvasu2• 13 years ago

sounds like ML+contracts, but wait is it statically typed? Maybe not Racket folks hate types (with great dredd)

skrishnamurthi75• 13 years ago

It's gradually typed. Everything has both a static and dynamic account. We have a prototype type checker and a pre-prototype type inferencer.

If Racket people "hate types", you'd have a hard time explaining the existence of Typed Racket, or that some of the most cited research on types is by one of Racket's creators.

But please, don't let facts get in the way. (-:

fedvasu2• 13 years ago

Sorry Professor, there is only one person behind typed-racket Sam, AFAIK. typed racket isn't very well supported or documented or even advertised by racket folks.

progman• 13 years ago

Pyret looks very promising. Keep on the good work!

But please remove the minus sign from identifiers! I am concerned that people may abstain from Pyret for this simple reason. It is really annoying to embrace every operator with blanks. That should be an optional job for the IDE to increase readibility.

By the way, is there already a raco exe for Pyret?

skrishnamurthi75• 13 years ago

Thanks for the encouragement. You can indeed run it using raco pyret ....

We're sticking with the identifier syntax for now. We've written a lot of code in Pyret over the course of 9-12 months and we really like it. My guess is that people will only notice it if someone points it out (only one person on HN noticed, and even that was to ask how it could work). Most folks will just get on with the job at hand.

mcpherson• 13 years ago

functions are fun

lars512• 13 years ago

Incidentally, a Gist for installing Pyret using Marelle:

https://gist.github.com/larsyencken/7424864

Pyret: A new programming language from the creators of Racket

Related Stories