The Pyret Programming Language

Post by eterevsky » Sun, Aug 22, 2021, 8:25 AM UTC

0-_-0 wrote: post #52

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

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

Post by cormacrelf » Sun, Aug 22, 2021, 8:46 AM UTC

xpe wrote: post #49

DonaldPShimoda wrote: post #25

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'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…

> 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/…

    fun subtract(a, b):
      a-b
    end
    
    >>> The identifier a-b is unbound:        definitions://:3:2-3:5
    
    4 | a-b
    
    It is used but not previously defined.

Post by catwell » Sun, Aug 22, 2021, 8:59 AM UTC

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…

    method = o.method(:my_method)
    method.call(5)
    # or method[5], or method.(5)

   Kernel.define_method(:method_as_fun, &method)

Post by scns » Sun, Aug 22, 2021, 9:35 AM UTC

Maksadbek wrote: post #55

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.

Post by scns » Sun, Aug 22, 2021, 9:43 AM UTC

scns wrote: post #34

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.

Beauty lies in the eye of the beholder, ie aesthetics are subjective. For me, using proximity instead of parentheses to signify grouping would raise an eyebrow. I'd make an exception for cases of base*exponent, i think Python has it?