Live data from Hacker News

The Pyret Programming Language

pyret.org

91–100 of 138 posts

Re: The Pyret Programming Language

#91
post #88

I was excited that Pyret, which I was previously familiar with as a Racket #lang, had evidently gained enough independence to warrant its own website that does not even mention Racket. What a vindication of the #lang system! Then I read this: "Ultimately, Racket’s #lang facilities, though designed to create new languages—and a great prototyping ground for Pyret—proved to not be quite enough to support a language crea…

Is #lang really Racket's USP?

I vaguely get that the idea is an extension of the Unix "shebang" convention to files which define modules. It might be preferable to a system based on file extensions or file associations (it's certainly less brittle). I guess the question is whether it's better than directives of the form "import(lang, file)", in other words, explicitly naming the interpretation language for each file that's imported. Naturally one could set a default so that a plain "import(file)" would do the right thing. A project full of files in extremely heterogenous languages would make make #lang more appealing, but it would also be possible to build some kind of file association system within Racket—personally I would prefer to put the #lang info in the filename or the path than stick it ("intrusively") into the file.

Re: The Pyret Programming Language

#92

The syntax is pretty much like Python and ruby: “end” to declare end of block statements and colon to start a block statement. But why to use “fun” to declare a function when “def” could be used. The same in other languages: function, func, fun, fn, etc.

Lol the syntax is basically Ocaml with a tad less noise.

Re: The Pyret Programming Language

#93
post #51
post #41

I like the idea of attaching tests to the function itself - oftentimes I'm finding myself combing through the unit tests for various components to understand the expectations around how they are meant to be used (especially when they are not documented well enough), I feel this approach could help in this aspect (and also with adding new test cases that could have been missed).

And in python you can use doctests (tests inside de docstrings of functions)

I'm looking to do something in this general area better than doctests. Looking for collaborators.

http://adsharma.github.io/pysmt

Re: The Pyret Programming Language

#94
post #88

I was excited that Pyret, which I was previously familiar with as a Racket #lang, had evidently gained enough independence to warrant its own website that does not even mention Racket. What a vindication of the #lang system! Then I read this: "Ultimately, Racket’s #lang facilities, though designed to create new languages—and a great prototyping ground for Pyret—proved to not be quite enough to support a language crea…

Is #lang really Racket's USP? I vaguely get that the idea is an extension of the Unix "shebang" convention to files which define modules. It might be preferable to a system based on file extensions or file associations (it's certainly less brittle). I guess the question is whether it's better than directives of the form "import(lang, file)", in other words, explicitly naming the interpretation language for each file…

#lang is much more than shebangs. Racket #langs are implemented on top of Racket - they can be nothing more than alternative syntaxes, or they can have different semantics (written in Racket). This has the effect of rendering different Racket #langs interoperable within a project. This is wildly powerful - someone reimplemented Python entirely as a #lang, for instance, which meant that Racket could use (pure) Python libraries directly, and vice versa.

It's an entirely different philosophy, which aims to allow to use "the best tool for the job" even within a project. Need a DSL? Write one!

Re: The Pyret Programming Language

#95
post #94

Earlier quoted context omitted.

Is #lang really Racket's USP? I vaguely get that the idea is an extension of the Unix "shebang" convention to files which define modules. It might be preferable to a system based on file extensions or file associations (it's certainly less brittle). I guess the question is whether it's better than directives of the form "import(lang, file)", in other words, explicitly naming the interpretation language for each file…

#lang is much more than shebangs. Racket #langs are implemented on top of Racket - they can be nothing more than alternative syntaxes, or they can have different semantics (written in Racket). This has the effect of rendering different Racket #langs interoperable within a project. This is wildly powerful - someone reimplemented Python entirely as a #lang, for instance, which meant that Racket could use (pure) Python…

I understand all that. You don't seem to have understood my comment, which was asking questions about the suitability/fitness of the "#lang" mechanism, rather than questioning the idea of polyglot code on top of Racket.

I guess it seems to me like it hasn't been established whether the "#lang" mechanism is a brilliant invention, or something cheesy. My initial reaction is that it seems cheesy.

Re: The Pyret Programming Language

#96

Earlier quoted context omitted.

I haven't used doctests in Python, but I have in Rust. It really helps that any code blocks in a docstring is a doctest by default, so they ensure that examples in your documentation stay evergreen. It's nice to know that if there's a code example in documentation, it will compile and run properly and hasn't been broken.

Practically speaking how useful are the Rust doctests? I thought they looked like a genius idea but I don’t get how they work 95% of the time when examples don’t come with all the plumbing required to make valid state for a function to actually work on.

There's a feature for that: you prefix the plumbing with `#`, and it runs in the doctest but doesn't render on the doc page. https://doc.rust-lang.org/rustdoc/documentation-tests.html#h...

Re: The Pyret Programming Language

#97

Earlier quoted context omitted.

I've used rationals by default in Racket/Scheme for literally 3+ decades now. It's fine. Dart is trying to be an industrial-strength language. We're trying to create an awesome initial programming experience. To the beginner, those denominators are nowhere near as much of a problem as "numbers" that don't make sense. But we draw limits. Did you try the `sin(pi / 6)` example? You'll find that Pyret produces a rather i…

I'm a bit dubious that magic stuff like this really makes anything easier. It's like JavaScript's truthiness and type coersion. It's trying to be friendly and work most of the time, but in reality it is more complex because now you have to remember a whole set of rules about how exactly the magic behaves.

Waaaay less magic than Javascript. Looks like the rules are described here. Two kinds of numbers: exact and rough. Unless you use trig functions it will all be exact. https://www.pyret.org/docs/latest/numbers.html

Fun fact about Javascript: there are string and number constants x, y, and z, such that `x Think about what this means for sorting!

Re: The Pyret Programming Language

#98

Earlier quoted context omitted.

I've used rationals by default in Racket/Scheme for literally 3+ decades now. It's fine. Dart is trying to be an industrial-strength language. We're trying to create an awesome initial programming experience. To the beginner, those denominators are nowhere near as much of a problem as "numbers" that don't make sense. But we draw limits. Did you try the `sin(pi / 6)` example? You'll find that Pyret produces a rather i…

I'm a bit dubious that magic stuff like this really makes anything easier. It's like JavaScript's truthiness and type coersion. It's trying to be friendly and work most of the time, but in reality it is more complex because now you have to remember a whole set of rules about how exactly the magic behaves.

My guess is that you didn't try @skrishnamurthi suggestion:

> Did you try the `sin(pi / 6)` example? You'll find that Pyret produces a rather interesting result that is also instructive.

The result of this doesn't feel like magic and doesn't resemble "JavaScript's truthiness and type coersion" at all IMO.

Here's a live code editor where you can try it out: https://code.pyret.org/editor

I found it to be a very refreshing and intuitively-guiding experience :)

---

Spoiler alert!

So, fist i had to find how to access pi and sin(), which was simple enough googling for documentation. Typing `num-sin(PI / 6)` on he editor already gives an interesting result:

  ~0.49999999999999994
That ~ there looks suspicious!

Then i tried `num-sin(PI / 6) == 1 / 2`, which seems to be syntactically invalid and yields an awesome error message:

  Reading this expression errored:
  
  num-sin(PI / 6) == 1 / 2
  
  The == and / operations are at the same grouping level. Add parentheses to group the operations, and make the order of operations clear.
Kudos to the Pyret team for such a nice error message!

So finally, adding those missing parens, `num-sin(PI / 6) == (1 / 2)`, yields another informative and useful error message:

  Attempted to compare a Roughnum to an Exactnum for equality, which is not allowed:
  
  The left side was:
  
  ~0.49999999999999994
  
  The right side was:
  
  0.5
  
  Consider using the within function to compare them instead.
All in all, i'm very impressed with the clarity and approachability of the language. Thanks @skrishnamurthi for the suggestion of trying this out! :D

Re: The Pyret Programming Language

#99
post #52

Earlier quoted context omitted.

The Wolfram language successfully resolves it: https://www.wolframalpha.com/input/?i=sin%28pi+%2F+6%29+%3D%...

Yes, I should have written "practical programming language". It definitely possible to resolve many equations like this (though not all of them), but is quite a slow process, which is ok for a math system like Mathematica, but not for a real-life programming language.

"Real-life programming language" or "practical programming language" assumes that there's only one acceptable set of trade-offs for all "real-life" or "practical" problems. I suspect that what you actually meant was "a programming language designed to create industrial-strength consumer or business software".

As one of the maintainers has noted repeatedly on this thread, Pyret is a "real-life programming language" whose purpose is educational. Mathematica is a "real-life programming language" whose purpose is solving math equations. Performance isn't much of an issue in either case, so it's a perfectly acceptable trade-off.

That these languages weren't designed with your use case in mind doesn't make them illegitimate or inferior languages.

Re: The Pyret Programming Language

#100
post #94

Earlier quoted context omitted.

#lang is much more than shebangs. Racket #langs are implemented on top of Racket - they can be nothing more than alternative syntaxes, or they can have different semantics (written in Racket). This has the effect of rendering different Racket #langs interoperable within a project. This is wildly powerful - someone reimplemented Python entirely as a #lang, for instance, which meant that Racket could use (pure) Python…

I understand all that. You don't seem to have understood my comment, which was asking questions about the suitability/fitness of the "#lang" mechanism, rather than questioning the idea of polyglot code on top of Racket. I guess it seems to me like it hasn't been established whether the "#lang" mechanism is a brilliant invention, or something cheesy. My initial reaction is that it seems cheesy.

I'm not sure I'm following, then. You think the basic idea of polyglot programming on top of Racket is sound; but that's what #lang does, and is the interesting bit of what we're talking about. The fact that it's specified with a line at the top of the file is a boring implementation detail - albeit the correct decision in my view, since the information about what language a file is written in clearly belongs with that file - exactly the same reason we have shebangs. But it seems like a minor thing to pick on to deem it "not Racket's USP".
Post reply on HN