HOPS: A Hierarchical/object-oriented programming environment system

Theses

Thesis/Dissertation Collections

1989

HOPS: A Hierarchical/object-oriented

programming environment system

Ryuichiro Kodama

Follow this and additional works at:

http://scholarworks.rit.edu/theses

This Thesis is brought to you for free and open access by the Thesis/Dissertation Collections at RIT Scholar Works. It has been accepted for inclusion in Theses by an authorized administrator of RIT Scholar Works. For more information, please [email protected].

Recommended Citation

School of Computer Science

HOPS:

A Hierarchical/Object-Oriented

Programming Environment System

by

Ryuichiro Kodama

A thesis, submitted to

The Faculty of

the School of Computer Science and Technology,

in partial fulfillment of the requirements for the degree of

Master of Science in Computer Science.

Approved by:

.Professor James E. Heliotis

Professor Peter G. Anderson

Professor John A. Biles

Date

Acknowledgements

I would like to thank Hitachi, Ltd. for its scholarship during the study in the MS

program at Rochester Institute of Technology.

Being a foreign student, I greatly

appreciate Janene Oettel's help in pointing out the grammatical mistakes in English.

Finally, I would like to

thank

my wife, Kazuko, for her support. This paper could not

have been completed without her cheerful encouragement.

About the Reproduction of This Thesis

Title of Thesis:

HOPS: A Hierarchical I Object-Oriented Programming Environment System

I,

Ryuichiro Kodama, hereby grant permission to the Wallace Memorial Library, of

RTf,

to

reproduce my thesis in whole. Any reproduction will not be for commercial use of profit.

Theconcept of object-oriented_programmingis

becoming

animportantparadigmin

whichprogrammersrepresent and solve problems. HOPS (Hierarchical

/

Object-oriented

Programming

Environment

System),

developed inthis thesisproject,employsthisconcept

torepresent and manipulatetheresourcesofa_programmingenvironment. Alltheresource

objects(such as

files, directories,

simpleinteger dataand soon)are

hierarchically

arranged for easyaccess and_management, as theusermoves through atree structurejustasinthe UNLX file system. HOPL (Hierarchical

/

Object-oriented

Programming

Language),

whose

grammaris similarto C

language,

has been designed so that theexpression of resource

objects canbe

directly

embeddedina_statement, whichis translatedinto intermediatecodes and then is executed. The system allows the user to store the intermediate codes as

methods and to inherit methods from objects which _already contain methods.

HOPS,

functioning

nowundertheUNLXenvironment,can sharetheUNIXdirectories andfilesas its resources, so that it can be an object-oriented front-end processor for UNIX shell

commands. An experimental screen _editor, HOPE (Hierarchical

/

Object-oriented

Programming

Editor),

has also been developed. It is written _{partly in HOPL}to facilitate

customization of some_editingcommands.

Computing

Review Subject Codes

The

following

are the _primary and _secondary classification codes for this _thesis,

accordingto theACM's

Computing

Reviews. The primaryclassificationcode:

D3.3 Language Constructs

The secondaryclassificationcodes:

F3.3 StudiesofProgramConstructs

Acknowledgements

2

Abstract .-...3

Computing

Review Subject Codes 3

1. Introduction 6

1.1. More Precise Abstraction through HOPS 7

1.2. PreviousWork 8

1.3. Theoretical and Conceptual Development 10

1.3.1. Mechanism of HOPS Inheritance 10 1.3.2. Evaluation Process intheHOPL Interpreter 13

1.3.3. Hierarchical Arrangement of Objects 14

1.3.4. RepresentationofObjects 14

1.3.5.

Continuity

ofConventional SystemsandHOPS 15

1.3.6. TTY-basedSystem 16

1.4. HOPS

Glossary

16

2. Functional Specification 18

2.1. Object Management 18

2.2. HOPL

(Hierarchical

/

Object-Oriented

Programming

Language)

18

2.3. HOPE

(Hierarchical

/

Object-Oriented

Programming Editor)

26

3. Program Description 28

3.1. Basic Structureof anObject 28

3.1.1. BasicOperationson anObject 32 3.1.2. PhysicalStructureofSome Primitive Objects 32

3.1.3. CreationofObjects 36

3.1.4. Reference Counts 36

3.1.5. C Language Interface 39

3.2. Lexical AnalyzerandParser 39

3.2.1. TTYInterfaceandCommandFile Interface 39

3.2.2 Syntax Analysis 41

3.3. ImplementationofControl Structure 43

3.3.1. An Environment Object 43

3.3.2. The Evaluation Process and

Message-Passing

44 3.3.3. InstanceVariablesandLocal Variables 47

3.3.4. Method Objects 47

3.3.5. A Method List 49

3.3.6. AssignmentStatements 50

3.3.7. ConditionalStatementsandIterationStatements 51

3.3.8.

Jump

StatementsandInterruption 52

3.3.9. A Block Object 53

3.3.10. ScopeRules 57

3.5.1. A FileObject 66

3.5.2. Coordination with the UNLX File System 66

3.6. HOPE 67

3.6.1. The Line Editor 67

3.6.2. The Curses

Library

in C language 68 3.6.3. The HOPE Main Program Structure 68

3.7. Software Development_{using HOPS} 69

3.7.1.

Prototyping

69

3.7.2. A"setup"

Message 70

3.7.3. A Project

Using

Inheritance 73

4. Sample Programs in HOPL

find,

grep, andawk 76

5. Conclusions 79

5.1.

Summary

79

5.2. Alternative Approaches foranImproved System 79

5.3. Suggestionsfor Future Extensions 80

Bibliography

82

Appendix A: C Language Interface A-l

Appendix B:

Setting Up

HOPSunderUNLX A-6

One of the _primary goals of an interactive programming environment is to

enhance the_productivity of software programs.

Easy

manipulation of system resources

(such as

files, disks,

and other input/output

devices)

is essential for productivity. The

UNLXt

operating system

[7],

basedonahierarchical file_system, isasuccessfulinteractive

programmingenvironmentwhichmakesit easyandunderstandabletouse system resources

by

representingthemasfiles. That

is,

UNLXenables ustoabstract resourcessuch asI/O devices

by

read/write operations. This project develops an interactive programming

environmentwhichintroducesobject-oriented methodsintotherepresentationofresources,

and arranges _every object hierarchically. For

instance,

even a

directory,

which itself

contains _objects, is regarded as an object that can accept messages to manipulate its

embedded objects. Becauseobject-oriented methodsprovidemore preciseabstraction of

resourcesthanjustread/write _{abstraction,the resources, acquiring}the _abilitytostandardize

their

interfaces,

gain greater connectivity. Most

importantly,

thehierarchical arrangement

ofobjects makes_{it easy}to access and manage objects.

The environment system developed in this project is called HOPS

(Hierarchical/Object-oriented

Programming

EnvironmentSystem). HOPS isa_single-user,

single-tasksystem. Thesystem includestwocomponents:

(1)

aninterpreterofthe

newly-designed object-oriented

language,

HOPL (Hierarchical/Object-oriented

Programming

Language),

whichhandlesobjects

by internally

interpreting

messages sentto_them,and

(2)

a screen _editor, HOPE (Hierarchical/Object-oriented

Programming

Editor),

whose instructionsarewritteninHOPLsothat theusercan customize some ofitsfunctions. The

editor is also an example of an application program written in

HOPL;

_therefore, an

understandingoftheeditorwill

help

thereader understandHOPLlanguage.

IntheUNIX_{operating system,} all peripheraldevicesarerepresentedas files inthe

hierarchical file system [7]. Most of the device-dependent issues are

concealed insidethe device

drivers,

so that application programs can communicate with

thosedevicesthrough

basically

_onlyread and write operations. Eventhecommunications betweenprocesses aredonethrougha pseudofilecalled a

'pipe'

orthrough standardinput and output. While this standardization ofresourceconnections

by

a fileprovides great

flexibility,

there are _many resources that cannot be abstracted

by

_only read and write

operations. A

directory,

implemented as afile in

UNIX,

holds some files or someother

directories.The

directory

_obviouslyneeds some operationsotherthanreadandwrite, such

as a

lookup

_operation, which could test if a file specified as an argument exists in the

directory

ornot.

As an alternative to file abstraction, thispaper advocates hierarchically-arranged

objectswhichrepresent alltheresourcesinan_{interactive programming}environment.

By

regarding theresources as objects whichcan acceptmessages, it is possibletorepresent

many different types of resources as objects. A

directory

object can acceptthe

lookup

operation as amessage. A

directory

objectcan accept a message

X,

then execute it

by

sendinga message such as

"evaluate"

to themethod objectXthat the

directory

associates

withX.

Thus,

customized commands canreside ona

directory

as objects. An interpreter

objectcan acceptamessagelike "changethe_workingdirectory." Andan editor object can

evenacceptall themessages toedit a text,so that theuserscancreate customizededitor

commands_usingthose messages.

This system is based on object-oriented methods

[3],

which standardize all

executions as messages sent toobjects, so that we can take advantage ofdynamic high

connectivity betweenobjects. This featureisalso referredto as an advantageofatypeless language. Suppose that an object is attached as an argument to the message

EAT,

and

One

day

you create an objectLAMB and wanttoinvoke EATwithLAMB. Atthattime,

you don'tneedtocreate a specializedversion oftheEATmessage, such as EAT-LAMB. Allyou needtodo is justadd a methodfortheGRILLmessageto theobject

LAMB,

then

you can send amessage, EATLAMB. Inthis way, theconnectivityofEATisenhanced.

In

HOPS,

_everynamed objectis locatedinatleastone

directory

and alldirectories

are arranged

hierarchically,

so that theobjects relatedtoaproject canbecollectedinone

directory

foradministrative convenience and

they

can be searched in ahierarchical way.

Basically,

there are no globally-named objects other than a root

directory

and a current

workingdirectory. Theroot

directory

representstheHOPL

interpreter;

it holdsthevariable objects usedin the

interpreter,

such as a previous input statement. Thecurrent _working

directory

istheobjecttowhichmosttyped-inmessages are sent.

Every

commandin HOPS

startswitha messagesymbol which_{may be followed}

by

some_arguments,ifany. Youcan

changethat

directory by

_sending theinterpreteramessagetochangethecurrent _working

directory.

1.2. Previous Work

The Smalltalk-80t _programming environment

[3]

is apioneer system which not

onlyprovidesbutis also described in anobject-orientedlanguage. This systemhas been developedthroughseveral versions:

Smalltalk-72,

Smalltalk-76,

and

finally

Smalltalk-80 in 1980. In the Smalltalk-80system,awindowcalledabrowserenablesthe userstofind a

specificclass andmessage[4]. Bothclassesandmessages arecategorized,sothat theusers

canfindthe code of a specific method

by

selecting

(1)

aclass_category,

(2)

a class inthat

categories,

(3)

amessage_{category in}thatclass, and,

finally, (4)

a messageinthatcategory.

1"

HOPS doesn't_relyon _{anything but}aTTY-type

device,

whilethe Smalltalk-80 systemis

dependent on a bitmapped display. In a _sense,HOPS provides more primitive functions

which would be basic operations for even _using the bitmapped display. The Little

Smalltalk system

[2]

largely

supports thespecification ofthe Smalltalk-80 under UNIX.

Thesystem, writteninC languageforportability, shares one ofits purposeswithHOPS in

the sensethatitpursues a TTY-version of a object-orientedlanguage. Butwhen youlook

atthe_scopingrule of object variablesinthose two _systems,Little Smalltalk appears notto

have such a structural scope as the hierarchical arrangement of variables that HOPS

provides.

Directories playa significant rolein

hierarchically

_arrangingtheobjectsin HOPS.

Objectsare connectedtoa

dictionary

inwhichinstancevariables anduser-definedmethods

arelookedup. Thereis no_{direct way}toaccessinstancevariables;a method boundto the

symbol '.'

(period),

receiving an instancevariable nameas an _argument,returns thevalue

of aninstancevariable.

Among

_{currently investigated}object-oriented

languages,

Self

[17]

employs a similar structure foran object's

dictionary,

whoseslots contain bothvariables

and procedures. Thereis another conceptthatSelfandHOPS share: eliminationof a class

object. While

Self

gets rid of class objects

by

_exploiting prototype-based objects

(substituting

instantiation

by

_cloningor_copyingan_object),a method

dictionary

works asif

it were a class object in HOPS. For

instance,

if a message 'new' is sent to a method

dictionary,

the

dictionary

object creates an instance that has operations in the method

dictionary. With either_{method, this} eliminationreduces complexities (such as thosein

metaclass_connections)oftheobject-orientedsystem.

For a compiled and _strongly typed object-oriented

language,

there is C++

[15]

developedatAT&T. Theobjectsinthatlanguageare scopedbasedonthe_scopingrulefor

functions,

localtoa

function,

orlocaltoanobject. The HOPLis

interactively

interpretedas

well astranslatableinto

intermediate

codes.

UNIXprovides a lotof useful built-incommandsthatcanmanipulatefilesor their

contents. Anew command canbe built

by

_combiningthose built-incommands in whatis

called a shell script. Ontheother

hand,

there are alotof

library

functionswhich

directly

accessthe structure of afileor allow thequickmanipulationof system resources. Those functions

help

build _up an application programwrittenin C language.

Thus,

UNIX has

twobasicinterfaces: shell script commands andC

library

functions. Forexample, thereis both a command called 'rm' and a C language

library

function called

'unlink'

which are

usedtodelete afile. In HOPLthose two interfacesare standardizedinone

format;

HOPL

just sends a messagetoa object. The deletionofafile is done

by

_sending a messagelike

"deletethefile xyz"

to the

directory

_containingxyz.

In addition to the HOPL

interpreter,

another system component in HOPS is the

screen_editor,

HOPE,

which can becustomized

by

_{modifying HOPE}

itself,

becauseit is

writtenin HOPL. Emacs

[13]

hasa similarfeature inthatit iswrittenin itsownlanguage called

Mlisp

(Mock lisp). The users can create a customized _editing environment

by

changingsomefunctions in Emacs. Forexample, itcansimulateanenvironment similarto theUNLX editor called'vi'. The users canalso add a newfunctionto theEmacsand save

it as a

library

function. While Emacstakes advantage ofalisp-like programming _style,

such as the dynamic scope of _variables, HOPE is built _up based on object-oriented

methods; it consists of several chief objects and executes edit commands

by

_sending

messagestothose objects.

1.3. Theoretical and Conceptual Development

1.3.1. Mechanism of HOPS Inheritance

In the Smalltalk-80 system, when theusers want torun a simple demo program,

While this indirectprocedure preserves programs as assets ofthe system, itimplies that

there_{may be}a more

direct,

quicker proceduretoruna prototype program. In

HOPS,

the

classisreplaced

by

a simpledictionary. Theobjectin HOPSis categorizedintotwo types: a simple object and a compound object. Asimple objecthas onlyone

dictionary,

sothatit isusedfor_representinga primitive objectwhichdoesnotinherit anypropertiesfromother

objects,exceptfroma publicdictionary. Thepublic

dictionary

includesmethods(such asa logical-oroperator "II"and alogical-andoperator

"&&")

whichare_commonlyused

by

_any

object. "Compound

object"

isanother namefor

"directory

object", whichis connectedtoa

directory-method

dictionary,

a user-customized

dictionary,

and zero or more inherited

dictionaries. When theuserssee and_modifythecontentofthe current

directory,

the

user-customized

dictionary

isused to_{look up} aninstancevariable.

Therefore,

whentheusers

wanttorun ademo_program, all_theyneedtodo is justcreate a new methodina

directory

andtype inthatmethod name. Ifa messageis sentto a

directory,

the systemlooks it up

first, (1)

in the directory-method

dictionary,

(2)

intheuser-customized

dictionary,

(3)

in

any inherited

dictionaries, (4)

inthedictionaries fortheHOPL

interpreter,

then

finally

(5)

in thepublic

dictionary

describedabove. Thereisa methodinthedirectory-method

dictionary

HOPL interpreter

parent

Hierarchical Arrangement

'child

Directory-method

dictionary

(common

to all

directories)

User-customized

dictionary

kpwd^b^

',*

m?M.

T^m*

wmi.

A

_z/

or>

m+

methods

written in

C

language

!me !pa

X

Increment

Inheritance

dictionary

(implemented

by

a

list,

whose element

has no _name)

literal string "project"

parent

directory

= "!"

integer"1"

methodfor Increment

Directorieswhose user-customized

dictionary

is used for inheritance

Figure 1.1 Anexample ofdirectories in HOPS

Figure 1.1 showsan exampleofdirectories in HOPS.

Every directory

shares one

directory-method

dictionary

which consists of tables between a message symbol and a

methodthatis

typically

writteninClanguage. Each

directory

has itsown user-customized

dictionary

and inheritance dictionary. The user-customized

dictionary

contains two

inherited

directories.

Only

the user-customized

dictionary

connectedto thosedirectories is

usedfor

inheriting

methods.

Oneoftheimportantcharacteristicsin HOPS directoriesisthat thereisnodifference

betweenaninstancevariable'slocationand a method'slocation. Thereferencefields inthe

dictionary

pointtoboth instancevariables and methods. Forexample,aninstancevariable

x (which holds an integer

1)

and a method Increment reside on a user-customized

dictionary

in Figure 1.1. This structure makes _{it easy} to manage bindings for instance

variables, becausean instance variable can be

dynamically

obtained

by

_carrying out the

same procedure as a methodis lookedup.

1.3.2. Evaluation Process in the HOPL Interpreter

MostversionsoftheSmalltalksysteminterpretanintermediatecode(bytecode)

by

incorporating

stack operations [3]. Thiswasdemonstrated

by

a simpleSmalltalk interpreter

written in Smalltalk-76 itself [5]. HOPS applies lisp-like evaluation to the process of interpretation instead of_{using byte} code. Figure 2.1 shows that _process, in which the

message-sending actionis interpretedasanobject(method_object),then the systemsends a special message 'eval'to the method objectwithno arguments. This design allows usto

instance

variables

X

)

ieatj

target object

target Qbject meSsage

Figure 1.2 Interpretationof_sendinga messagein HOPS

1.3.3. Hierarchical Arrangement of Objects

The hierarchical arrangement of objects plays a significant role in HOPS. In a

hierarchicalstructure, objects canbe locatedin a well-organized_waysothatmoredetailed

components

(objects)

can be accessed as theleafofthe tree structure is searched. This

structure is also suitable for project management because separated subprojects can be

developedin directories independently.

1.3.4. Representation of Objects

In

HOPS,

themannerof_specifyingahierarchicalobject retainsthe_consistencyof

object-oriented methods: the execution of a program

by

_sending a message. HOPS

represents_{everything in}the systemas an object. Therearethreewaysto_specifyanobject:

(1)

by

sendingamessage '.'

withan _argument,object_name,to thecurrent

directory

(toget

anobjectembeddedinthat

directory),

(2)

by

_sendinga message 'A'to thecurrent

directory

(toget theobject

holding

that

directory),

or

(3)

by

_sending a message '.'

withan_argument,

object_name,to theroot

directory

(to get an objectembeddedinthatdirectory). Because

namedoes nothavetobetypedinwhen a message issent to

it;

_every statement in HOPL

startswith a message symbol whichissenttothecurrent

directory

(ifthe

directory

doesn't

have such a_message, then itwillbe sent to the root

directory,

HOPL

interpreter),

unless

the root

directory

is specified first in the statement. Instead of

typing

the statement

interactively,

if itiswrittenin a method (aprogram

body

invoked

by

amessage) andthe

root

directory

isnot specifiedfirst inthe_statement,thenthe_{first identifier appearing in}the statement means a messageidentifiersentto'selfinthesense ofSmalltalk-80terminology.

If such a message symbol cannot be found in the message

dictionary

of

'self,

a special

object calledILLEGAL isreturned after evaluation process. ILLEGALisusedincase an

errorconditionis satisfied:for_example,thecaseinwhichaspecifiedmessageis notfound.

ILLEGALrespondsILLEGAL to _{any kind}ofmessage except the 'print'message which

willprint out the name "ILLEGAL" to standard output. ILLEGALmustnotbe boundto

any variables; if one tries to assign it to an instance _{variable, the} assigned value is

automaticallychangedtoa system constantobject,

NIL,

whichmeansfalse inconditional

expressions.

1.3.5.

Continuity

of Conventional Systems and HOPS

Thesyntactic sugardescribedabove givestheusersa sense of_{continuity between}a

non-object-oriented,conventional systemandHOPS. Aconventional system allowsfora

set of globally-accessiblecommands, which consist of

first,

a commandname, and then

somearguments,ifany. Whenafile is

deleted,

thecommand'rm

xyz'

istyped

in,

where

'rm'

is a command name and xyz is the argument that indicates the file to be deleted.

Behind this systemis theideathat thesystem works as a"servant" _acceptingcommands.

HOPSdoesnot changethisideaexceptthatitemploys as_manydifferent"servants"

(which

can understand different sets ofcommands) as possible. The "servant"

in HOPS is a

directory

object, in which (in addition tothe standard set of commands forthe

directory

directories.

In this_way,as theusers movethrough the

hierarchy,

HOPS provides a

customizedcommand setthatisconnectedto thecurrent_{working directory.}

1.3.6.

TTY-based

System

Generally,

anadvanced_programmingenvironment requiresuserstospend alotof

time at the keyboard

typing

in text and debugging. As

long

as the chief task in

programming istoassign a symbol to an

idea,

thekeyboardwillnotbe eliminated. Even

when a system employs menus andicons a great

deal,

programmers stillhave to typeina newly-created name relatedto theconceptthat

they

are

trying

tomodel. Useof a_pointing

device,

or_mouse,whichis inevitablewithabitmapped

display,

interruptsthat_typingwork;

theprogrammers haveto

keep

_switching theirhands between keyboards and mice. So for

this reason, andtomakethesystem as portable as_possible,itwasdesirabletouse aTTY

ratherthan bitmapped

display

forthe basic components ofthe system.

However,

ifone

wanted to make the user interface

friendly

tonovice _programmers,it is still possible to

construct abitmap-based systemon

HOPS,

becauseofitsprimitivefunctionality.

1.4. HOPS

Glossary

The

following

list showsHOPS

terminology

inthis_paper, most ofwhich is from

Goldberg

[3]. Thepurpose ofthissectionisto_clarifythedifferencebetweenSmalltalk-80

termsandHOPS terms. Most

importantly,

HOPSimplementsa"class"in adifferentway.

object Acomponent oftheHOPS system represented

by

some

private_memoryand a set of operations.

message A request for an object to _carry out one of its

operations.

class Anobjectthatdescribestheimplementationof a set of similar objects. This is represented

by

a simple

dictionary

inHOPS.

instance variable A variable available to a single object for the entire

Ufetime

of_{the object;} instancevariablescanbenamed.

method

receiver

A description of how to perform one of object's

operations. While a message is an external

representation of the request to an object, a method

describes aninternal specification abouthow to_carry

outthatrequest.

Theobjecttowhicha messageissent.

message symbol The name ofthe typeof operation a messagerequests

ofitsreceiver.

message argument An object that specifies additional informationforan

operation.

block A descriptionof adeferredsequence of actions.

block argument Aparameterthatmustbesupplied when certainblocks

are evaluated.

simple object

compound object

An object that does not inherit any properties from

other objects andhas onlyone method-dictionary. This

isoriginal

terminology

in HOPS.

Anothernameof a

directory

in HOPS. Incontrasttoa

simpleobject, this object caninheritspropertiesfrom

other _objects; therefore it can hold several

method-dictionaries in it. This is also original

terminology

in

2.

Functional

Specification

2.1.

Object Management

Because everythingin HOPS isrepresented as anobject,theobject structureplays a

significant role in

determining

the system's performance and basic properties, such as

primitive methods. Thebasicideaofanobjectisthatit isacontainerof pointers toobjects.

In

HOPS,

therequirementsforanobjectisthat thenumber of pointers mustbeexpandable

(as faras thesystem's resources _allow) and reducible at_{any time,}andthattheobjectbe a

sequence of those pointers or simple integer values. A reference counter method is

employedtorecoverfreespace.

2.2. HOPL (Hierarchical

/

Object-Oriented

Programming

Language)

Below isthegrammar ofHOPL. Herenon-terminal symbols arewritteninun-bold

fonts,

andterminal symbols arein bold face. Alternativecategories arelistedonseparate

lines;

inafew_cases, a

long

set ofnarrow alternativesispresented on one

line,

marked

by

the phrase "one of". An optional terminal or nonterminal symbol carries the subscript

compilation-unit:

method-definition-unit

interactive-unit

method-definition-unit:

method-structure method-definition-unit

method-_structure

method-definition:

instance-variable

:= _{method-structure}

instance-variable:

. identifier

. character-string-object

method-structure:

local-declaration-list

opf

{

local-declaration-listopt statement-listopt

}

interactive-unit:

local-declaration-list

opt statement-list

local-declaration-list:

local-declaration local-declaration-list local-declaration

local-declaration:

var _{identifier-list ;}

identifier-list:

identifier , identifier-list

identifier

Therearetwocompilation units: a methoddefinitionunitand ainteractiveunit. The

methoddefinitionunitcontains alistofmethod

definitions,

whichdefinehowtorespondto

a message. This unitis normally stored in a permanent

file,

and iscompiled as needed.

The current _working

directory

gets to accommodate methods with names after the

compilation. Because in

HOPS,

instancevariables and methods sharetheirlocation (in a

directory),

themethod-definitionhastheformof aninstancevariableassignment.

The interactive unit is a collection ofHOPL statements. This unit specifies the

format of commands which are typed in from a TTY. This unit can be saved in a

permanent

file,

which is compiled and executedjust like a command batch file. The

statement:

expression-_statement

if-statement

iteration-_statement

jump-statement

compound-statement

compound-statement:

{

statement-list opt

}

statement-list:

statement statement-list statement

expression-statement: expression _{opt ;}

if-statement:

if

(

expression

)

statement

if

(

expression

)

statement else statement

iteration-statement:

while

(

expression

)

statement

for

(

expression_{opt ;} expression _{opt ;} expression_opt

)

statement

jump-statement:

return term-expression_{ovt ;}

Astatement is similartoaC languagestatement exceptthata switch-statementis

not included in the HOPL statement and that a compound-statementin HOPL does not

containalocal variabledeclaration. IfanexpressionisnotNIL

(constant-object;

described

later),

thenit isregardedasTRUEinaconditional expression ofif-statementand

iteration-statement. The solution of the

"dangling-else"

problem is the same as C language's:

associatingtheelsewiththeclosestpreviouse/se-lessif.

expression:

instance-variable = expression local-variable = expression instance-variable := expression local-_variable := expression

message-expression

local-variable:

$

identifier

Assignment

statements change the value ofinstance variables or local variables.

There are two assignmentoperators:"="

called _simply an assignment operatorand ":="

called a quoted assignment operator. Ifthequoted assignmentoperatoris_{used, the}

right-hand- side _expression,

remaining not _evaluated, is assigned to the variable which is

specified

by

the

left-hand-side

expression.

Tocreate aninstance variable,theseassignment operators areusednormally. Even

if the specified instance variable does not exist, the assignment operators create that

variable.

There are three ways to reference a localvariable. In the most formal _{way, the}

dollar sign '$' is prefixed before the variable name identifier. This gives the safest

grammar. Another wayis the dollarsign plus positive number, which indexes the local

variable. The easiest _way to represent a local variable is to usejust thevariable name

identifierwithoutthedollarsign. The HOPLcompilertries tomatchtheidentifiertosome

localvariable. Ifitfailstodoso,an errormessagewillbeprinted.

message-expression:

term-expression cascaded-messageopt

cascaded-message

cascaded-message:

special-message : 0pt cascaded-message

keyword-message : cascaded-message

special-message

keyword-message

keyword-message:

identifier multiple-arguments0pt

special-message:

special-identifier object-expressionopt

special-identifier identifieropl

Aspecialidentifierisa sequence ofthe

following

characters:

#%&*

butthe_{identifier consisting}of_onlytheequal_sign,

'=',

isnota specialidentifier (theequal

signisusedforan_{assignment statement).}

Using

cascaded_{messages, several messages can be typed in} one statement. For

example,

1+2factorial:/(2+1 xor

3)

istransformedintothe

following

_parsingtree (Figure2.1).

Parsed

resultfor

"1+2

factorial:

/(2+1 xor3)"

tObj

msgSym _/

argl

______

tObj

msgSym _factorial

tObj

1

msgSym +

argl 2

method object method object

method object

tObj

msgSym xor

argl 3

tObj

2

msgSym +

argl ₁

method object

method object

Figure 2.1 Parsedresultof1+2 factorial: /(2+1xor

3)

A parsing tree, consistingofthemethodobjects,receives the "eval"messagefrom

theHOPL

interpreter,

so that the message propagates through the leaves in thetree and

multiple-arguments:

single-argument _, multiple-arguments single-argument

single-argument:

term-expression

term-expression:

object-expression cascaded-

special-message^,

cascaded-special-message

cascaded-special-message:

special-message :_opt cascaded-special-message special-message

When akeyword message has several _arguments, some special messages can be included ineach argument. For_example,thekeywordmessage,

1 send 1+2+3,1-3

hastwo arguments(l+2)+3 and 1-3.

object-expression:

constant-object

(

expression

)

block-expression local-variable hierarchical-object identifier

hierarchical-object:

instance-variable hierarchical-object

A _{hierarchical-object}

instance-variable

A

block-expression:

[

local-declaration-list0pf statement-listopt

]

The hierarchical-objectenables us toreference _{any instance} variable

by

_moving

throughthehierarchicalstructure. The

following

expressionspecifies aninstancevariable ins2of an objectboundtoaninstancevariableins1 of a parent object oftheparent object of

thecurrent_{working directory.}

The block-expression is ablock in Smalltalk-80: adescription of adeferred sequence of

actions. Itwillaccept a message"value" witharguments,ifany. Thosearguments should

be declared inside

[

].

constant-object: number-object

character-_{string-object} character-object

! hierarchical-objectopt system-constant-object

number-object:

-number-object positive-integer-object

positive-float-object

system-constant-object: one of

TRUE FALSE NIL SELF SUPER

Thecharacter-string-objectandcharacter-objectarerepresentedinthesame_way as

inC

language;

thecharacter-string-objectis enclosed

by

doublequotesandthe

character-object

by

single quotes. Theexclamation mark "!"

standsfortheroot

directory,

orHOPL

interpreter. It ispossibleto_specifya

directory

objectfromtherootdirectory. The

system-constant-object FALSE is another name for

NIL;

those internal representations are the

same. SELFandSUPERare pseudovariablesinthesense ofSmalltalk-80terminology.

Miscellaneous LexicalConventions

Acommentbeginswith/* andterminateswith

*/,

orbeginswith

//

and terminateswith new-line character orend offile.

Anidentifierisasequence oflettersanddigits. The firstcharacter

mustbea

letter;

theunderscorecountsasaletter.

Asemicolon ';'

is _{automatically}addedtotheendofastatement

The HOPLinterpreter

interactively

accepts_onlyexpression-statement. Astatement

executed

interactively

_{ends with a new-line characterwhich can be an alternative to the}

character';'. Alltheinterpreterdoes isread an objectfroma

TTY,

evaluate

it,

andwritethe

result of theevaluationtoaTTY. The

following

are examples ofconstant-object,wherethe

sentence

following

"//" isa comment.

152

//

integer-object

-234.34

//

float-object_withan

unaryoperator

"-"

"helloworld\n"

//character-string-object

//(sameastheonein C language

[6])

'

z' _{//character-object}

//(sameastheoneinClanguage

[6])

The

following

example shows how to work on a customized object

(directory),

where"HOSP> " isa system prompt message.

HOPS> 1

project_A project_B

//The '1'message willbe sentto thecurrentdirectory.

//Therearetwoobjects(botharedirectories

//inthiscase).

HOPS> cd .project A

//CcTwill be interpreted

by

theroot

directory,

because

//thecurrent

directory

doesnot acceptthatmessage.

//The dot'.' issentto thecurrent

directory

with

//theargument, project_A,andthen the

directory

object

//boundto thename'project_A'willbereturned.

//That

directory

ispassedas an argumentforthemessage

//'cd'.

Finally,

theinterpreter (root

directory)

changes

//thecurrent

directory

to theproject_Adirectory.

HOPS> 1

x Increment //The Tmessagewillbesentto thecurrent

//directory

"project_A".

//Supposethat'x' is anintegerand

'Increment'

is bound //toa method.

HOPS> .x = 1+2+3

6 //X is boundto6. Theplus

'+'

is sent to 1 and

//theresult of1+2.

HOPS> . Increment type

//ThemethodIncrementreceivesthemessage

//"type",

whichdisplaysthemethod content.

var

i;

{

.x =

.x +

$i;

}

HOPS> Increment 3

HOPS> . Increment _vi

//Themessagevi(theUNIXscreen_editor)issentto

//'.Increment'.

Themethodfor"vi"invokestheUNIXvi //ifthereisa_{documentation file}attachedto the'.Increment'. //Youcan edit a methodinthisway.

2.3. HOPE (Hierarchical

/

Object-Oriented

Programming

Editor)

There are two main objects that support the screen editor HOPE: a line

display

object called "curses"and a scratch fileobject called"ed". Cursesorganizestextlineson a

TTY

display

and manages a current cursor position inwhichinputcharacters areinserted.

In order to enhance its _{portability among many kinds} ofTTY

displays,

curses employs

UNIX

library

curses asthe name

literally

describes. It includes some informationabout

how many linesaredisplayedand where eachlinestarts or endsina_screen, sothatitcan

preventthecursorfrom movingaroundthescreenareainwhichnolinesaredisplayed.

Edisa simplelineeditorwhich canbeused withoutthe line

display

object. Itcan

retrieve oneline specified

by

a linenumberfromatextfileand edittheline. Itcan also

move, copy, and delete some lines specified

by

two linenumbers. The scratchfile is a

temporary

filewhich isusedfor

keeping

_up all theeditedlines of atext_{file according}to

Kernighan [8].

HOPE works

by

_sending messagesto these two objects, curses and ed. The user

can edit atextfile

by invoking

twokindsofcommands:keyboard-mappedcommands and

named commands. Whenyou open

HOPE,

_every

key

typed in first is a command as in

UNIX vi editor. For example, if you type in the character

'i',

then you can insert

charactersinto the locationpointed to

by

the cursor.

By

typing

in the named command

following

':', you can send messages to HOPE. The customization of the named

commands is done

by

_adding methods onto the

directory

for HOPE or

by inheriting

Figure2.2 shows thestructure ofHOPE as describedabove. Thefile with which

HOPE deals is also an object _representing a UNIX ASCII file. The user can handle a

UNIX ASCII file as an object that can accept messages such as concatenate, append a

string, showitscontents, and so on.

screen

Figure 2.2 StructureofHOPE

3

. Program Description

3.1. Basic Structure of an Object

Because _everyresource in HOPS is an _object, it is necessaryto

identify

anobject

somehow. The identification number for an object consists of 16

bits,

whose positive

representation (15 bits withthe most significantbit

being

_zero) indicates theindexofan

arrayofbasicobjectblocks. The lengthoftheobjectblock is 16 bytesanditcontainssome

informationabout an_object, asdescribed later. The negativerepresentationis usedforthe

identification of special _objects, which do not needto beallocated space when

they

are

created;

they

includesystem constant objects such asNILandTRUE.

Thestructureof anobject canbeexplained

following

three_steps,eachofwhichhas

a_{considerably independent function.}

Inorderto_{conveniently fulfill}theneedtoallocate new spaceintheprocessofobject

creation, allthepositiveidentificationnumbers are

initially

queuedinafree block stack.

Whennew space is neededfor object_creation, anumberpoppedfromthis stackis used,

andwhendestruction ofobjectsisneeded, theidentificationnumbersofdestroyedobjects

are pushedto this stack.

At that _{step, every block} is considered to be transparent. That

is,

there is no

difference in information among the blocks dequeuedor enqueued. In thenext _step, an

object _array whose volume can be changed as needed is implemented _using these

transparentblocks. Heretheblocksare categorizedintotwo types: header blocksand node

blocks. Figure 3.1 shows howthevolume-changeable_{array is}constructed. One halfofa

header block (8

bytes)

is dedicatedto_pointingto_up tofour_objects, since eachobject is

representedas 16bits(2 bytes). Ifthevolumeof an_arraybecomesgreaterthanfourobject

elements, node blocksare addedundertheheader block. Thenodeblockpointsto_up to

maximum of32 (4 x

8)

elements. Ifthenumberof elementsis greaterthan

32,

thenthe

addition ofnodeblocksto thetree-likestructure canbecontinuedinasimilar manner until

thefreeblockstackisexhausted. This is how the_{practically infinite length}ofaninstance

objectis attained. This givesHOPS another advantage: the averagetime toaccess each

elementisproportionalto thelogarithmoftheelementnumber(basedon2). This access

speedis _relatively

fast,

comparedwith the _{implementation using}sequential

lists,

whose

element access coststheorder oftheelement number.

up

to 4

(0

depth)

up

to

8

(1

depth)

Q

up

to

16

(1

depth)

up

to 32

(1

depth)

?

up

to

40

(2

depths)

up

to 64

(2

depths)

up

to 1

28

(2

depths)

?

?

up to 256

(2

depths)

up

to 264

(3

depths)

header

block

I

I

node block

By

taking

advantageoftheunbounded size ofthe tree structure mentioned_above,it

ispossibleto representan object regardless ofits length. Ontheother

hand,

thereis more

information tobeaddedinthis structure. Theupperhalfof a 16-byte headerblockisused

tostoretheinformationwhichthesystem needstohandlean_object,such asthe

flag

which

indicateswhetherthecontents ofanobject are pointersornot.

Figure 3.2illustratesthestructure of aheaderblock. Thefirstslot(2-byte

field)

in

thisblock iscalled_magic,whichis_actuallytheindexof a method

dictionary

object. Ifthe

messageissentto_{this object,}that

dictionary

objectisusedto_{look up}themessage symbol.

The second specifies how _many words (16

bits)

anobject hasas its slots. Note that this

number_uniquelydecides the tree structure. Forexample,ifthelength is

15,

then the tree

consists of oneheaderblockandtwonodeblocks. Thethirdisa reference_counter,which

is describedin alatersectionforreference counts. The fourth isa set ofbit

flags,

fourof

whichare explainedhere.

(1)

GC flag: This

flag

indicates whether the elements held

by

aheader block are

object pointersornot. Itisusedforreference countswhenan objectis discarded.

(2)

KILL flag: Whentheobject spaceiscollected asgarbage,thesystem checksfor

this

flag

to decide whether or not a special message is to be sent to this object before

returning it backto the free blockstack. Thisis _used, for_example, todelete a UNLX file

connectedtoaFileobject(anobject

behaving

likeanASCII

file)

whichis

being

discarded.

(3)

EVALflag: The HOPL interpreter evaluates_every object

by

_sending a special

message"eval". This

flag

eliminatesthefrequentsearchforthe "eval"method; ifthe

flag

is

off, then the objectisregardedas aconstantthroughouttheevaluation_process,andifthe

flag

ison, thesystemstartstolookforthe "eval"

method. Mostoftheobjectsdonothave

eval method in the

dictionary;

their EVAL flags are all off because

they

are constant

(4)

MOUNT flag: Ifa

directory

objectismarked with this

flag

on whencreated, then the fileobjects(objects

behaving

likeafile containing ASCII_characters)created under

that

directory

are_{automatically linkedto theUNIXfiles. Whena}

directory

_{objectiscreated}

underthat

directory,

thesame named

directory

iscreatedundertheUNIXfilesystem. This

is how the projectdevelops programs written in

HOPL;

aFile object _{containing HOPL}

source codesis _{automatically} savedintheUNIXfile. Thismechanism willbe discussed

later indetail.

Header Block

Structure

(16

Bytes)

objectindex

magic

length

refc

oattr

objjDtr

[0]

obj_ptr[1]

obj_ptr[2]

obj_ptr

[3]

: message

dictionary

?

(corresponding

to

a class

)

: word size of an object

: reference counter

:object attributes:

GC,

KILL

EVAL,

MOUNT

object indices or

node block indices

2

bytes

Figure 3.2 A header blockstructure

Table 3.1 summarizestheprocessof_constructingan object. Itis

interesting

tonote

that the process can be compared to the reference model [16]. Each layer's function

described in Table 3.1 is implemented

by

_using the lower layer's services. Objects

communicate to each other

during

their

lifetime,

driving

the services provided

by

the

Table 3.1 Referencemodelin

implementing

an object

layer

#

Function

Implementation

Illustration

0

To supply

transparent,

regular-size

blocks

as needed

Astack

containing

free

blocks

___-* >E__

1

To

implement

a variable length objects

Atreestructure

consisting

of

a header blockand

some node blocks

ZwWZw77\

2

To represent

any

kinds

of_objects,

considering

thecharacteristics of

each

(positive)

block indices for

ordinary

objects and

negative numbers

forsystem reserved objects

An object

3.1.1. Basic Operations on an Object

An object in HOPS is a tree structure _consisting ofblocks as described above.

Thereareseveralbasicoperations onthis tree structure. Thetreestructureis

invisible;

all

thatis observedfromoutsideisavalue's sequence,whoselengthis

infinitely

enlarged or

reduced.

Therefore,

twobasic_operations,insertionanddeletionof_elements,are provided.

Itis possibletoplacean elementanywhereinthesequence. Another importantoperationis

the transformationofdata between atree structure and a

flat,

contiguous memory. Most

primitive objects are implemented

by

C

language,

in which data is represented in flat

memory. In a sense, that transformation is a basic interface between HOPL and C

language.

3.1.2. Physical Structure of Some Primitive Objects

All theobjectsin HOPS areimplemented usingthestructure mentioned above. In

this section, let us take a look at thephysical structures ofsome primitive objects. The

categoryname (class name)oftheprimitive object shownbelowstarts with a capitalletter.

class at _all,althoughthesystemdoesnot requireit. Thisconvention comesfrom

Smalltalk-80's notation [3].

(1)

Integer: It isrepresented_physically in four

bytes,

whichiscalled

long

integer'

inC language terminology. Becauseobject pointer slots of aheader blockare eight

bytes,

enoughtocontainthosefour

bytes,

anintegerobject occupies 16 bytes for justoneheader

block.

(2)

Float: Itoccupies 8

bytes,

whose format is the same as 'double' in UNIX C

language.

(3)

String

and Character: It is a sequence ofbytecharacters; ifthelength isodd,

thenit is adjustedtoeven byte length

by

terminating

with the nullcharacter. Theobject

lengthkeptinaheader blockstillindicatesword_size,not character size.

A Characterobjectisrepresented innegative 16-bitnumbers. That

is,

when it is

created,the systemdoesnothavetoallocate spacetoholdthecharacter value. Thenegative

indexnumberitselftellsus whatitrepresents. Therangefrom-100to-355isreservedfor

aCharacter_object, so that those objectscanbe convertedtoASCII characters

by

_adding

100totheindexnumberinC language.

(4)

C function method (Cmethod): The content of this object consists of a C

language function address and atoken ID (2-byte integer). Thetoken ID is supposedto

identify

each messagesymbolin a simple object. Ifthisobject receives a message symbol

"eval",

then theCfunctionpointedto

by

thefunctionaddress

('fnc')

wouldbeasfollows:

(*fnc)(obj,

token, env) OBJobj, env; shorttoken;

Typically,

a switch statement insidethefunctionpointedto

by

'fnc' switches C

language-written methods

by

_using the token ID 'token'. 'Obj'

is a target object in the caller's

activation recordobject. This type of object is added toa

dictionary

in theinitialization

phase.

(5)

Method: Thisincludesthreeobject pointers: atargetobject,a messagesymbol,

and an argument list. Ifthis method receives a message symbol

"eval",

first,

the target

object andeachargument are_evaluated,thenanewactivation recordiscreated,and thenthe

message symbolincludedinthemethod objectissentto theevaluatedtargetobjectwiththe

new activation record

holding,

if any, evaluated arguments. The algorithm will be

describedin detaillater.

(6)

Method list: Thisconsistsofalistofmethod objectsand aFileobject(anASCII

filelinkedtoaUNLX

file,

explained moreinthesection"Coordination withUNLX"). This

istheplace where translatedcodesfor statements separatedwith a semicolon are stored.

The Fileobjectisusedtoreferto thedocumentationofthe translatedcodes. Itisattachedto

aMethodlistwhentranslation_starts,rightaftertheFileobject receivesthemessage"trans".

Theusercan still seetheoriginal source

by

_sending'type'to theMethod list.

(7)

Dictionary: This isan even-lengthlist inwhich even-numbered

(2n)

slotshold

key

objects andthe _{corresponding}odd-numbered

(2n+l)

slotsholdvalueobjects. When

the

Dictionary

object receives a message "lookup" with an argument

KEY,

the list is

scanned _{only for} even-numbered slots to _{look up KEY} and the _{corresponding}

odd-numbered slot's valueisreturnedif it is found.

Otherwise,

the

Dictionary

object returnsthe

special objectILLEGAL.

(8)

Directory: Itconsists of a listof

key

objects and alist of value objects. Both

lists havethesamesize,becauseeach

key

object correspondstoeach value object. Notice

that a

Directory

objectis anothernameforacompoundobject,whichis the_onlyinstance

object thatcan inherit methods fromother objects. In that _{sense, the}

key

object andthe

valueobject are supposedtobetheinstancevariablename

(using

a

String

object) andthe

In

HOPS,

Directory

objects are

hierarchically

arranged. To implement this,special

instancevariables called"!pa" and"!me"are employed. Thevariable "!pa"holdsapointer

toa parent

Directory

_object, andthevariable" !me"holdsthenameof aself

Directory

object

ratherthan the self

Directory

_object

itself,

_{inorderto avoidthecyclicalstructure. Figure}

3.3 illustratesan exampleoftheseinstancevariable connections.

Root

directory (!)

key

value "!pa"

"!me"

"x"

"aDir"

23

Directory

!.p

"jpa"

key

value

'!me" _"aDir"

45.6

Directory

S.p.aDir

Figure 3.3 Anexampleof

directory

connections: a

directory !.p

hasaninteger instancevariable"x"and a

directory

instancevariable

"aDir",

while a

directory

l.p.aDir hasanfloat instancevariable"y".

A

Directory

object, namely a compound _object, is not always connected to the

parent

directory;

it couldbe assignedto alocal variable in a statement without

having

a

parentdirectory. Thegeneralrule of "!pa"

and "!me"

connectionsisthat theconnections

arepreserved unless a

directory

is disconnected from its original parentdirectory. If a

directory

isassignedtoalocalvariablerightafterit iscreated,theneventhevariables"!pa"

and "!me"

will not existin that directory. There is also a rule aboutdisconnection: ifa

directory

is disconnected fromaninstancevariableandthatvariablebelongstoa

directory

pointedto

by

a "!pa"

variableofthedisconnected

directory,

thenthe "!pa"variableofthe

directory

whose connectionisnot completed andthatthe_consistencyofthe

hierarchical

structureispreserved.

3.1.3.

Creation

of

Objects

Constantobjects(suchas

integer, float,

or_string)are created

by

a parser. Thereare

two ways tocreate other types of objects. One is to send a message "new" to a method

dictionary

(called_magic)which is attachedto thefirstslotofaheaderblock in anobject

being

created. HOPS

initially

creates a special

directory

"l.dict",

under which all the

magicsforprimitive objects are boundto the_{corresponding}classname. Forexample, the

instancevariable ".Directory"in"Ldict" holds a method

dictionary

fora

Directory

object.

Sothe

following

statement creates a new

directory

named

"aDir"

underthecurrent_working

directory.

.aDir=

!.dict.Directory

new;

The other_way to create anobject is to send a message "new" to the same-class instance

object. The

following

statement expressesthesameideaasthatabove.

.aDir=new;

The message

"new"

is received

by

the current _working

directory

which is a

Directory

instanceobject. This waygivesthemost concise expression of_creatingadirectory.

Althoughthese twoarebasicmeans tocreate an _object, thereare other waystodo

so,

depending

on thecharacteristics oftheobject. For_example,anIntervalobjectiscreated

by

sendinga message "to"toanIntegerobject asfollows:

.a= 1 to

5;

//

createsanIntervalobjectwhichisa rangefrom 1 to5.

3.1.4. Reference Counts

HOPS adopts reference counts

[11]

as _memory management algorithms. This

methodcalledgarbage collection. On theother

hand,

thedisadvantageofthismethodis thatit cannot recover a cyclical structurein whichoneoftheslotsin a_object,

directly

or

indirectly,

points to the self object.

Therefore,

when

designing

the basic structure of

objects in

HOPS,

some solutions wereconsideredtoavoid a cyclical structure. The "!me"

connection of a

directory,

_{described in the previous section, is} an example of those

considerations.

Two basic operations are provided for the reference counts method:

IncObj

and DecObj.

IncObj

_simplyincreases

by

onethe 'refc'valuelocated intheheader block ofan

object.

DecObj

decreases therefc value

by

one and ifthevalue becomes _{zero, then the} objectisregarded asdiscarded becausethevalue zero meansthat_nothingisconnectedto

thisobject. Before collecting blocks used

by

thediscardedobject asgarbage,

DecObj

also

startstodecreasetherefc values of objects held inthe slots ofthediscardedobject.

Thus,

alltheblocksthat thediscardedobject uses are_recursivelycollected and pushedto the

top

ofthefree blockstack.

The

following

three paragraphs show techniques for

dealing

with the reference

counts method.

(1)

Referencecounts in an assignmentstatement: Suppose wehavethe

following

simple assignment statement.

$a=

$b;

An object is boundto each variable before the assignment.

IncObj

will operate on the

objectboundto

$b

and

DecObj

willoperate ontheobjectboundto$a.

Here,

IncObj

must becalledfirsttoallowforthenextspecial statement.

If

DecObj

is firstandtheobjectboundto$aisnot connectedto theothers,thenitisthrown

outbefore

IncObj

operatesonit.

(2)

Objectsattainedin anactivationrecord: The lifetimeof_anyobjectis determined

by

thereference _counter, so it should be bound to _{something in} orderto have a positive

reference count. An activation_{record, implemented} as anEnvironmentobject in

HOPS,

playstheroleof

holding

allthe

locally-bound

objects and_anyreturnedobjects. Ifa method

returns an objectto the caller, the activation recordforthe methodis destroyed and the

returned object is bound to the activation record for the caller. In the process of

destruction,

the objects used_onlyinside the method arediscarded because thereference

counter goestozero.

(3)

Garbage collection in a_parsing phase: Because methods are implemented as

objectsin

HOPS,

the_parsingprogram(written in C

language)

creates_manyobjectswhich

remainunboundtoobject slots.Ifthereis no_error, thenthoseobjects arebundled intoone

methodormethod

list,

whichiscollectedasgarbageafteritsexecution. Butit is difficultto

collectthoseobjects as garbagewhen a syntax erroris found.

Specifically,

HOPSapplies a

syntax-directedtranslationscheme

[1]

toparsing,so eachClanguage functioncorresponds

toa nonterminalintheHOPLsyntax. Ifacontrolisaddedtocollect_garbage,theflow of

eachfunctionwillbesodistortedthat thesystem couldlosethe advantage oftheclearflows

of a syntax-directedtranslationscheme.

HOPS solves thisproblem

by

_{collecting in} advance all the objects created in a

parsingphase. Thoseobjects areboundto a simpleListobject asits memberswhen

they

are created. Thislistobjectis discardedrightbefore thenext_parsingphase starts.

Thus,

3.1.5. C

Language

Interface

HOPS enables the system to be expanded

by linking

a new object written in C

language. It isan unfortunate factthat themore_purelyobject-orientedthe system

is,

the

more _slowly it runs. The reason is that a method

dictionary

search is

fundamentally

essential. HOPS provides the _programming environment in which _everything can be

written _{using HOPS} objects. But this _codingmanner is not always recommendedifthe

message-passing overhead gets intolerable. The user is encouraged to find out the

functional borderwhichsplits programsin HOPLandprogramsin C

language,

_considering

thespeed efficiency.

Appendix Ashows an example of an objectwrittenin C language for HOPS.

3.2. Lexical Analyzer and Parser

3.2.1. TTY Interface and Command File Interface

'

UNIX

file

descriptor

VI7

Line Buffer

characters

send "eval"

message

Lexical

Analyzer

token

objects

(1)

method definition

(2)

statement list

Figure 3.4 A lexicalanalyzerand parserin HOPS

Figure 3.4 shows adiagramofdata flowthroughthelexicalanalyzerand parserin

HOPS. Inputcharacters arepooledinaline buffer.

They

aretranslatedintotokenobjects

eventokensarerepresentedasobjects. Tokensare_usuallyimplemented

by

twoprimitives:

a tokenidentification number and therelated attribute values. Forexample, the lexical

analyzerproducesINTEGER (definedas anumber_somewhere)andits

binary

value

12,

so

that_using

INTEGER,

theparser can switchthesyntaxtree_{branches correctly} and passthe

value 12to thecode generation phase. Butanintegertokenin HOPS _{is simply}anInteger

object. Its magic (see the section 3.1 and Figure

3.2)

plays the role of the token

identificationnumber,andthevalueisembeddedin it.

HOPS has threeinput

interfaces,

as shownin Figure3.4:

TTY,

String

Object,

and

UNIX file descriptor. The

String

object accepts a message "getm" and returns a parsed

method object for the character string. Although the TTY interface seems to be

implemented

by

_givinga standardinput filedescriptorto theUNIXfile descriptor

interface,

it is differentinseveralrespectsfromtheUNLXfile descriptor interface. Ifa curses mode

(inwhichUNIXcurses

library

isavailable, andthe terminalmodeis switchedtoechoand

cbreak) ison,thenTTYinterfaceechoes eachinputcharacter, simulates a

backspace,

and invokes a commandline editor when_receiving an escape character. Thecommand line

editorenablesthe usertoedit theinput line whichrefers to the

history

ofrecently-typed

commands,justasin theUNLXKorn Shell [9]. Another difference isthat TTYinterface adds a semicolon at the end of an input line.

According

to the HOPL _{syntax, every}

statement should terminate with a semicolon. The typed-in command

has, however,

traditionally usedaCARRAGE-RETURNorNEW-LINEcharacter asitsterminator. The

compromiseofthe twoideasyieldstheautomaticadditionof a semicolon.

Theoutputoftheparserisalways aMethodlistobjector,if only one statementis

parsed, aMethodobject. Butthereare_{syntactically}twocategoriestobeparsed: a method definitionand a statementlist. There is ordinarily aFileobject under a

directory,

which

contains allthedefinitionsof methodsinthedirectory. Theparsertranslates thisFileobject intoa methoddefinition. Thestatementlist istypedin fromaTTYterminalorisstoredina

3.2.2 Syntax Analysis

Intheinitialstage ofthesyntax_{design for}

HOPL,

theHOPL grammarwascleanin a sense that the parser needed to look ahead at _only one token in order to decide the

deviationtree.

However,

inits finalformtwo token look-aheadwas used. Thestructure oftheparser program wouldhavebeentoocomplicatedtoallow onetoken

lookahead,

due

tothe problems

described

below.

(1)

Localvariable_namingproblem: Localvariablesincludeargumentvariablesand

temporarily-definedvariablesinsidea compound statement.

They

are_originallyreferenced withadollarsign_{prefix, '$'.}

However,

_{after some programs are} writtenin

HOPL,

_adding the '$' sometimes turns out to be cumbersome. For example, consider the

following

statementin HOPL.

for

(

$i=0;$i<10;$i=$i+l)

$iprint;

The use of theprefix gives us an easy-to-readformat in which the variable 'i'

is quickly

found to be a local variable. On the other

hand, typing

the dollar sign on a standard keyboardrequires two

keys,

the'$'

key

andtheshiftkey. Thisisnotefficient,considering the frequentuse of thelocal variables in a program.

Therefore,

a statement such as the

following

is desirable.

for

(i=0;i<10;i=i+l)

i_print;

Unfortunately

thereisaprobleminthisstatement. Itisagainstthebasicconceptin HOPL

that _{every starting identifier is} to be regarded as a message symbol sent to the current

working directory.

Accordingly,

the original grammar interprets the

"i"

as a message

symbol to the current _working

directory

in the two _expressions, "i+1" and "i print".

Finally,

therule addedtothegrammaristhatiftheparsermeets a special character(suchas

for

(i=0;i<10;i=i+l)

$i_print;

Ifakeywordmessage is sentto an objectbound to alocal _{variable, the}dollar signmust

precedethelocalvariable name.

(2)

Negativenumber_parsingproblem: Intheoriginal_{grammar, the}lexicalanalyzer

recognized negative_numbers,whosedigitsmust

immediately

followa minus signwithout

any space characters. As aresult,the

following

statementshave syntaxerrors.

5

//

Sending

a message

'-'

to thecurrent_working

directory

with'5'.

//

(There isa space characterbetween'-' and

'5'.)

3-5

//

Nomessage symbolbetweentheobject

'3'

andtheobject '-5'.

3- _-5

//

'3'

receives a message ' ' with anargument '5'.

Thereasonfortheerrors originatesinthefactthatthegrammaradopts

binary

operatorsand

postfix_operators,notprefixoperators. Whatwasdonetoeliminatetheabove errorswas

tomaketheminus sign'-' one separatedtokeneventhough the

subsequentcharacterisalso aspecialcharacter,

to

lexically

analyze_onlypositive numbers (without

'-'),

*

torecognize negative numbersifa minustokenfollowsa positivenumber

tokenin the HOPL's

'expression',

and

toaddthe

following

productionrules.

number-object:

-number-object

positive-integer-object

3.3.

Implementation

of

Control Structure

3.3.1. An

Environment Object

An

Environment

objectisan activation recordin HOPS. Thepurpose ofthisrecord

is principallytogive an appropriatescopeto the_{currentlyrunning}method andtomaintain

the current _{working directory. At the same time, its practical role is to point to}

every

locally-used object andtohave itsreference countbeatleastone,inordertonot permitthe

reference counts algorithmtocollectitas garbage. An Environmentobject iscreatedjust

before a messageis senttoanobject andit is destroyed justafter a valueisreturnedto the

caller'sEnvironmentobject. Whenit is

destroyed,

the

DecObj

operatortries toconsume all

theobjectsboundtoitsslots(orinstance_variables)

by decrementing

theirreference counts.