Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search

[REBOL] Re: Hitting the learning curve

From: Steven:White:ci:bloomington:mn:us at: 5-Nov-2003 11:56

>>> [gedb01--yahoo--co--uk] 11/05/03 03:49AM >>> >>>I've been throwing to gether 5 line scripts... >>>The problem is that, given a blank piece of screen, >>>where do I begin when devising my own code to solve my >>>own problems. What is the starting point.
I have exactly that same problem. I have used REBOL for little chores--moving files around the office, generating automatic email--but when I want to use it for something bigger my mind is blank as to how to start. Just last week I had an excuse to use it for something a bit bigger (but still small) so I have made a small crack in that barrier. Here is what I have so far, in case it helps. Languages are interesting not only for what one MAY say, but for what one MUST say. I come from a COBOL background ("The use of COBOL cripples the mind..." Edsger Dijkstra) so I'm used to having things that must be present, and must be in certain places, so I do that in REBOL to make myself comfortable. I also have found that the examples on the REBOL web site use words like "file," "data," and so on that trigger a reflex in my mind that says, "That's a reserved word," and that is confusing. So to easy my confusion I type all the REBOL words in lower case and all the words of my own invention in upper case, just like old COBOL. It is not recommended as a style, but it helps me personally. I hope that as I go along I can develop a collection of reuseable, or at least reconfigurable, scripts that I can call into my main program with the "do (script-name)" command. I have one so far, which is a language module. It contains every scrap of text that the main program will show in any way. The idea it that by isolating all text in one file, I could move the script to another language by translating that one file. I hope to write it up for the cookbook this week. The final form of a finished script will be something like this: ** The header ** "do" commands to bring in any reuseable modules ** "Declarations" of any configuration data items that the user might want to change. ** "Declarations" of all other data items. ** All screens, defined with the layout function, each followed by all the code that is run when the various controls are activated. ** The "main program" or "first executable instruction" to get the program running. With those preliminaries explained, here is how I proceed for a script that has a GUI screen and does stuff when you push buttons, etc. Draw out the screen, physically or mentally, so I have some idea of what I am trying to accomplish. Copy a skeleton of the REBOL header as my new script file, and fill in all the stuff. This just gets me warmed up, gets a little momentum going. Put in a "do %language.r" command to bring in the language file, which at this time is just a skeleton. (I'll put this "do" into the header skeleton eventually.) If I can see far enough ahead to know what data items I will be dealing with, I will "declare" them. This is not necessary in REBOL, but I like to do it to keep track of things. "Declaring" them is just setting them to some initial value in some standard spot in the script, so I can look back at them later and remember how to spell their names. This is like DEFAULT-FILENAME: FORMATTED-DATA: none and so on. As I go on, I will add more items. I also document each item in comments in the script so I don't forget what they are and use them for the wrong purpose. I tend to go overboard on comments, so I have heard from my co-workers. Then I define the(all) screen(s). I use just the layout function, as MAIN-WINDOW: layout [ (VID commands)... ] Now, when I set up any text, button, etc. in the layout, the text that is to appear is NOT coded as a literal in the layout. It is coded as a data name in the language file. For example: button 60x20 LMB-001 LMB-001 might refer to a value of "OPEN" in the language file. So during this layout development I also am making entries in the language file, like LMB-001: "OPEN" For any screen control that can cause some action, usually a button, I use a function call as that action. Even if the action is as simple as quit, I use a function call. This is because I like things tidy, and so that if that action becomes more complex, I don't have to rework the formatting of the script so much. For example: button 60x24 LMB-001 [BUTTON-ACTION] [inform LMH-001] In the above example, BUTTON-ACTION is a function in the script. The other action, "inform LMH-001," is the "inform" command which will display a help text on a right click. That help text is a layout in...the language file. So as I am setting up buttons, I am also adding items to the language file. I will define as many screen items as I feel like, just to get something that can be displayed. I won't necessarily do the full screen, or all screens, at this time unless I have a clear idea of what everything will be like, or unless I have a good head of steam. Then I define all the functions that were declared as actions on the screen. I just put in stubs for them, like BUTTON-ACTION: does [ ] This makes the script syntactically complete, although I believe this is not necessary--in other words, the script will run fine until you push the button with the missing funciton. But, I like things tidy, so I put in a stub for every action, and will fill them in later. Finally, I will put in the "first executable instruction" (or whatever your computing background calls it). This usually is something like view MAIN-WINDOW At this point, I have something that will bring up a screen, and do absolutely nothing. So I run it. Seeing it there gives me hope for the future. Then I start filling in the unwritten parts. Keep in mind as you read this that I am a beginner with a bias. Hope it helps. In spite of REBOL's "simplicity" I still find it strangely very difficult. Steven White City of Bloomington 1800 W Old Shakopee Rd Bloomington MN 55431-3096 USA 952-563-4882 (voice) 952-563-4672 (fax) [steven--white--ci--bloomington--mn--us]