Rye details - let the jack go

This is a second post in a series. Click here to read the first one.

Modifier functions

So, when we have to, how do we change values of words outside our current context? The answer is "Explicitly".

Rye has a limited number of functions that change values of words in-place. They all end with exclamation mark. These functions currently are:

change! - changes a value and returns true if value was changed
inc! - increments a value in-place (like i++)
append! - appends a value or a block of values to a series in-place
purge! - higher order-like function that removes items from an series in-place

Ordinary functions in Rye don't change their arguments in-place. Rebol's and Python's functions or methods are more mixed bags about this. Append in Rebol both adds a new value to the existing series and returns it. Python's list.append() returns None and modifies the existing list.

Rye prefers expressions (not statements). Expression is something that returns a result rather than changes the state. Unless we literally want to modify a value/state or if the reason is optimization, we in Rye write expression based code.

Modifier functions can access the words in the same manner as the evaluator looks up ordinary (read) words. They search for a word in the current context and recursively in parent's contexts until found (or fails).

So we could make something like this:

Modifier functions still don't allow us to change values inside sub-contexts. In fact, there is for now no way to do that.

You can always call ...

We can't change values in contexts from outside, but we can call into them. That's currently a desired limitation.

Smells like objects

Rye is not an object oriented language. It tries to lean towards functional concepts, if we need to be taking sides. Contexts could be used like objects, to encapsulate functionality and state, but that is not the usual or preferred code/state organization method.

I usually separate code and data. There are better types of Rye values for data like lists, dicts and dataframes (tables). And there is a concept of generic methods and kinds, which more resembles CLOS (Common List Object System) if you need dispatch. We won't go there now.

If the bull went, let ...

There is a saying in Slovenia "Če je šel bik, pa naj gre še štrik" - try to translate that :).

Just to show some more general context behavior, we could achieve something like inheritance in two ways (that are not there for inheritance's sake).

There will be no talk about fake object systems in the next posta about contexts.

Follow Rye's development on Github.

Komentarji

Priljubljene objave iz tega spletnega dnevnika

Less variables, more flows example vs Python

In the last blogpost ( Less variables, more flows ) I wrote a quick practical script I needed. It was an uncommon combination of CGI, two GET requests with Cookies and a POST request with Authorization header. I really like practical random/dirty problems, rather than ideal - made up problems to test the language. To get a sense of comparison I rewrote the example 2 times while removing specific Rye features. But that comparison is meaningless to a person that doesn't know Rye or at least Rebol already. So I went on fiverr and made a request for a Python script with these requirements. I got a nicely written Python script that uses functions for each step. To be more comparable, I rewrote the Rye code to a similar structure. Below is the result ... For a next step, it would be interesting, to extract a little simpler example out and add error handling. With Rye-s specific failure handling, I think the difference would become even greater. You can find Rye on github .

Preberite več

Ryelang - controlled file serving example and comparison to Python

This is as anecdotal as it gets, but basic HTTP serving functions in Rye seem to be working quite OK. They do directly use the extremely solid Go 's HTTP functions, so that should be somewhat expected. I made a ryelang.org web-server with few lines of Rye code 3 months ago and the process was running ever since and served more than 30.000 pages. If not else, it seems there are no inherent memory leaks in Rye interpreter. Those would probably show up in a 3 month long running process? And now I got another simple project. I needed to make a HTTP API for some mobile app. API should accept a key, and return / download a binary file in response if the key is correct. Otherwise it should return a HTTP error. So I strapped in and created Rye code below. I think I only needed to add generic methods stat and size? , all other were already implemented, which is a good sign. Of course, we are in an age of ChatGPT, so I used it to generate the equivalent Python code. It used the elegant

Preberite več

Receiving emails with Go's smtpd and Rye

This goes a while back. At some project for user support, we needed to receive emails and save them to appropriate databases. The best option back in the day seemed project Lamson . And it worked well ever since. It was written in Python by then quite known programmer Zed Shaw. It worked like a Python based SMTP server, that called your handlers when emails arrived. It was sort of Ruby on Rails for email. We were using this ever since. Now our system needs to be improved, there are still some emails or attachments that don't get parsed correctly. That isn't the problem of Lamson, but of our code that parses the emails. But Lamson development has been passive for more than 10 years. And I am already moving smaller utilities to Rye. Rye uses Go, and Go has this nice library smtpd , which seems like made for this task. I integrated it and parsemail into Rye and tested it in the Rye console first. Interesting function here is enter-console , that can put you into Rye console any

Preberite več

ryelang

Preišči ta spletni dnevnik