Improving seccomp and landlock intergration into https://ryelang.org, improving tooling for making single executable files from rye projects, experimenting with reactive, declarative TUI library.
I was never an iOS user, or developer - exactly because Android was more "open", exerted less control over a user of the device.
The same reason I use Linux for 25 years (not ideological, but it just makes most sense by far). In time where this view (win11 vs. Linux) is starting to make sense to more and more people, few rare config nuances are getting easier to solve due to LLM-s, going into the opposite direction with a mobile OS calls for users to also start seriously considering more open alternatives and making a path for users of our app to do the same.
They're static lists that won't get updated unless we add to them manually. I'd love to make them auto-update (see https://news.ycombinator.com/item?id=46610744) but that might be too much to expect for now.
But it reminds me of the SEO guys optimizing for search engines. At the end of the day, the real long term strategy is to just "make good content", or in this case, "make a good language".
In the futuristic :) long term, in "post programming-language world" I predict each big llm provider will have its own propertiary compiler/vm/runtime. Why basically do transpiling if you can own the experience and result 100% and compete on that with other llm providers.
It's interesting how often there are similarities between Numshell, Rye and Lil, although I think they are from different influences. I guess it's sort of current zeitgeist if you want something light, high level and interactive.
Yes, a lot of REBOL ideas, that Rye took, or various functional, homoiconic langauges implement (haskell, lips, clojure, scheme, Io, Factor) come from search for greater internal consistency than your ALGOL-derived status-quo languages provide. :)
So degrading the core doesn't make much sense if you are not more specific. This is the core.
The `6` is the code, I just put the first thing that came to my mind there :D
In my example, if you replace it with a more sophisticated code block, R will evaluate it and print out the result of the evaluation.
Typically, you'd want to parse the unevaluated code, though:
> `if` = function(a, b) { print(substitute(a)); print(substitute(b)) }
> if (foo) { print("bar") }
foo
{
print("bar")
}
It overwrites `if`, in the current scope, of course.
Sorry, but I don't understand the example. In Rye, as in REBOL all first level block evaluations (do, if, for, loop, ...) happend in current scope (context).
Rye has first class contexts and it's one of more exciting things to me about it, but I'm not sure it's related to what you describe above. More on it here:
One thing that pops out at the example above is that I wouldn't want to define a y inside if block, because after the if you have y defined or not defined at all, at least to my understanding of your code.
Rye is constant by default, most things don't change and you need less veriables because it's expression based and it has left to right "flow" option. So you only make variables where you really need them, which is less common and specific, it should be obvious why you need a variable.
10 days later... sorry, I didn't see your comment.
The example I gave had a few pieces:
- x is defined prior to the if/else, and overwritten in just one branch
- y is defined in both branches
So in the rest of the function, we have both x and y available, regardless of which branch is taken.
I just took a quick read of the context page and the context basics page, but it's still unclear to me whether you can program how scopes/contexts interact in rye.
In my example, we I'd say we have a few different scopes worth mentioning, and I'm curious how programmably we can make them interact in rye:
Scope 1. Right below the first x = ...: we have names available form <beginning of the function> and have x available as the ... stuff. Presumably the `foo` in `if foo` lives in this scope.
Scope 2T. Right after the true branch's y, we have scope 1 plus y introduced
Scope 2F. Right after the false branch's x and y, we have scope 1 plus x "pointing to" something new and y introduced.
Scope 3. Below the if/else, where <rest of the function> lives. This is either scope 2T or scope 2F. x is either scope 1's x or scope 2F's x, and y is either scope 2T's y or 2F's y.
In the original articles language,
So the scope relationships in an if/else are a diamond DAG taking the names from before it, making them available in each branch's scopes, and then making a sorta disjoint union of the branch's names available afterwards. Could that be programmed in rye, to allow the kinds of naming ergonomics in my previous example, but with the if/else being programmable in the sense of the original article? I'm especially interested in whether we could overload it in the traditional autodiff sense.
Responding to a different part of your comment about using names rarely in rye, I've found that I benefit a ton from handing out names more than most people do in functional languages, just for clarity and more self-documenting code. Like, the ide can say "`apples` is broken" instead of "error in location xyz" and I can rebuild my mental state better too when revisiting code.
This is another subject but mathematical operators are and behave (for better and worse - there are also negative consequences of this consistency) like all other op-words, they just don't need . in front and correct, non-op-word is prepended by _.
12 + 23 ; is technically
12 ._+ 23 ; or not using op-word is
_+ 12 23 ; or if we bind function _+ to add
add: ?_+ ; we get
12 .add 23 ; and
add 12 23
It has downside because op-words don't behave exactly as math expressions would, but you can use parenthesis and we have a math dialect which includes full math precedence rules.
reply