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

Rye Language

ryelang.org

Post reply on HN
Print view View original

21–30 of 61 posts

Re: Rye Language

#21

Post by RodgerTheGreat »

bsder wrote: post #16
galaxyLogic wrote: post #2

This sounds cool: "Every active component in Rye is a function (if, loop, for, fn, return, extends, context). No keywords, no special forms." It should make the language much simpler than other languages. The challenge of programming is dealing with copmplexity in code, and if the language takes away much of that complexity it should be a good thing.

Apparently it's called "either" and it doesn't evaluate every arm. So, explain to me how that is a function and not a special form?

REBOL-family languages (including Logo) don't eagerly evaluate expressions like a Lisp, and therefore can use ordinary functions/operators in places that would otherwise need to be special forms and/or macros.

Re: Rye Language

#22

Post by cardanome »

middayc wrote: post #11
lispm wrote: post #9

Earlier quoted context omitted.

> There are multiple token types and they always combine / apply in the same ways, there are no special forms like "how to define a function" or "how to write and if else". In Rye calling if or eihter (if/else) is no different than calling any other function. Not in Lisp. In Lisp IF, COND, ... are either special operators or macros which expand to more primitive special operators. They are not functions. The syntax f…

Yes, you are correct. I wasn't exact e nough about it, the end result syntax wise is similar, but there are macros involved in Lisps case. I wrote multiple times right about this difference between Rebol-s and Lisp-s. The main difference being that Lisps evaluate lists by default and you have to quote them to not be evaluated and Rebols don't evaluate blocks by default and you have to "do" them to evaluate them. That…

There is Lisps with so called f-expressions[0] which do not have special forms. That would be similar to the Rebol approach I think, I am a bit fuzzy on that.

The general consensus in the lisp community is that having a few special forms is worth it as it makes the compiler's job much easier. Basically it is a trap because yes it is much more elegant but practically it isn't worth the trouble, or at least some people see it that way. I also heard that Smalltalk is considered hard to compile for its lack of special forms.

But more complicated doesn't mean it is necessary impossible to still have a efficient compiler. It is definitely an interesting topic. Definitely would love to hear if you had any trouble on that front. If you already that far that you are thinking about optimization that is.

And your new languages looks amazing. Definitely going to check it out.

[0] https://web.cs.wpi.edu/~jshutt/kernel.html

Re: Rye Language

#23

Post by middayc »

BiteCode_dev wrote: post #17

Interesting, but optional parenthesis is a no go for me. Every time I try to read a Ruby line with no (), I have to stop and think. Not being able to scan code is an anti feature.

Rye as Rebol (that it derives from) doesn't use parenthesis in general. In Rebol you can use them optionally for explicitly defining evaluation priority. But not in the same form as in Algol based languages:

    print(inc(x))
But like Lisps. I've used them when I wanted to be very certain about evaluation, but not in general.

    (print(inc x))
In Rebol (or Rye) this is usually just:

    print inc x
That's why all function in Rebol/Rye have fixed arity and yes, you generally have to know it or deduce it from the code, which is a minus.

Rye currently doesn't have parenthesis option, but it might get it at the end. It does have op and pipe words, an optional left to right flow, which can also better hint about the structure than pure polish notation of Rebol I think. For better of worse, these Rye expressions all do the same :) --

    print inc x
    print x .inc
    x .inc .print
    inc x |print

Re: Rye Language

#24

Post by middayc »

RodgerTheGreat wrote: post #21
bsder wrote: post #16

Earlier quoted context omitted.

Apparently it's called "either" and it doesn't evaluate every arm. So, explain to me how that is a function and not a special form?

REBOL-family languages (including Logo) don't eagerly evaluate expressions like a Lisp, and therefore can use ordinary functions/operators in places that would otherwise need to be special forms and/or macros.

Exactly ... I tried to explain this here: https://ryelang.org/meet_rye/basics/if_either/

Re: Rye Language

#27

Post by __MatrixMan__ »

BiteCode_dev wrote: post #17

Interesting, but optional parenthesis is a no go for me. Every time I try to read a Ruby line with no (), I have to stop and think. Not being able to scan code is an anti feature.

Ideally this would be a view setting, and could be enabled or disabled for different users without making edits to the code.

Re: Rye Language

#28

Post by middayc »

__MatrixMan__ wrote: post #27
BiteCode_dev wrote: post #17

Interesting, but optional parenthesis is a no go for me. Every time I try to read a Ruby line with no (), I have to stop and think. Not being able to scan code is an anti feature.

Ideally this would be a view setting, and could be enabled or disabled for different users without making edits to the code.

Yes, and IDE that would know the arity of functions (which is not totally simple, because of the very dynamic nature of the language) would be able to display the "parenthesis" or the grouping of function calls. I plan to make sort of visual editor for it too as an experiment so that could be a first demo of it.

Re: Rye Language

#29

Post by skybrian »

Hint: the "interactive" demos are scrollable by dragging the bottom. (Sadly, you don't have any access to the terminal window's scrollbar, so you can't just scroll to the end of the "video.")

I still think a non-animated transcript of a terminal session is better.

Re: Rye Language

#30

Post by middayc »

ejstembler wrote: post #26

Looks interesting! +2 for Postgres and AWS support. Looking forward to GCP support someday...

Rye is Go based, and Go has a great number of well done libraries. Integrating Go libraries into Rye by hand is very simple and I was able to add plenty of them, at least at proof of concept level just on my own.

Rye-front is also an experiment of how you can externally extend Rye, by adding Rye to your code/library. In this case the main focus is Go GUI library Fyne.

Now a colleague is writing a tool that auto-generates Fyne bindings and has already made great progress (Fyne has couple of 1000 functions/structs/... If we will be able to generalize this to any Go library, this will be really exciting.

Post reply on HN