🚀 go-pugleaf

In article <798@cwi.UUCP>, alan@cwi.UUCP (Alan Wright ) writes:
> In article <552@smds.UUCP>, rh@smds.UUCP (Richard Harter) writes:

> You may find that the best you can do prior to some large following
> developing is to literally give your language away. Further, the
> prevailing attitude is that it must be available in source form.

Well, yes, that is generally the case.

> I agree with your reasoning here, but my experience shows that not only
> do you achieve higher productivity via such languages, that you also
> tend to implement more generality, flexibility, and other such
> qualities with the more expressive language. I suspect that a general
> rule here is that the more code a programmer has to write, the more
> corners (s)he will tend to cut. 

Particular as deadlines grow closer.  :-)  I think you are right -- the
gain I see is that a well designed "higher level" language is easier to
write -- line for line of code -- than a traditional compiled 3GL because
irrelevant considerations (for the purpose of the code) do not intrude
themselves.  To give a typical example from C, quite often the most natural
way to implement an algorithm is to use pointers into data structures.  The
pointers have to all be declared and initialized.  While this is simple
enough it is overhead.

I take it as a maxim that any language which does not provide automatic
dynamic storage which you do not have to manage is not really satisfactory.

> > There is a psychological trap involved, a tendency to say "I use and
> > like X, but it could be a lot better so I am going to create my own
> > language Y."  The result is X with a bunch of extra miscellaneous features.

> Not necessarily. For example, there is really no resemblance between
> Perl and Accent. The reason for this is that Perl was designed for
> one niche (system administration?), while our needs were somewhat
> different (production CASE software prototyping and development). 

This is not what I had in mind.  You were trying to do something different.
What I was thinking of more on the lines of fiddling with minor features
and adding gadgets.  If you look at the major languages you seen quite
different underlying concepts of what the languages are about.  Compare,
for example, FORTRAN, COBOL, lisp, apl, forth, SNOBOL, and eiffel.  You
are talking whole different modes of thinking here.  My point is that
there is a great tendency to elaborate on the mode of thinking that one
is famliar with.  One, in effect, rewrites C with one's particular pet
peeves removed.

> > I gather from your comments about a compile-phase for
> > Perl at runtime that you can parse an accent program in advance and execute
> > off of a representation of the parsed program.  Is this correct?

> Yes. Parse once, execute multiple.... Also, we can deliver one object code
> for all of our platforms.

At this point we have settled for parsing at run time (but parsing is
very cheap.)  This is a one time cost since procedures, once parsed,
remain available in parsed form for re-execution.  Perhaps later.

> Now, back to the topic of Lakota. I remember seeing something you posted
> in the past which suggested to me that Lakota was perhaps more like a
> REXX than a Perl. What I remember is something about controlling the
> interactions among a set of subordinate tool processes. Is this correct?

Just so.  The general notion is that you can create execution frames on
the fly which have persistence but which are decoupled.  An execution frame
is sort of like a light weight process; however from the viewpoint of the
OS the execution frames are all part of the same process.  From a 3GL 
program you can start up (or resume) an execution frame which can, in
turn suspend itself and pass control (and data) back to the calling program.
You can also link 3GL routines into the execution frame via an interface
which makes them look like Lakota commands and intrinsic functions.
[3GL is an overstatement -- the interface understands C and the interpreter
is written in C.]  The interpreter expects that there is an underlying
shell language that you can pass commands to which is anything that
it doesn't recognize as being a Lakota command.  The real difference
between REXX and Lakota (in this regard) is that there isn't a natural
underlying OS such as VM/CMS that Lakota is tied to.  (Although AREXX
for the Amiga apparently is a happy combination.)  The objective here
is to be able to have multiple pieces of functionality working together
within a common environment.
-- 
Richard Harter, Software Maintenance and Development Systems, Inc.
Net address: jjmhome!smds!rh Phone: 508-369-7398 
US Mail: SMDS Inc., PO Box 555, Concord MA 01742
This sentence no verb.  This sentence short.  This signature done.