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 R language has this feature as well. It's a whole lot of fun to work with.
Rye: Homoiconic dynamic programming language with some new ideas
31–40 of 86 posts
Re: Rye: Homoiconic dynamic programming language with some new ideas
#32Earlier 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…
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.
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.
Re: Rye: Homoiconic dynamic programming language with some new ideas
#33Earlier quoted context omitted.
The R language has this feature as well. It's a whole lot of fun to work with.
Likewise in Tcl where blocks can either be sent quoted (using {}) or unquoted (using “”). In the latter, variables and procs will have a round of substitution performed before being passed to the proc.
Re: Rye: Homoiconic dynamic programming language with some new ideas
#34authority = [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.
Re: Rye: Homoiconic dynamic programming language with some new ideas
#35familiar 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
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 con…
Could you perhaps summarise how contexts work in Rye? On the Ren-C forum we’ve recently been discussing binding a lot, and I’d be interested to learn how Rye does it.
Re: Rye: Homoiconic dynamic programming language with some new ideas
#36Re: Rye: Homoiconic dynamic programming language with some new ideas
#37The 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 (j…
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.
Re: Rye: Homoiconic dynamic programming language with some new ideas
#38Congrats, this language looks pretty cool! What advantages does it have over, say, something like Elixir?
Re: Rye: Homoiconic dynamic programming language with some new ideas
#39Seems 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)
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! ;)
Re: Rye: Homoiconic dynamic programming language with some new ideas
#40> 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 ?
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.…
Like Lisp’s QUOTE which has to be a special form.