Activity: Commentary

General:Glee is a work in process. Activity on the project is never expected to stop. There remain several features undocumented. These are steadily being revealed with documentation and examples. There is new development effort in areas such as files, threads, and distributed processing. As these become workable, they will also be documented and illustrated. These activity reports won't necessarily be daily but they will align with code and documentation postings. I hope you will return frequently to follow the progress. Glee is really starting to look like a real language. It won't be much longer and I'll be showing how to do real work with it through case studies.





1/5/2003 - 2/2/2003: Addition of Intersection and Union prompted a rethinking of the glyphs. These are the changes:

Operation V Now Was
Larger of D >> |
Largest M \>> \|
Running Largest M />> /|
Moving Largest  />>  /| 
Shift Right One M >-> New
Shift Right n D >-> >>
Rotate Right M >%> New
Rotate Right n D >%> %->
Smaller of D << &
Smallest M \<< \&
Running Smallest M /<< /&
Moving Smallest  D /<<  /& 
Grade up M ``> >>
Grade down M ``< <<
Shift Left One M <-< New
Shift Left n D <-< <<
Rotate Left One M <%< New
Rotate Left D <%< %<-
Reshape D %% New
Flip M >%< %<- or %->
Unique M & =
Intersection D & Smaller of
Bool And D & no change
String Words M \& \&
Bool Running All M /& Was Smallest
Bool Moving All  D /& Was Running Smallest
Bool Running Any  /|  Was Largest
Bool Moving Any D /|  Was Moving Largest
Indices of Unique M ``& ``&
Absolute Value M | |
Union D | Larger of
Bool Or D | No change
String Paragraphs M \| New
Bool Mark Start M *< no change
Mark LT D *< New
Mark LE D *<= New
Mark EQ D *= New
Mark GE D *>= New
Bool Mark End M *> no change
Mark GT D *> New
Mark equal D *~= New
Bool Mark On Off M *<> New
Mark Contains All D *^& New
Mark Contains Any D *^| New
Equal D = Mark EQ





7/13/2002: There are still many details left to implement and document on File Contexts. I return to them later. Work now will again move to the debugger.




6/28/2002: The operator spacing diagnostic has caused several examples to begin failing. I am having to go back, locate code, and space out the operators, This looks to be taking about 2 days.




6/27/2002: If you look at the Glee test stand form you find "X" "I" "S" "C" "T" and "G" buttons. These are the Program Debugging Buttons. The "G" (for GO) is the only one hooked up. I'm now hooking up the others. The interpreter was tightened to given an error if you don't space between operators. This did not use to be restricted but it led to dangerous mistakes. So now, you must space between operators. For example "7/-" will give an error. It must be "7/ -".




6/26/2002: This upload contains the read only version of the file system. It has been lightly tested but relies heavily on string streams that have been more thoroughly tested. This version immediately converts the entire contents of a file to a string object. It then delivers streaming services. An arbitrary 1MB limit has been imposed on the file size. Ultimately, true streaming will be supported and this quick kludge will be abandoned. The documentation is admitedly weak and will improve steadily with time. I am anxious to get sockets working so Glee can really begin to show its colors. Another excuse for delaying further work on the file system is the planned way of dealing with files in Glee. Rather than dealing directly with physical media, Glee will ultimately deal with a service that does the direct interfacing with the physical media. This will allow much greater control over the media in terms of security and shared access regardless of the host file system. To allow this I must visit interprocess communications and sockets. If anyone is watching and has specific questions about the files I welcome them. I will take these as guides for directing and improving the documentation.




6/25/2002: Work on the file system facilities is not yet complete. Right now the system is read only. When a file is accessed, the complete file is read into a string (1M limit right now) and all subsequent requests for data are served out of that buffer using stream and indexing facilities. This will get me by for now and allow experimentation with read-only type Glee applications. In the end, I expect the file system to be a separate service rather than a conventional operating-system-based shared disk store. This will allow me to do all kinds of things not possible with most operating systems but will allow me to adapt to virtually any operating system's files. The file system is now working and I'm going through my testing for the next upload which should be shortly.




6/18/2002: Well, it has been a long pull and I still haven't reached my objective with files. String streaming is complete and working. I still need to annotate the examples and do much work on the tutorial. In the mean time, streams should be fairly self explanatory without it. The File Context work is fairly complete. The File work still needs to have streaming hooked on to it. I was getting impatient with myself for an upload. I am no longer discovering bugs but my testing has not been exhaustive. If you see some, give me a shout. With a more current upload, I can deal with them quickly. I wish I could create this stuff as fast as you'll be able to go through it and grasp it.




6/16/2002:A huge amount of work has been accomplished since the last upload (1.0.1.39). But since virtually no one is paying attention I'm not feeling pressure to upload what I have. Streams in strings is working but I'm still finding obscure annoyances as I try to do real work with them. That is causing some refactoring, regression, and redocumentation. Once that is done, the file system is ready and waiting to have streams "hooked on".




6/12/2002: Streams are a mechanism for slewing through strings and files. There is quite a lot to them although the concepts and usage are very simple. With the next upload I will begin documenting the streams. I will use strings for the examples as they require no hooking up. I will then extend these examples in abbreviated form to files (using these web pages as the files) so you can get a feel for how using streams with files is just as easy and consistent with their operation on strings.




6/10/2002: I have done quite a bit of refactoring in adding streaming operators. I never come up with something I like on the first try. I also have to reduce things to a small suite of functions that build on each other and collaborate ... that takes some sculpturing. It should not take too much longer. There are a couple dozen new operators but they are easy to learn because knowing what the glyphs mean, you can read them directly. For example "@" means set cursor at and "->" means end so "@->" means set cursor at end of stream. Similarly "@<-" means set cursor at beginning of stream. "->>" means next and "<<-" means previous. "&" means all and "|" means any so "var @<<-& 'GLEE' "moves the cursor to the previous instance in the variable "var" where all the characters of the string 'GLEE' match up Gleefully. Files work in the same way using the same operators. Thus using files is also very natural and intuitive. I hope you will find it to be worth this long wait.





6/5/2002: It has been a little too long between uploads but the work on the file system has taken several iterations. It also became obvious that a file was just an outboarded string. My strings didn't have streaming. Files have to have streaming. So the logical move was to make strings stream and then make files look like virtual strings. That requires (1)major changes to the string object (e.g. it needed state variables); (2) a design for the streaming operators (lots of cut and try there to come up with an intuitive suite of glyphs); and then (3) complete regression (strings touch everything in Glee). Thanks for your patience. I hope you are still looking in. Note: some of the links in activity items after 5/14/02 are invalid ... I have not uploaded those pages yet. I will upload them when I have things settled and working. Otherwise you would have to watch me change my mind ... that is like seeing sausage made. So until I stop changing stuff, you will get some 404: File Not Found errors.




5/14/2002:I've been fiddling with Record Sets too long. I think something like them is needed but I don't know if this is it. I'm going to leave the current work as admittedly crude and move on. I will return when I start writing the case studies and then see if I like what I've done here. My objective was to provide a robust yet simple to use mechanism for maintaining heterogeneous data in a table with mnemonically addressed fields (columns).




5/1/2002: Record Sets. Fix Grade Bug: The grade bug came about when I tried to fix a minor problem (it wasn't stable in some cases) but I created a major problem (grade in some cases did nothing at all). I think I've got it now. The Record Set work is totally experimental and definitely work in progress. This is more than just getting documented... it's getting created. I try to keep the examples and tutorials running at all times ... that is my regression. Doing things not documented will likely not work, even though they logically should. Eventually they logically will. I don't want to make a career of these Record Sets but I do want to get some fundamental functionality. More than with the rest of Glee, but as always ... you're traveling at your own risk here and now.




4/26/2002: Record Sets: Record Sets as I have introduced them here are very rudimentary. They just give a facility of managing a table of records of fields. These kinds of facilities can absorb a huge amount of code to handle all the error conditions and support all requirements. I haven't gone to that trouble yet and it will probably be a while before I do. For now, Record Sets are a facility that can help you a little bit with the mnemonic management of data. But the correct management remains your responsibility. All I do is keep the number of fields in the records matching the number of Record Set fields. As I write case study applications that need record set features, I will add those features.




4/22/2002: Abandoned ...== operators. Glee tries to keep things simple for those who can live with simple. For the most part, trying to find strings in documents requires liberal matches. Thus case, redundant white space, and special characters can be ignored. But there are times when you can't tolerate these loose compares. Initally, I appended "==" to operators to designate the need for exact compares. For example, the contains operator ("^&") became ("^&==") for exact comparisons. These created all kinds of combinations for operators and some unneeded code. I have decided there is a better way. I am now implementing a new way. The new solution is to tag the object with the compare intention. This is done with the "@==" operator for exact compares and the "@=" operator for the more liberal Glee compares. These operators are monadic and do nothing but mark the objects on their left. Subsequent operators then interrogate this mark to decide on their behavior. When objects are created, they are marked for Glee compares. For exact compare use combinations like ("abc" @== ^& "abc"). For Glee compares, if you think (or know) the object is marked for exact compare use combinations like ("abc" @= ^& "ABC") to assure a Glee compare. I also modified the verbose display for trouble shooting. When marked exact, a string object's verbose display is like (String[ I425R1C=C]abc). When not marked exact the display is like (String[ I425R1C:C]abc); i.e. the colon ":"is replaced with an equal sign "=" when marked exact. Once marked, the objects stay marked so you can save them in variables with the marking preserved on retrieval. With sequences, the marking is done one level deep so it can affect operations on each element (i.e. @& ).



4/11/2002: Sequence operators (examples and cheatsheet); :select control examples. Testing of the :select control structure has revealed a number of issues relating to handling of sequences. I've been addressing those issues. In the process I discovered I had completely neglected the documentation of sequences in the Operators section. I'm spending a little time there to refine the operations and document before finishing the control structures. I have added another example for the :select control structure and have several more to do.




4/10/2002:Change behavior of (,,): As I begin to write more elaborate programs to demonstrate Glee I am finding some of its behavior is not as useful as it might be. The "expose with separator" operator (,,) is just such a case. Previously, it removed all depth like ravel and inserted objects between the elements. For objects with depth greater than one this was problematic. So I changed its behavior. Now the default option inserts space objects at the deepest level and line-feeds at higher levels. The dyadic version allows you to supply a sequence of separators in deepest to shallowest order. Now the depth of the result is the same as the depth of the argument.



4/7/2002:Clean up namespace documentation; conforming argument lists; more :for examples; document :if / :elseif / :else.: Way back on 3/4/2002 I switched Namespaces from dictionary objects to sequences. I just noticed I never corrected the namespace documentation in the tutorial. Further, I noticed the creation of namespaces from objects was not consistent or natural. I had done nothing to address length conformity issues. I have now adopted rules for conforming objects and fieldlists differing in number of elements. For single-field fieldlists, the object, regardless of number of elements, is assigned to the field. For numeric objects and fieldlists of more than one field, elements of the vectors are made to conform to the field list. The usual right-take is not used. My rationale for the general use of right-takes was data (e.g. time series) increases chronologically left to right. Experience has shown me I usually want to line up the most recent periods and fill missing elements on the left. However, in namelists used in argument passing, if I want to force length conformity at all, I want to do a left take. It is just more natural and intuitive. Left takes are also performed on sequences. If the user wants a whole numeric vector associated with a field and more than one field is given in the list, he must explicitly enclose his numeric vector object (>) forming a one element sequence. Strings are always taken as one element sequences rather than character vectors.




3/29/2002:Glee is almost useful: It's been a long pull, but with this release, Glee is one step away from being useful. Next I introduce blocks, named blocks (programs) and control structures. At that point we have considerably more than a very powerful desk calculator at our disposal. We can become programmers in Glee. After that come files and domains. That is one of our keys to the outside world. Keep those cards and letters coming.




3/26/2002:Fields, Field Lists, Compound References, Namespaces: I'm still working on the linkages for named blocks and control structures. Important components for these mechanisms are Fields, Field Lists, and References. With the Field List feature I had to abandon the implicit object of fields which used to be a reference to the most local namespace. Therefore, semantics like (.clear) had to become ([].clear=>@) to explicitly express the object of the method (i.e. empty indexing on now object [] returns a copy of the most local namespace which then has its .clear method invoked). The assignment has to be to the niladic (@) rather than the empty index ([]) because the ([]) returns a copy, not a reference. I think, while consistent, these semantics are ugly. Perhaps I'll introduce something like system commands (e.g. APL used )CLEAR to clear the workspace.) In practice, clearing of namespaces in this fashion should seldom be needed. I use it here to have the the examples work from a known base.

This semantics change has allowed me to provide the necessary semantics for field lists. Now, (.i) returns a field list containing one element (the field ".i"). It then allows specification of a field list as (.i .j .k) resulting in a three element field list containing fields ".i", ".j", and ".k". With field lists I can manage things like namespaces under program control as shown in the Field List tutorial.




3/13/2002:References:I may have broken through the log-jam. References are now working. They behave intuitively and they don't leak. They appear to be very useful and make implicit indirect addressing simple and robust. I probably have a couple more days of regression testing and code tweeking to do before I present the next version. If anyone is using the undocumented control structures (e.g. :for), my next release will probably break them. The release after that will make them work again and will document them. The reason for this is the impact reference objects have on the implementation of control structures and inter-block communication. It will take a complete rewrite (but no rocket science). In the meantime, I want to get the reference objects out so you can start to explore their features and use. Understanding them is crucial. I'm really pleased with the way they behave.




3/11/2002:References: References are still problematic. I'm able to make them work and am pleased with the semantics. But they leak.




3/7/2002: Namespaces, References and Anonymous Objects: The work continues. I'm trying to support something like 1000=>west.febr.sales. My initial scheme #ns=>west; #ns=>['febr']west; 1000 => ['sales'] (['febr'] west) wouldn't work because the model couldn't assign into an anonymous reference. A subsequent try: @=>west; #ns@=>.febr west; 1000=>.sales (west.febr); (where @ means "reference-to") is working and follows my simple left to right model but is obviously too clumbsy. The solution lies in the parser looking farther ahead than it has so far. It needs to see "west.febr.sales" in one eyefull and implicity create namespaces (@=>west; #ns@=>west.febr) where they don't exist. It also needs to support styles like x.div.sales[1..12] => [1..12]y.div.sales. I'm working those issues now. The problem is tougher than for REXX which just treats periods in names as part of the names. In Glee, symbols beginning with a period are fields and are used for symbolic addressing. The issues are tougher than C++ or Cobol that reduce compound names down to a memory offset at compile time. In Glee they reduce to nested namespaces that can be addressed by implicitly catenated fields. For example, west.febr is the namespace referenced by the symbol west addressed by the field named .febr. This returns a reference to a namespace which is then addressed by the field named .sales. Left to right dereferencing of namespaces implements easily. Assignment is more problematic. In the end I intend to make things much easier and more natural and intuitive for the programmer. I'm not quite there.




3/6/2002: Namespaces, References, and Anonymous Objects: It's still taking too long. This process is proving the computer and a working interpreter are great assistants in the "design" process. I am amazed at people who say they can design this stuff. I'm also skeptical. Regardless, the only process that works for me is sculpting. Right now I'm having to press back some modeling clay and try another tact. I know what the result should look like ... I'm still a little fuzzy on how to accomplish it. It's a good thing I have no marketing department or boss. With a marketing department I'd be pressured to put out crap and then be forced to keep it as a base for later development. With a boss I'd be fired. Either way, the result would not be as good as what I have in mind. If anyone is watching, thanks for your interest and patience.




3/4/2002: Namespaces and Rreferences:It's been too long. But now Namespaces and References are doing what I want them to do. Further, they're doing what I need them to do to snap into Named Blocks and Control Structures. If anyone is following along, it shouldn't be too much longer. One of the things that has taken so long was a switch from R/B trees to sequences of sequences for managing the namespaces. R/B trees reordered to alphabetical which blew my argument passing scheme. Then in thinking about it, with namespaces being objects (rather than one huge structured namespace for the whole interpreter), I decided sequences were the better structure anyway. Time will tell. But that's what's been taking so long.




2/26/2002: Namespaces, fields, and references:If anyone is watching you may have noticed little visible progress on Glee. I haven't published an interpreter or documentation update since 2/13/2002.

I have spent the last several weeks experimenting on how best to deal with namespaces, fields, and references. These objects along with blocks and named blocks (i.e. programs and functions) are all interrelated. When I first published Glee on 1/1/2002, I had rudimentary versions of all these objects functioning. However, as I documented the work and tested the examples for the documentation, some fairly glaring shortcomings became evident and some new opportunities were exposed.

Rather than drag you up and down the slopes as I explored and abandoned various inventions, I've resisted publishing new code and documentation. I will continue to do so until I am comfortable with how this sculpture is turning out. The computer instructs me on how this should all be pieced together ... it is an iterative process. I remain amazed at the process of interacting with the live Glee interpreter. This iterative sculpting process, working with a live and functioning interpreter, continues to point out flaws in "design". It reinforces my confidence in this live sculpturing process over a pure design process.

The computer is far better at keeping track of all the implications of object changes and their interactions than I am. Mere mortal programmers can't do this except on the most simple of designs. Unfortunately, there is no quick way through it. It is soup when it is soup. So if you're still following along, trust me ... there are good things coming and it shouldn't be too much longer before I break through this little logjam.




1/3/2002: Cheatsheet for Numeric operators: Few people will use all the Glee operators frequently. Even I need a quick reference like this to help me choose the appropriate operator for the task.




1/2/2002: Current effort is in documenting the operators. The outline level documentation of the numeric operators is complete. I updated both the code and the documentation at the end of the day for download. My next step will probably be to document other Glee objects (types), like booleans and sequences. I will then move to operator documentation for these objects as well as the character objects.




: