ryelang

I read an interesting article . In it the writer is trying to send "code" for remote drawing over the websocket and execute it on the receiving end. He is doing it in JavaScript, but to demo the useful nature of lisp code structure (brackets). He can't just send Javascript code and eval() it to do this, as you can't seem to really limit and control the the eval's context. So he makes a simple interpreter of a lisp like structures. In Rye contexts/scopes are first class values. While making them I created a function isolate , that creates an totally isolated context. Let's try to use it to create something similar without the need to make a separate interpreter. The receiver in the article draws graphical primitives to the screen, our will behave like some sort of old school printer. First instruction Fist the writer tried made calling one instruction possible. In his case it was drawLine, we will have a function print . ?word is a get-word. It returns the ...

I think providing a distinction between ordinary and pure functions has benefits and adds a little to certainty. Besides being sure that a branch of calls is referentially transparent I also nurture this idea of mobile code . And the first candidate for mobile code are pure functions, as you can run pure remote code with much less worry since there are no side effects. There is still a halting problem, but can be solve on interpreter level I think. Imagine communicating with a map-filter-reduce server also written in Rye and instead of translating requests into it's query language you can just sent it your pure functions for map/filter/reduce and get the result. The implementation is quite simple. All pure builtins have a Pure flag set and pure user functions can only call pure builtins or other pure functions. I didn't like the idea, that interpreter would need to always check the flags of all builtins and functions when evaluating the pure function. I figured out a way that ...

I had a lot of work elsewhere for past 2 weeks. Working full days with a very painfull XML/EDIFACT standard - don't ask.  This was to be a small uneventful coding session, just to add word some to the validation dialect, so I can validate a list of dicts directly from the initial example . I also added few other basic functions and it became quite fun after I decided to also add new word pipe . Pipe is what I will now call factor-isms . Features, that at least partially try to mimic cool (stack based) features or benefits of Factor lang . Factor (as other stack languages) have this interesting feature that you can directly cut a slice of words from existing code and without change define a new word that substitutes the slice. It's nice for re-factoring ... I suspect it even has something to do with the name. pass that I used below is another, old rye's factor-ism. It's a little like keep combinator for non-stack languages :) This is all quite specific stuff, if you wa...

If I want to make Rye example from the Emacs screenshot work ( previous post ), there is quite a list of boring stuff I need to do next. Things that weren't main language design questions so I was jumping over them so far, now have to be done. One of them is concrete handling of JSON data. Rye is meant to be a practical language, and good at back-end / data exploration tasks. So handling of bigger JSON files should work and be efficient. That is why we don't want to load, for example, a big JSON and convert it to all boxed Rye values until we really need to. Rye has an associative datatype (like JavaScript's Object) in the form of Context . And the series datatype (like Array) in the form ob a Block . But rye also has 2 more native types, that are currently named Dict and List . While context's keys are indexed words, Dict uses ordinary strings and not even Rye-s boxed strings, but unboxed Go-Lang strings. Same is for list, it's a Go slice of unboxed Go-Lang value...

Rye is an experimental, you can call it a toy, programming language still very much in development. I am not worried about doing everything or anything right at this point. Who determines what is right anyway? The status quo. There is nothing wrong with current state of things per se, but it's been and it's being explored enough without me. I'm also not saying that Rye is that much different, better or anything ... Up to this point I was developing Rye mostly in private. Now that I roughly built the last two ideas I had for the first version (kinds and converters), I decided to start writing this blog. Maybe some odd of you will find it interesting :). I am still mostly designing the language, the implementation is just something I could test the ideas with, but first version of it will also slowly need to come together. Visit the work in progress website for more info, code and links. Go code for interpreter is on github . I was posting in developments screenshots / demos...