Rye: Homoiconic dynamic programming language with some new ideas

[1propionyl]

The email type seems just a smidge too specialized for me. It could more broadly be an "authority" type (borrowing URI/URN terminology) a la:

authority = [userinfo "@"] host [":" port]

The simple extension of allowing a port makes it a more broadly useful type, since authorities like above appear all over the place. Email is just one protocol after all.

There is also a url type, but it is unclear how general it is (just http/s?). There is a cpath type which corresponds to the path in a URI as well.

URI = scheme ":" ["//" authority] path ["?" query] ["#" fragment]

In Rye typing, authority _could_ be the authority described above, and cpath already covers path. The rest are strings as they don't have generically defined syntax.

Perhaps this is a bit of a quibble but it seems to me like if URIs and their structured components (cpath is already there, and email is so close!) were core types rather than just email and url, it opens up a lot of use cases.

[middayc]

Hm. Interesting proposition. Rye inherited email and URL data types from Rebol. I haven't done that much on them specifically, because they aren't that crucial to the design of the language dynamics, so their implementation certainly should be improved (ant thought about).

The idea of making them more general certainly makes sense. Rye is "end-user" focused so it would maybe still be called email. URI-s right now can have different schemes. Scheme defines the kind of url and Rye has generic functions that dispatch on the kind of first argument. So there is:

open file://readme.txt and open sqlite://db.s3db and open postgres://user@localhost/database "pwd" ...

%path/notes.txt is also Rebolism and it's a shorthand for file://path/notes.txt

Thank you. I will think about this

cpath is currently a little specific, at least in behaviour as it's a context path to a word.

Thank you for making this comment. I will think more about it and certanly reread it when I work on there datatypes next time.

[warvariuc]

The blog entry titled "Less variables, more flows example vs Python" is strange. ( https://ryelang.blogspot.com/2021/11/less-variables-more-flo... )

The Python version uses intermediate variables so the author of the code is to blame for verbosity, not the language.

[middayc]

This was written in 2021, maybe it's really not that great of a blogpost. I wrote a lot of blogposts from many angles back then, mostly to myself as there weren't many readers, trying to see the language from the outside, to self-motivate, etc ...

I think I wrote a script I needed in Rye and I found it interesting, then I went to Fiver and paid someone to write a script in Python that does the same.

2021 were different times, and I hope I've grown a little too... and now I would ask ChatGPT or Gemini :)

[woolion]

It is a legitimate complaint of the language as there are language-related reasons that motivates it --the conciseness of the language has an impact on readability, but also how convenient it is to debug on separate lines.

The code examples are a tad too verbose but actually better quality than most real-world Python codebases, I would say.

Python is not very verbose but it's not very concise either (especially compared to Lisp families)

[elbear]

I don't see fewer variables as something good. On the contrary, I find a long "flow" or chain of function calls harder to read or grok.

Variables also help readability, because the name can help you discern what those functions return.

[amluto]

ISTM the big difference is that the Python code is doing CGI essentially from scratch, but the rye code appears to be using a CGI library.

[gumby]

> Rye is homoiconic, it has no keywords or special forms (everything is a function call, everything is a value)

How does it implement and, or, or if?

[justinpombrio]

This took me a minute to get, even after looking at the page about if:

https://ryelang.org/meet_rye/basics/if_either/

The tricky thing about if, and, and or --- the reason you can't implement them as functions in most languages --- is that they need to not evaluate all their arguments immediately. Otherwise:

    // Would print!
    if(false, print("oops!"))

    // Would throw  an error if the key is not present
    and(my_hashmap.has_key("key"), my_hashmap["key"])

The way that ryelang gets around this is that you pass the arguments in a "code block" surrounded by "{}", which delays its evaluation. So you write:

    // Does not print, because *if* never runs its code block arg
    if 0 { print("oops!") }

    // There's no example of *and* anywhere but my guess is you'd write this:
    and { my_hashmap.has_key("key") } { my_hashmap["key"] }

[middayc]

Yes, as samatman said, main reason is that blocks of (code or data there is no difference) don't evaluate so they are passed as function arguments and the function can potentially evaluate them. So if is a function that accepts two arguments, a boolean and a block of code.

loop is a function that also accepts two, integer for number of loops and again a block of code.

Even fn that creates functions is a function that accepts two blocks, first is a list of arguments and second is a block of code. There is no big difference between function fn and function print, they are both builtin functions defined in same manner and there are multiple fns for special cases and you can create your own on "library" level.

[samatman]

This is possible with fexprs or equivalent constructs https://en.wikipedia.org/wiki/Fexpr

It looks like that's how Rye does it as well, blocks can be conditionally evaluated: https://ryelang.org/meet_rye/basics/if_either/

"In REBOL, contrary to Lisps, blocks or lists don’t evaluate by default. For better or for worse, this little difference is what makes REBOL - REBOL." https://ryelang.org/meet_rye/basics/doing_blocks/

It's difficult for a language with this semantics to be made efficient, but efficiency isn't everything.

[choeger]

In a eagerly evaluating functional language you could always wrap the arguments in a thunk:

So if your built-in functions were implemented in Python, you'd use:

  def if_(cond, t, e):
    if cond:
      return t()
    else:
      return e()

[chabons]

Presumably as functions, the same way as excel?

and(x, y) -> bool

or(x, y) -> bool

if(cond, funcTrue, funcFalse) -> void

[c4pt0r]

Seems like a good Swiss Army Knife-like addition to the shell script (reminds me of awk as well). It would be interesting to keep it that simple (not another Perl)

[middayc]

Awk was one of early use-cases I wanted to make it useful for. It still has "Ryk" mode, but I haven't tested it in years so I'm not sure if it works right now.

Rebol was known for its small set of moving parts and behaviors but with a lot of depth and flexibility with them. I've added some moving parts with left to right code flow, but I still hope it's a limited set that fits well together. I am adding new behaviors very conservatively now, and I will remove some. Thanks for heads up about Perl! ;)

[djaouen]

Congrats, this language looks pretty cool! What advantages does it have over, say, something like Elixir?

[middayc]

It's difficult to compare it directly to Elixir since Elixir is a production ready language built on top or Erlang VM. Elixir certainly has more solid runtime, as Rye is interpreted. But Rye probably has much more malleable runtime that you could maybe better structure and specialize around your problem.

[leke]

I played around with Rebol many years ago and enjoyed it. This too looks like fun.

[carterschonwald]

The detail about input validation is a really nice one that hopefully the next generation of programming languages all do standard.

[RodgerTheGreat]

It sounds intriguing, but it doesn't look like there are any examples in the readme, and the documentation for the Validation dialect on ryelang.org is completely blank. How does this feature work?

[artemonster]

familiar with rebol, but evaluation rules with op and pipe words gave me headache. would like to know more about context oriented programming, tutorial had nothing in the section, unfortunately

[middayc]

Yes, op and pipe words are the biggest or the most visual addition to Rebol's base idea. Without them if you replace { } with [ ] it's basically just Rebol ... well, with some different details around contexts (rebol's bindology), no refinements, mandatory spacing around tokens, different error handling logic and some other details.

I am still learning to explain or even name things, but various examples of using contexts in different ways are currently what excites me the most. I will write "Meet Rye" further and contexts are one of next subjects to be written about.

[kunley]

About getters.. are they foo? or ?foo ? The examples have it mixed, "Meet Rye" doc has it as ?foo

[middayc]

If you don't come from Rebol it would probably be weird to you that there are many specific word-types in Rye.

    name: Janko ; name: is a set-word - it binds value to a word
    ?print      ; ?print is a get-word - it get's value word is bound to in this case a print builtin function
    :age        ; left leaning set-word (this is get-word in Rebol)
    what?       ; just a regular word
    ...

name get's the value anyway, so we don't need to use ?name but if word is bound to a function just invoking a word will evaluate a function and if we want to return a funtion we use get-word. which has ? in front.

? at the end is just a regular word and a (currently accepted) naming convention where noun? means get-noun. so length? in instead of get-length etc.

Rebol used ? at the end convention for more things, a lot for boolean results, testing of types, like string? and positive? but also for lenght?

For booleans current Rye's naming convention is that we use is-adjective. Rebol used positive? to test if value is positive. We would in this way use is-positive.

The conventions might change if we see that there are ways that make more sense and are also consistent.