Live data from Hacker News

The Pyret Programming Language

pyret.org

121–130 of 138 posts

Re: The Pyret Programming Language

#121

It seems like a bad idea to use the same “where” syntax for definitions and test cases, especially since a major aim of this is education.

The `where:` syntax ought to only be for test cases attached to functions. Maybe this comment is a useful answer: https://news.ycombinator.com/item?id=28265210

Re: The Pyret Programming Language

#122

My criticism is that this language is very similar to Python and might very well confuse students who ultimately have to switch to Python or other languages.

If it helps to think about the issue, we have a (free, online) book that manages this transition, so we've thought about this quite a bit and one co-author has been teaching a Pyret -> Python flow for several years. [https://dcic-world.org/2021-08-21/part_intro.html]

Re: The Pyret Programming Language

#124

> # this is true > ((1 / 3) * 3) == 1 This is a slippery slope. Early versions of Dart tried to use rational numbers by default, but then it was cancelled because denominator size can grow exponentially. Also, I seriously doubt you can make a language that will correctly resolve checks like this one: sin(pi / 6) == 1 / 2

The number stack goes like this: naturals -> integers -> rationals -> reals.

Trying to simplify this by removing any stage doesn't really work. sin() over a rational should be a compile time error.

Re: The Pyret Programming Language

#127

> # this is true > ((1 / 3) * 3) == 1 This is a slippery slope. Early versions of Dart tried to use rational numbers by default, but then it was cancelled because denominator size can grow exponentially. Also, I seriously doubt you can make a language that will correctly resolve checks like this one: sin(pi / 6) == 1 / 2

The number stack goes like this: naturals -> integers -> rationals -> reals. Trying to simplify this by removing any stage doesn't really work. sin() over a rational should be a compile time error.

PI/6 is not rational.

Re: The Pyret Programming Language

#128
post #49

Earlier quoted context omitted.

> Knowing who they are, I would happily assume that they spent plenty of time debating this exact issue of mixing kebab case with infix subtraction, and either decided the benefits were worth the cost or else decided that the cost was practically nonexistent. We don't need to assume when we can search. I did a few minutes of searching and found the following: https://groups.google.com/g/pyret-discuss/c/rPe7gYBLdPs/m/…

It only makes more sense when you do look at the background, so thanks for the link. They're lisp folks. They use kebab-case. I completely get it. It may be the product of decades of research, but it is also the product of default choices and comfort for the people who wrote it. ALL programs have an element of this: I write Rust and you can tell without looking when some tool is written in it -- TOML config? Apache-2…

> Does this not speak for itself?

If not, this does:

   $ cp a-b c-d # copy a-b file to c-d
   $ expr 1-1
   1-1
   $ expr 1 - 1
   0
You already know some language with whitespace delimiting such as, oh, the shell.

Re: The Pyret Programming Language

#129
post #87

What pain point of Python as an education language is Pyret trying to address? Union type might be vaguely useful, although some of these use cases can be modelled as inheritance or typed enums.

IMHO, Union types are the one the most important features that should have been in programming languages since C. And I believe it would have made our software much more bug free than it is generally now. Enums in all languages should be Rust like enums with exhaustive checking and allow recursive definitions.

Re: The Pyret Programming Language

#130
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…

If I understand correctly, the main problem was that the Pyret project wanted Pyret to run directly in the browser, so they needed a JavaScript-backend. Since Racket doesn't have a JavaScript-backend, they wrote a compiler in Pyret that compiles Pyret to JavaScript.

I don't see the lack of a JavaScript-backend as failure of the language building facilities of Racket. In fact, the ability to quickly build a new language in Racket, made it possible to try out different features quickly. Also, it made bootstrapping possible.

Post reply on HN