Related articles |
---|
Gotos may be Harmful, but Labels are Neat! bburshte@us.oracle.com (Boris Burshteyn) (1994-12-16) |
Re: Gotos may be Harmful, but Labels are Neat! Ciaran.McHale@cs.tcd.ie (Ciaran McHale) (1994-12-21) |
Re: Gotos may be Harmful, but Labels are Neat! mikau@nmsu.edu (1994-12-22) |
Newsgroups: | comp.compilers |
From: | Ciaran McHale <Ciaran.McHale@cs.tcd.ie> |
Keywords: | design, realtime, bibliography |
Organization: | Computer Science, Trinity College Dublin |
References: | 94-12-114 |
Date: | Wed, 21 Dec 1994 16:08:45 GMT |
Boris Burshteyn <bburshte@us.oracle.com> writes:
>[Good riddance to GOTO statements but, unfortunately, with them went
>labels. Labels denoting particular points in the flow of execution may
>be useful as a debugging tool. Programmers might use, say, regular
>expressions, to specify legal sequences of labels (paths); the run-time
>system could then raise an error if the flow of execution strayed from
>the legal paths. Surely such a tool would be useful. Has anyone heard of
>such a system?]
I hope the above paraphrase of Boris's long posting is accurate; my
apologies if it is not.
I know of several language facilities that have a similar intention.
One is pre- and post-conditions as used in, say, the Eiffel language. I
have not used Eiffel myself but some people I know who have used it say
that its support for pre- and post-conditions is excellent for
discovering both coding bugs and design bugs.
Strange as it may seem, another place you might look is the area of
synchronisation. You see, one way to view synchronisation mechanisms is
that they will _delay_ a process until it is safe for it to continue
along (what you call) a path. If the implementation of a
synchronisation mechanism was changed so that it raised a run-time
error/exception rather than delay a process then it might be suitable
for your needs. Many synchronisation mechanisms are based on the
concept of what I call a "guard" (e.g., as used in the Guide language
or my SP synchronisation mechanism). In effect, a guard is similar to
an Eiffel-style pre-condition except that if it evaluates to false then
it will delay the process until the condition is true rather than raise
an exception. This goes to show that the concept of synchronisation and
the concept of assertions in a sequential language are related.
In case you are wondering, despite the similarity of synchronisation
and sequential assertions, to my knowledge there has very little
published work on developing a unified mechanism that can be used for
both synchronisation and sequential assertions. Bertrand Meyer has done
some work in this area; so too has Klaus-Peter L"ohr. My PhD thesis
(submitted but not yet accepted/rejected; I am not giving out advance
copies of it) also mentions this briefly.
One synchronisation mechanism that might be of particular interest to
you is Path Expressions. It uses regular expressions to denote the
permissible interleavings of invocations upon a concurrently-accessible
object. Some researchers have proposed the use of Path Expressions for
use in debuggers which seems to be directly relevant to your needs.
The rest of this postings consists of bibliography details for
papers/researchers mentioned in this posting.
@incollection{Path-Expressions-1,
author = "R. H. Campbell and A. N. Habermann",
title = "{The Specification Of Process Synchronisation
by Path Expressions}",
booktitle = "Lecture Notes in Computer Science, No. 16",
publisher = "Springer Verlag",
year = "1973",
pages = "89--102",
annote = "This is the original paper on path expressions.
The version of path expressions described here is a bit
primitive but the paper is still worth reading"
}
@article{Path-Expressions-8,
author = "Bernd Bruegge and Peter Hibbard",
title = "{Generalised Path Expressions: A High Level Debugging
Mechanism (Preliminary Draft)}",
journal = "SIGPLAN Notices",
year = "1983",
volume = "18",
number = "8",
pages = "34--44",
month = aug,
note = "Special Issue: Procedings of the ACM SIGSOFT/SIGPLAN
Software Engineering Symposium on High-Level Debugging.
(This is also a special issue of SOFTWARE ENGINEERING
Notes 8(4), August 1983)",
abstract = "This paper introduces a modified version of Path
Expressions called {\em Path Rules\/} which can be used
as a debugging mechanism to monitor the dymanic
behaviour of a computation. Path rules have been
implemented in a remote symbolic debugger running on
the Three Rivers Computer Corporation PERQ computer
under the Accent operating system."
}
@article{Path-Expressions-9,
author = "Wenwey Hseuch and Gail E. Kaiser",
title = "{Modelling Concurrency in Parallel Debugging}",
journal = "SIGPLAN Notices",
year = "1990",
volume = "25",
number = "3",
pages = "11--20",
month = mar,
note = "Special Issue: Second ACM SIGPLAN Synmposium on
Principles \& Practice of Parallel Programming
(PPOPP)",
abstract = "We propose a debugging language, {\em Data Path
Expressions\/} (DPEs), for modelling the behaviour of
parallel programs. The debugging paradigm is for the
programmer to describe the expected program behaviour
and for the debugger to compare the actual program
behaviour during execution to detect program errors.
We classify DPEs into five subclasses according to
syntactic criteria, and characterise their semantics in
terms of a hierarchy of extended Petri Net models. The
characterisation demonstrates the power of DPEs for
modelling parallelism. We present {\em predecessor
automata\/} as a mechanism for implementing the third
subset of DPEs, which expresses bounded parallelism.
Predecessor automata extend finale state automata to
provide efficient event recognisers for parallel
debugging. We briefly describe the application of DPEs
to race conditions, deadlock and starvation."
}
@book{Misc-17,
author = "Bertrand Meyer",
title = "{Eiffel: The Language}",
publisher = "Prentice Hall",
year = "1992",
annote = "ISBN~0-13-247925-7"
}
@article{Other-Powerful-Sync-59,
author = "Bertrand Meyer",
title = "{Systematic Concurrent Object-oriented Programming}",
journal = "Communications of the ACM",
year = "1993",
volume = "36",
number = "9",
pages = "56--80",
month = sep
}
@article{Other-Powerful-Sync-46,
author = "Klaus-Peter L{\"o}hr",
title = "{Concurrentcy Annotations or Reusable Software}",
journal = "Communications of the ACM",
year = "1993",
volume = "36",
number = "9",
pages = "81--89",
month = sep
}
@inproceedings{Comandos-Sync-7,
author = "D. Decouchant and P. Le Dot and M. Riveill and
C. Roisin and X. Rousset de Pina",
title = "{A Synchronisation Mechanism for an Object Oriented
Distributed System}",
booktitle = "Proceedings of the 11th International Conference on
Distributed Computing Systems",
month = "20--24 May",
year = "1991",
pages = "152--159",
organization = "IEEE",
address = "Arlington, Texas",
abstract = "This paper presents a mechanism for synchronising
shared objects in a distributed system based on
persistant, typed objects. Synchronisation constraints
are expressed as separate control clauses and are
factored for a class of objects. The interference of
this mechanism with inheritance and transactions is
examined and solutions are proposed. Examples of
synchronised objects are provided and a semaphore-based
implementation of this mechanism is described."
}
@inproceedings{Comandos-Sync-14,
author = "Ciaran McHale and Bridget Walsh and Se\'an Baker and
Alexis Donnelly",
email = "{cjmchale,baker,donnelly}@dsg.cs.tcd.ie,
bwalsh@iona.ie",
title = "{Scheduling Predicates}",
booktitle = "Proceedings of the ECOOP'91 Workshop on Object-Based
Concurrent Computing",
editor = "M. Tokoro and O. Nierstrasz and P. Wegner",
pages = "177--193",
year = 1991,
month = jul,
note = "Published as volume~612 of Lecture Notes in Computer
Science. Springer-Verlag. Also available as technical
report TCD-CS-91-24, Department of Computer Science,
Trinity College, Dublin 2, Ireland."
}
Ciaran.
--
---- Ciaran McHale (cjmchale@dsg.cs.tcd.ie)
\bi/ Dist. Systems Group, Department of Computer Science, Trinity College,
\/ Dublin 2, Ireland. Telephone: +353-1-7021539 FAX: +353-1-6772204
http://www.dsg.cs.tcd.ie:/dsg_people/cjmchale/cjmchale.html
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.