Live data from Hacker News

Rye: Homoiconic dynamic programming language with some new ideas

github.com

61–70 of 86 posts

Re: Rye: Homoiconic dynamic programming language with some new ideas

#61
post #14

Earlier quoted context omitted.

I know well what a FEXPR is (I was a Maclisp maintainer) but they are special forms. It is interesting to imagine inverting the sense of execution, but as you say it's hard to do much optimization.

They're special forms in a language where functions are something which eagerly evaluates its arguments. In a language where functions don't do that, they're just functions. Rye appears to be one of those languages. One could quibble about whether that's the right thing to call them, but if we say they're vau or whatever, "everything in Rye is a vau" is still true. I think calling them functions is reasonable though.

In Kernel, we could argue that operatives are the more fundamental type of combiner, and applicatives (aka functions) are the sole special-form, constructed by calling `wrap` on another combiner.

Re: Rye: Homoiconic dynamic programming language with some new ideas

#62
post #7
post #5

Earlier quoted context omitted.

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

Why is it difficult?

It's difficult to optimize because evaluation of expressions depends on the dynamic environment, which you don't have ahead-of-time.

You can't even assume `+` means "add the arguments", because `+` may have been bound to something completely different prior to evaluating the expression containing `+`.

Re: Rye: Homoiconic dynamic programming language with some new ideas

#63
post #52

Earlier quoted context omitted.

As done in Smalltalk.

Smalltalk may be influential, but is now rarely used. The code block approach is widely applied in two massively used industrial languages though: Ruby and Kotlin. In Kotlin specifically it's one of the very central features.

And Ruby has been strongly influenced by Smalltalk.

Anyway, if you want something perhaps a bit more used, you can check out Pharo. I think that is the most used Smalltalk-like language these days.

Re: Rye: Homoiconic dynamic programming language with some new ideas

#64
post #40

Earlier quoted context omitted.

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

> The way that ryelang gets around this is that you pass the arguments in a "code block" surrounded by "{}" Like Lisp’s QUOTE which has to be a special form.

Is this correct though? Lisp's quote would need some eval or something to evaluate later afaik. More fitting might be a (lambda () ...), a.k.a. lazy evaluation.

Re: Rye: Homoiconic dynamic programming language with some new ideas

#65
post #28

Earlier quoted context omitted.

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?

Hi, you can see a smaller example on ryelang.org front page if you ctrl+f "validation". Here are unit tests / reference for the validation dialect, but they aren't the best source of information: https://ryelang.org/validation.html Here is an old blogpost with another example: https://ryelang.blogspot.com/2021/01/added-intro-pages-for-h... It's a dialect with static/builtin rules that can be combined and two rules th…

It’s definitely an idea which I’ve seen people wish Haskell had. But requires some machinery that’s not quite in that language.

I guess it’s easy to express in a dependently typed language to an extent.

Re: Rye: Homoiconic dynamic programming language with some new ideas

#66
post #28

Earlier quoted context omitted.

Hi, you can see a smaller example on ryelang.org front page if you ctrl+f "validation". Here are unit tests / reference for the validation dialect, but they aren't the best source of information: https://ryelang.org/validation.html Here is an old blogpost with another example: https://ryelang.blogspot.com/2021/01/added-intro-pages-for-h... It's a dialect with static/builtin rules that can be combined and two rules th…

It’s definitely an idea which I’ve seen people wish Haskell had. But requires some machinery that’s not quite in that language. I guess it’s easy to express in a dependently typed language to an extent.

This validation dialect (and SQL dialect are main things) I used in all my web development for years using Rebol. So in Rye I made it part of the base builtins. It's nothing particularly special or complicated and could be improved to cover more cases.

I then had custom functions in Rebol that instead of argument list accepted this validation block and what it returned gor serialized into JSON and returned from the webserver. In case of valiadation error it also got automatically returned and sent back. So you defined such fucntions in a context and got an web accesible API and also you could call them on serverside to render something there (or fill in JSON directly into page that is served).

Function in Rebol (and Rye) also have a docstring and it's accesible within the language so these functions could also self-document. Show their description and validation rules if you called them with &_x=1 (as in explore mode).

Of course I tried to redo all this in Rye and make it even better for this.

Ok ... I got a little carried away ... :)

Re: Rye: Homoiconic dynamic programming language with some new ideas

#67
post #59
post #4

Earlier quoted context omitted.

Presumably as functions, the same way as excel? and(x, y) -> bool or(x, y) -> bool if(cond, funcTrue, funcFalse) -> void

if(and(or(cond1, cond2), cond3), effect1(), effect2()) In most languages, if `cond1` evaluates to true, you would not evaluate `cond2`. If `cond1` and `cond2` evaluate to false, you would not evaluate `cond3`. If all conds evaluate to false, you would not evaluate `effect1()`, and if `cond3` and either `cond1` or `cond2` are true, you would not evaluate `effect2()` They're not functions because they don't evaluate th…

I don't think that's what Rye is doing.

It's doing if(cond, effect1, effect2) where effect1 and effect2 are functions, and only evaluating the matching effect function. But everything is functions.

Re: Rye: Homoiconic dynamic programming language with some new ideas

#68
post #59

Earlier quoted context omitted.

if(and(or(cond1, cond2), cond3), effect1(), effect2()) In most languages, if `cond1` evaluates to true, you would not evaluate `cond2`. If `cond1` and `cond2` evaluate to false, you would not evaluate `cond3`. If all conds evaluate to false, you would not evaluate `effect1()`, and if `cond3` and either `cond1` or `cond2` are true, you would not evaluate `effect2()` They're not functions because they don't evaluate th…

I don't think that's what Rye is doing. It's doing if(cond, effect1, effect2) where effect1 and effect2 are functions, and only evaluating the matching effect function. But everything is functions.

technically effect1 and effect2 are so called "blocks of code" in rebol/rye/red/...

Everything being a function is trying to say that every "active word" (a word that does something ... print, first, if, fn, context, extends, ...) is just a function.

Re: Rye: Homoiconic dynamic programming language with some new ideas

#69
post #40

Earlier quoted context omitted.

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

> The way that ryelang gets around this is that you pass the arguments in a "code block" surrounded by "{}" Like Lisp’s QUOTE which has to be a special form.

I would imagine it is closer to lambda than quote (though also a special form), since the implementation of if would require that the bindings in the arguments evaluate to their values in the callers environment.

Re: Rye: Homoiconic dynamic programming language with some new ideas

#70

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.

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.

Post reply on HN