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 | D | />> | /| |
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 | M | /| | 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.