REBOL 3.0 Front Line

REBOL 3.0 Front Line http://www.rebol.net/cgi-bin/r3blog.r A place for publishing comments and discussions about REBOL 3.0. en-us Carl Sassenrath 2010 REBOL Language Discussion about error handling http://www.rebol.net/r3blogs/0309.html http://www.rebol.net/r3blogs/0309.html no-spam@rebol.com (Carl Sassenrath) Sat, 6 Mar 2010 02:47:32 -0500 In the REBOL3 group on the REBOL3 world, there's been some discussion about error handling. Here's a document about it to read and comment on. Once we've discussed it, we can take it from there and determine what needs to be done to wrap it up. IMPORTANT: R3 Chat server problem - restarted! http://www.rebol.net/r3blogs/0308.html http://www.rebol.net/r3blogs/0308.html no-spam@rebol.com (Carl Sassenrath) Fri, 12 Feb 2010 14:31:08 -0500 Yesterday, when testing R3 on Windows 7, I had a problem with R3 Chat (DevBase). When downloading the message base, it would timeout. I remember this problem was fixed back in April of last year! Checking with the info command, it confirmed my concern: the server was running an older version! Apparently, when the hardware was rebooted on Nov 17, it restarted an older version of the DevBase server. This was the one that made it difficult for new users to sync up on the message base. Unfortunately, I did not see any messages from users about this problem... and it makes me wonder how many new user accounts were successful syncing up. \note So, please note: If you tried to use R3 Chat over the last couple months, and it failed, please try again now. /note Plans for A98 with Host Kit changes http://www.rebol.net/r3blogs/0307.html http://www.rebol.net/r3blogs/0307.html no-spam@rebol.com (Carl Sassenrath) Mon, 8 Feb 2010 13:26:05 -0500 If you have inputs regarding the R3 Host Kit, please make sure we know about them. Actually, it would help if we can get someone collect and sort developer comments, notes, and any changes... otherwise something may get missed. This includes inputs/changes on the R3 makefile (e.g. Kaj's feedback). The sooner we get the list organized, the sooner we can get A98 out. Don't post the list here, upload it as a text file to the R3 Chat #358 topic "R3/Plans/Priorities". (Reminder: To post a file use the submit command while within the 358 topic.) Comma as a delimiter in some special cases? http://www.rebol.net/r3blogs/0306.html http://www.rebol.net/r3blogs/0306.html no-spam@rebol.com (Carl Sassenrath) Sat, 6 Feb 2010 15:56:08 -0500 As you know, REBOL does not use commas. This design decision is critical to the foundation of the language. In REBOL we write: [1 2 3] not: [1, 2, 3] Why? Simple, because we want to write: [1 + 2] not: [1, +, 2] Think about that carefully. In REBOL data can be code, and code can be data. Commas would prevent that concept from working properly. This property makes REBOL quite special and unique in the world of programming languages. So, it's fundamental. Now, ticket #537 requests a change to the lexical analyzer to give higher strength to commas. Several people have asked for it over the years. What's desired is if someone provides data in the form: a, b, c We can easily use the REBOL scanner to parse it without too much trouble. I spent some time today looking into this request. It's possible, but non-trivial. While comma doesn't have any special significance in the lexicon, it is used for non-English style decimal points... worldwide. That is, in REBOL: 1.23 = 1,23 People in the USA freak out on that, but if they travel to say, Paris, after the initial shock, they get the idea. I suppose it works the opposite direction as well. Anyway, comma is not a delimiter in REBOL, it's just a special character used for numbers. Now that all that's clear, can comma be made a bit stronger to act more like a delimiter? Perhaps. But, we'd need to resolve this ambiguous case: [abc,123] Which of these lines would be the correct result? [abc 123] [abc 0.123] **error: comma found in expression Now, what happens if we write: [abc,123,456] Hmmm. You begin to see the problem, and it's non-trivial because comma means two different things here. So, after some thought, I think we're better off leaving such lines to be processed as strings by parse and keeping the REBOL lexical analyzer as it is. Those tricky < and > characters http://www.rebol.net/r3blogs/0305.html http://www.rebol.net/r3blogs/0305.html no-spam@rebol.com (Carl Sassenrath) Sat, 6 Feb 2010 13:29:22 -0500 \note A97 Fixes Release A97 should fix most or all of these related issues. Please try it out. /note In the REBOL lexicon, the < and > "arrow" characters are special, and must be scanned (lexically analyzed) in special ways. To understand the situation, notice that arrows denote two datatypes, word! and tag!: >> type? second [a < b] == word! >> type? second [a > b] == word! >> type? second [a <> b] == word! >> type? second [a b] == tag! To avoid problems, we don't allow arrows to be part of most words. This avoids creating ambiguous lexical sequences such as: a Are those arrows as words or are they part of a tag? To simplify such cases, we restrict the usage of arrows when used for words. We allow these words: < >> >= > If you attempt to use arrows within words in general, you'll see an error: >> a< ** Syntax error: invalid "word" -- "a<" ** Near: (line 1) a< However, we do want to allow this common markup usage in a sensible way: >> [word] == [ word ] So, that's even more tricky to scan. Now, all this being said, we know there are a few minor bugs related to arrows in the scanner. They are listed in the R3 CureCode bug database, and they will be fixed. For example, we need to allow lit-word quoting of arrow words: >> if word = '< [...] ** Syntax error: invalid "word-lit" -- "'" ** Near: (line 1) if word = '< [...] But, I simply wanted to point out this issue, so it is understood that arrows are not general-usage word characters. MOLD vs TO STRING! http://www.rebol.net/r3blogs/0304.html http://www.rebol.net/r3blogs/0304.html no-spam@rebol.com (Carl Sassenrath) Fri, 5 Feb 2010 01:18:25 -0500 There is a proposal in Ticket 1404 to make mold and to string! produce different results. Example: >> mold #a == "#a" >> to string! #a == "a" I like this idea, because it gives users a simple, easy-to-remember choice for removing specific datatype notations. Let me know what you think. R3 A97 will be a bug fix build http://www.rebol.net/r3blogs/0303.html http://www.rebol.net/r3blogs/0303.html no-spam@rebol.com (Carl Sassenrath) Tue, 12 Jan 2010 16:37:37 -0500 The A97 build is intended to fix some of the CureCode tickets that have accumulated. If you have a critical "show stopper" bug (meaning it stops you from testing or using R3) make sure I know about it by posting a note on R3 Chat. BTW, this is a good time to mention that the new REBOL.com WIP Wiki website is built with R3. I can't wait to move this blog system into it. "Step by step." Post your favorite new PARSE examples http://www.rebol.net/r3blogs/0302.html http://www.rebol.net/r3blogs/0302.html no-spam@rebol.com (Carl Sassenrath) Wed, 23 Dec 2009 13:37:12 -0500 With so many new parse features in R3, various types of operations should be documented as simple examples. For example, while working on website revisions I wanted to use R3 to strip out some of the obsolete HTML tags, such as the old FONT markups like: About REBOL's Technology And, in fact, all such FONT tags and end tags, regardless of attributes. Here's the parse code I used. It also shows how to make two passes over the same file because some of the end tags may not be properly paired. parse page [ top: while [to ""] :top while [to "" remove thru ">"] ] Notice the use of while rather than some. This is important because remove causes the position index to not advance. See the new note in Parse Summary about this. Now, I invite you to post your own useful little R3 parse examples. Thanks. We'll collect some of them for use as examples in the parse documentation. Host Kit for Linux released - More to follow http://www.rebol.net/r3blogs/0301.html http://www.rebol.net/r3blogs/0301.html no-spam@rebol.com (Carl Sassenrath) Sat, 12 Dec 2009 13:50:45 -0500 The R3 Host Kit allows developers to compile and link an R3 executable. Yesterday the first Host Kit for Linux was released. Next, we'll work on OS X, but it doesn't use the .so shared lib model, so it may take more time to get it released. Here's a summary of Host Kit releases: :Windows32 - Released. Developers confirm it builds and runs. :Linux (lib6) - Just released. Contact me on Chat if you want to test it. :Linux (Fedora) - Just released. Ditto. :OS X (Intel) - Pending. If you're an OS X guru, contact me directly (chat or feedback) :OS X (PPC) - Pending. Same note as above. :FreeBSD - Build. Contact me if you want it. :Amiga - Pending. :iPhone - contact me (if you have experience) :Android - contact me (if you have experience) Modules: another EXPORT method proposed http://www.rebol.net/r3blogs/0300.html http://www.rebol.net/r3blogs/0300.html no-spam@rebol.com (Carl Sassenrath) Wed, 9 Dec 2009 15:28:09 -0500 In R3, modules are easy to create. I've got one for generating HTML pages of all sorts, including web forms for various sites. The module is small, useful, easy to maintain... and before long it will be an integrated part of all the web site WIP wikis (once they move from R2 to R3.) The HTML module is defined with the header: REBOL [ Title: "HTML Formatting Functions" Type: module Name: html-emit Version: 1.2.2 Author: "Carl Sassenrath" Exports: [reset-html emit emit-tag emit-link ...] ] However, there is a practical matter to consider: I really don't want to maintain the Exports field directly. There are more than 30 words in it. Some of you know that this issue has been on my mind for several years. In my original modules proposal (long ago) I made serveral suggestions. For example, the header could specify what not to export, then export everything not on that list. Another solution, one to think about... is to add a keyword into the module making method. The word would be used like this: export emit: funct ["Emit HTML... The meaning of export is only important at module load time, where it is used to declare what names are exported. This method works well, because the module's loaded source block is no longer relevant to future evaluation. So, the export words are non-functional. The main advantage is that the export declaration right next to the function it exports, making maintenance easier. An alternative that I should mention, because someone will no-doubt mention it anyway is: #export emit: funct ["Emit HTML... But, I don't like that as much because issues are not words, they are strings and each one eats memory, where as a word, it wouldn't require any extra memory. (But we need to finish that discussion soon... before alpha is over!) This export method isn't a change we're going to be making this week, but we need to get your comments, because it will happen sooner or later! Once you start writing more modules... you'll know what I mean. Next stage. Dialects vs functions. Graphics API... more. http://www.rebol.net/r3blogs/0299.html http://www.rebol.net/r3blogs/0299.html no-spam@rebol.com (Carl Sassenrath) Fri, 4 Dec 2009 13:16:13 -0500 The next stage of the host kit are the graphics-related interfaces -- those implemented as the draw, richtext, and effect dialects. Because these sources are to be part of the host kit, they need to be isolated in the same way that we isolate extension functions. Therefore, they need to be implemented similar to extensions. This was, in fact, part of the plan while building the extension architecture. In order to make this work, the command! datatype requires extensions for optional-args-by-datatype. So, it turns out, this greatly parallels the action of delect. Therefore, in the name of simplification, I don't want both. So, delect will be modified to work with command! blocks, and commands will be improved to provide similar capabilities. I should mention that the motivation for this change comes from more than just this specific situation related to graphics. It's a bit of an admission that for many interfaces, functional forms are adequate - full grammars are not required in such cases. The roots of this theory and discussion go far back in REBOL history to private debates comparing Rugby (RPC-like) and REBOL/Services (dialect based). Although dialects are generally more powerful, the simple and regular form of functions has benefits too. Some of this "discovery" comes through what I've learned in implementing many distributed system architectures. This includes not just R/S, but IOS, AltME, DevBase, and RebDev (Chat). During the refactoring stages of RebDev Chat, its communication grammars collapsed into a functional form, with just a few small additions (optional args, repeated args, default values, and binding of the functions into context.) It occurred to me that these features were nearly identical to what dialects like draw were implementing via delect. In fact, if you probe system/dialects/draw you'll see the dialect grammar is nearly functional. So, in conclusion, it's best not to support both. Adding more power to the command! datatype for better support of extensions will obsolete the the object format used by delect. It's best to bite the bullet now and make the change rather than let it extend past this alpha test stage. More info soon. I really hope this can be done quickly, and we can move into full support for graphics development and porting it to other systems like OS X, X11, etc. This is also the method to be used with REBOL/Services 3.0. R3 Host Kit prototype released http://www.rebol.net/r3blogs/0298.html http://www.rebol.net/r3blogs/0298.html no-spam@rebol.com (Carl Sassenrath) Wed, 2 Dec 2009 18:56:35 -0500 The R3 Host Kit makes it possible to build REBOL from a set of host source files and the REBOL library (DLL). The Host Kit release is divided into several development stages. This is the very first stage, so I'm calling it a "prototype"... simply because it's only been compiled here so far, not by anyone else. This release goes to just a few developers to verify that it is buildable and to work out any serious issues within a small group, just to keep it manageable. But, don't worry. If you're champing at the bit (npi), you'll get a copy later this month when we've got any gotchas worked out. Too much time has gone into trimming and simplifying the host kit. With the current source code and makefile, I can quickly compile and build a REBOL executable using a bare bones WinGW C compiler. That feels good. I kept it very simple because I like to abide by the adage that the best systems begin as simply as possible. Why? Because they only get more complicated from there. Systems never get simpler -- only more complex. A95 jump in size due to compiler optimizations http://www.rebol.net/r3blogs/0297.html http://www.rebol.net/r3blogs/0297.html no-spam@rebol.com (Carl Sassenrath) Tue, 24 Nov 2009 01:53:21 -0500 As an experiment, A95 was built with compiler optimizations enabled. Normally, the alphas are not optimized. This change increases the executable file size by about 75K, in case you were wondering why it grew. Watch for any odd behavior due to the optimizations. (Yes, it can happen.) R3 Math Speed http://www.rebol.net/r3blogs/0296.html http://www.rebol.net/r3blogs/0296.html no-spam@rebol.com (Carl Sassenrath) Mon, 23 Nov 2009 20:17:32 -0500 Ticket #0001338 suggests that math speed is reduced in R3 as compared to R2. Let me comment on that. First, all R3 releases are alpha test builds which means they're not optimized builds. However, if I enable compiler optimizations, I see that R3 is slightly faster than R2. Using the example code that was posted (fair code because it is 64 bits in both R2 and R3): a: 1.0 b: 2.0 dt [loop 20'000'000 [a + b * a / b]] The timings on x86 in XP are: R2.276: 0:00:14.062 R3.A94: 0:00:14.218 (no opts) R3.A95o1: 0:00:13.920443 (some opts) R3.A95o2: 0:00:13.858737 (more opts) So, for now, while in alpha, let's focus on the last few language-related elements of R3, so we can move to the next release stage. Also, for higher performance math, rebcode functions should be available in R3.1. And, if the R3 developer community feels inclined to support compiled functions (yes, such support would be in the host), greater levels of performance could be achieved.