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

21–30 of 138 posts

Re: The Pyret Programming Language

#21

Post by justinpombrio »

cabalamat wrote: post #9

Overall this looks quite nice. I like the way types can be defined but if they are not they can be anything. Are these types checked anywhere? I think they should be checked at compile-time wherever possible, and optionally at run time too (I say optionally as the checks might make it slow, so they could be checked in development but perhaps not in production).

IIRC, they're checked at run-time but not compile-time. And to avoid the speed issue (you're right: it really can get really slow), it only checks the top-level type. E.g. `List` just checks that it's a list.

Re: The Pyret Programming Language

#22

Post by cormacrelf »

nostrademons wrote: post #20
cormacrelf wrote: post #18

It seems pretty bad to have kebab-case identifiers in a language that also has an infix subtraction operator -. The only languages I know that allow kebab-case idents are lisps, where subtraction is (- prefix notation). From the examples: lam(actual): num-abs(actual - target) This is a new, even worse kind of "whitespace significance" than indentation. Is it a function called `num-abs` or a variable `num` minus `abs(…

Dylan had kebab-case idents and infix operators. It worked okay because you have to separate infix operators with a space anyway; omitting it is a syntax error. In practice I doubt this would trip me up because every coding standard I've worked with has mandated spaces around infix operators. I suppose it might be a lot more confusing if you're used to coding standards that allow you to omit them, but my understandin…

Maybe it would be okay with syntax highlighting and a careerful of code formatting muscle memory, but how would that fare in an educational context?

> "Pyret is a programming language designed to serve as an outstanding choice for programming education"

Re: The Pyret Programming Language

#23

Post by justinpombrio »

nostrademons wrote: post #20
cormacrelf wrote: post #18

It seems pretty bad to have kebab-case identifiers in a language that also has an infix subtraction operator -. The only languages I know that allow kebab-case idents are lisps, where subtraction is (- prefix notation). From the examples: lam(actual): num-abs(actual - target) This is a new, even worse kind of "whitespace significance" than indentation. Is it a function called `num-abs` or a variable `num` minus `abs(…

Dylan had kebab-case idents and infix operators. It worked okay because you have to separate infix operators with a space anyway; omitting it is a syntax error. In practice I doubt this would trip me up because every coding standard I've worked with has mandated spaces around infix operators. I suppose it might be a lot more confusing if you're used to coding standards that allow you to omit them, but my understandin…

Same thing in Pyret, it's a syntax error to not put a space around infix operators.

Re: The Pyret Programming Language

#25

Post by DonaldPShimoda »

cormacrelf wrote: post #18

It seems pretty bad to have kebab-case identifiers in a language that also has an infix subtraction operator -. The only languages I know that allow kebab-case idents are lisps, where subtraction is (- prefix notation). From the examples: lam(actual): num-abs(actual - target) This is a new, even worse kind of "whitespace significance" than indentation. Is it a function called `num-abs` or a variable `num` minus `abs(…

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's consistent and regular. I don't think it's as much of an issue as you're making it out.

Pyret is the result of decades of research in computer science education, helmed by Shriram Krishnamurthi, who was one of the original members of the Racket project (itself a language designed for CS education in the '90s, a descendant of Scheme with kebab case and prefix notation). The full list of authors of Pyret is lengthy, but includes a number of well-established researchers in the PL and CSed communities. 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.

In any case, I trust their decisions better than those of someone who glanced at the website only long enough to inform a condescending (and highly superficial) comment on Hacker News.

Re: The Pyret Programming Language

#26

Post by darrenf »

cormacrelf wrote: post #18

It seems pretty bad to have kebab-case identifiers in a language that also has an infix subtraction operator -. The only languages I know that allow kebab-case idents are lisps, where subtraction is (- prefix notation). From the examples: lam(actual): num-abs(actual - target) This is a new, even worse kind of "whitespace significance" than indentation. Is it a function called `num-abs` or a variable `num` minus `abs(…

Raku has kebab-case as well as infix subtraction. Sigils disambiguate when the operands are variables ($foo-$bar), and callables must be made explicit:

    sub foo-bar { 10 }
    sub bar-foo { 7 }
    say foo-bar-bar-foo; # Undeclared routine error
    say foo-bar()-bar-foo; # 3

Re: The Pyret Programming Language

#27

Post by Ericson2314 »

DonaldPShimoda wrote: post #25
cormacrelf wrote: post #18

It seems pretty bad to have kebab-case identifiers in a language that also has an infix subtraction operator -. The only languages I know that allow kebab-case idents are lisps, where subtraction is (- prefix notation). From the examples: lam(actual): num-abs(actual - target) This is a new, even worse kind of "whitespace significance" than indentation. Is it a function called `num-abs` or a variable `num` minus `abs(…

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's consistent and regular. I don't think it's as much of an issue as you're making it out. Pyret is the result of decades of research in computer science education, helmed by Shriram Krishnamurthi, who was one of the original members of the Racket project (itself…

Yes not requiring spaces around infix operators is terrible even when there is no ambiguity. Frankly, everything about programs-as-text is terrible for beginners, but this softens the blow.

Re: The Pyret Programming Language

#28

Post by runarberg »

cormacrelf wrote: post #18

It seems pretty bad to have kebab-case identifiers in a language that also has an infix subtraction operator -. The only languages I know that allow kebab-case idents are lisps, where subtraction is (- prefix notation). From the examples: lam(actual): num-abs(actual - target) This is a new, even worse kind of "whitespace significance" than indentation. Is it a function called `num-abs` or a variable `num` minus `abs(…

In mathup[1] I actually use whitespace around infix operators to group expressions. E.g. `1 + 2/3 + 4` is not the same as `1+2 / 3+4`. I find this leads to a much cleaner expressions.

When you are designing your own language, you can make these choices. The author of Pyret obviously thought that clearly named identifiers were worth it.

1. https://runarberg.github.io/mathup/

Re: The Pyret Programming Language

#29

Post by chowells »

cormacrelf wrote: post #22
nostrademons wrote: post #20

Earlier quoted context omitted.

Dylan had kebab-case idents and infix operators. It worked okay because you have to separate infix operators with a space anyway; omitting it is a syntax error. In practice I doubt this would trip me up because every coding standard I've worked with has mandated spaces around infix operators. I suppose it might be a lot more confusing if you're used to coding standards that allow you to omit them, but my understandin…

Maybe it would be okay with syntax highlighting and a careerful of code formatting muscle memory, but how would that fare in an educational context? > "Pyret is a programming language designed to serve as an outstanding choice for programming education"

Only having one correct way to do something with very simple rules (always put whitespace around operators) is easy for students. It's when the rules are complicated with exceptions and multiple correct ways that things get hard to learn.

Re: The Pyret Programming Language

#30

Post by cabalamat »

justinpombrio wrote: post #21
cabalamat wrote: post #9

Overall this looks quite nice. I like the way types can be defined but if they are not they can be anything. Are these types checked anywhere? I think they should be checked at compile-time wherever possible, and optionally at run time too (I say optionally as the checks might make it slow, so they could be checked in development but perhaps not in production).

IIRC, they're checked at run-time but not compile-time. And to avoid the speed issue (you're right: it really can get really slow), it only checks the top-level type. E.g. `List ` just checks that it's a list.

> they're checked at run-time but not compile-time

Do they intend to add this? I think it would make a big difference. It would make thje language more like Haskell, where lots of bugs would be caught at compile time.

> it only checks the top-level type. E.g. `List` just checks that it's a list.

That's fair enough because otherwise it might have to go though potentially very big data structures.

Maybe there could be a command `strict_check(aDataStructure)` which would only get executed when type checking is on and would recurse into a data structure checking everything.

Post reply on HN