Home   Archive   Permalink



Definitional Returns Solved in Ren/C, Trello

In what I consider to be the most satisfying achievement of Ren/C to date, I'll announce that I consider the nuanced problem of definitional returns to be 'solved'.
    
Of course, it's early yet...having just been made...but it definitely has 'the right stuff'. It's a good time for review, so here's a post on the subject:
    
http://codereview.stackexchange.com/q/109443/9042
    
So feel free to dust off your Rebol thinking caps and see if anything comes to mind.
    
I've been asked to write announcements. I've mostly wanted to hold off anouncements until I could speak to the accomplishments of someone besides myself in it... due to the great work by Brett Handley on getting native spec code into the C source as Rebol processed in the comments, or by John Kenyon on the importation of the CureCode database to GitHub.
    
But one of the largest holdup in getting to those announcements is being unaware of where Andreas has vanished to--as he is the one who holds the keys to GitHub rebol/rebol at this point. So if anyone could get in touch with him that would be a great help.
    
In the meantime, I hope the definitional scoping announcement will hold people over. There is also the Ren/C Porting Trello that describes many things as the initiative goes on, including a card for this:
    
https://trello.com/c/4Kg3DZ2H
    
It is difficult to keep the Trello in sync with the work, and there are some things that get added and are later reviewed and removed in favor of a better solution. So it's all a tremendous amount of time.
    
I'd like to thank everyone who has lent their support and hopefully there'll be a lot more to say soon.

posted by:   Fork       1-Nov-2015/19:18:53-8:00



I should of course also mention the work by Giulio Lunati on building for Android!
    
So if you were curious if there's a Rebol you can use today on Android that has all the Ren/C-isms like HTTPS and now has definitionally scoped returns...indeed, there is one!
    
http://giuliolunati.altervista.org/r3/
    
So that is not a premature announcement. :-)

posted by:   Fork       1-Nov-2015/19:22:51-8:00



Huzzah! You people amaze me. Congrats!

posted by:   Edoc       2-Nov-2015/17:12:38-8:00



Wow, you are digging deep.

posted by:   Nick       4-Nov-2015/5:39:30-8:00



Deep is what it takes to tackle the foundational problems of the language. Imagine if you feel that the choice of UNTIL being arity-1 is not good, and you want one that is arity 2:
    
     better-until: func [condition [block!] body [block!]] [
         while [not do condition] body
     ]
    
It might seem like it works okay at first:
    
     >> x: 0
    
     >> better-until [x = 3] [
             x: x + 1
             print x
         ]
    
     1
     2
     3
    
But then try using a return...
    
     >> test: does [
             x: 0
             better-until [x = 3] [
                 return "we'd like test to return this"
             ]
             "but it returns this, not good"
         ]
    
     >> print test
     but it returns this, not good
    
It's the sort of problem that has far-reaching consequences, and has needed a good solution--vs. just a tacked-on hack.
    
But I really do believe the wait for that solution is now effectively over. It's fixed, and fixed in a clean way. And importantly: a pattern for how to *not* build in RETURN as a keyword has laid a map for how to get rid of other things that shouldn't be keywords (like the evil SELF).
    
Things are moving at a good clip now, and some new demos forthcoming.

posted by:   Fork       4-Nov-2015/9:41:39-8:00