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

The Pyret Programming Language

pyret.org

Post reply on HN
Print view View original

111–120 of 138 posts

Re: The Pyret Programming Language

#111

Post by travisjungroth »

srfsrvsr wrote: post #91
dTal wrote: 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…

I think they were using "#lang system" as a synecdoche[0] for "Racket's language support". Racket's USP is definitely that it's a platform for language design and implementation[1].

On the other hand, I don't think it's a big deal they moved off of Racket. I actually think it's a success story that they were able to build on the platform and then move off.

[0]https://en.wikipedia.org/wiki/Synecdoche [1]https://en.wikipedia.org/wiki/Racket_(programming_language)

Re: The Pyret Programming Language

#113

Post by jonnytran »

catwell wrote: post #65
satyanash wrote: post #53

The ruby comparison is unfair: o = Object.new def o.my_method(x) self.y + x end def o.y 10 end o.my_method(5) == 15 # true method_as_fun = o.my_method # Wrong number of arguments, 0 for 1 The last line is actually doing: method_as_fun = o.my_method() Which should make the error message obvious. Ruby makes this syntax optional for readability purposes, which becomes obvious once you start going through real world ruby…

Yes, that would be: method = o.method(:my_method) method.call(5) # or method[5], or method.(5) If you really want a "function" that you can call with parens: Kernel.define_method(:method_as_fun, &method) (Definitely don't do that last bit in a real project...)

And before someone criticizes Ruby for being inconsistent in how the method is called, Ruby isn't a callable oriented language [1]. The common case is calling methods, so the fact that you need to say `.call(5)` both makes it more consistent and makes real code more concise, especially when making DSLs where chaining is really useful.

1: https://yehudakatz.com/2010/02/21/ruby-is-not-a-callable-ori...

Re: The Pyret Programming Language

#114

Post by empressplay »

eterevsky wrote: post #50

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

Really? Even our Logo interpreter successfully resolves that one (although you have to use radsin instead of sin because our sin works in degrees)

Re: The Pyret Programming Language

#115

Post by dTal »

travisjungroth wrote: post #111
srfsrvsr wrote: post #91

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…

I think they were using "#lang system" as a synecdoche[0] for "Racket's language support". Racket's USP is definitely that it's a platform for language design and implementation[1]. On the other hand, I don't think it's a big deal they moved off of Racket. I actually think it's a success story that they were able to build on the platform and then move off. [0] https://en.wikipedia.org/wiki/Synecdoche [1] https://en.w…

I like your positive attitude towards it - when you phrase it like that, it does indeed sound more like a success story. You may have changed my mind!

Re: The Pyret Programming Language

#116

Post by zem »

psykotic wrote: post #101
skrishnamurthi wrote: post #86

Earlier quoted context omitted.

But if you write instead a := b+c * d you aren't going to get an error. You're just going to get awfully surprising behavior, because you may think you were expressing one precedence with the spaces but the language has its own mind and doesn't care. In contrast, Pyret doesn't bind anything more tightly than anything else. You parenthesize to make your intent clear. If your expression gets too large, you should consi…

A space-aware syntax can allow optional spacing around operators but make it an error if it does not respect the precedence hierarchy or is deemed inconsistent by other rules.

I believe fortress did that.

Re: The Pyret Programming Language

#117

Post by Waterluvian »

justinpombrio wrote: post #96
Waterluvian wrote: post #76

Earlier quoted context omitted.

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

That would help. I’ll have to experiment to better understand if it all works well enough.

I’m thinking about Python unittest having setUp function for preparing every test without repeating myself. Maybe Rust has a similar way to define setup code for every test.

Re: The Pyret Programming Language

#118

Post by cabalamat »

skrishnamurthi wrote: post #86
cabalamat wrote: post #31

Earlier quoted context omitted.

> Always requiring whitespace around infix operators is, in my opinion, easier to explain to people than "you can do whatever you want with the whitespace." It might be easier to explain, but it also makes the code look ugly. Consider the expressions: a := b + c*d if e > f-g then ... Here the * and - are more tighly bound than the + or >, and I'm using the whitespace to make that obvious.

But if you write instead a := b+c * d you aren't going to get an error. You're just going to get awfully surprising behavior, because you may think you were expressing one precedence with the spaces but the language has its own mind and doesn't care. In contrast, Pyret doesn't bind anything more tightly than anything else. You parenthesize to make your intent clear. If your expression gets too large, you should consi…

Your argument is that a language shouldn't have a feature, because that feature can be misused in order to make the program hard to understand.

But this is a bad argument, as it could apply to any language feature. E.g. I could write a program:

    def add(a, b):
        return a - b
Here I've called it "add" but it does subtraction. By your argument, we should ban functions having meaningful names, as people could use a misleading one.

> Pyret doesn't bind anything more tightly than anything else

So all dyadic operators have the same precedence, like in Smalltalk? How horrible.

> You parenthesize to make your intent clear.

More likely I write my code in something other than Pyret, to make my intent clear.

Re: The Pyret Programming Language

#119

Post by jpolitz »

chajath wrote: 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.

This is a good question! We addressed this explicitly in our (new) book that starts in Pyret and transitions to Python:

https://dcic-world.org/2021-08-21/part_appendix.html#%28part...

Post reply on HN