Thread View: comp.lang.functional
2 messages
2 total messages
Started by Simon E Spero
Tue, 15 Jan 1991 17:12
Various Subjects
Author: Simon E Spero
Date: Tue, 15 Jan 1991 17:12
Date: Tue, 15 Jan 1991 17:12
81 lines
3613 bytes
3613 bytes
Archives:
I've been away from the net for a couple of months (what a great
day to start work), and I was wondering whether anybody out there archives this
group. If so, can the archive be accessed via Internet?
Haskell:
Has a shippable version of Yale Haskell been released yet? If so,
where does it live, and if not, is the delay related to problems with T and
large programs? I had a lot of problems of this nature whilst writing part of
a back end for Lazy Hope+C (and had hoped to borrow any workarounds from
Haskell).
Cookbook:
Can anybody give me a reference for a transformation cook-book;
something covering various tried and tested transformation tactics? Does one
exist; if not can anyone suggest a good set of review papers?
Global State:
I've noticed that most programs I've written that maintain a state
tend to have a fairly large number of paramaters which are passed un-inspected
down through various functions, until they finally used, updated, and then
passed back up the chain in a sequence of ever increasing tuples. One idea
I had for dealing with this problem is through the use of some sort of
automatic paramaters. These would be a collection of identifiers that would
be automatically added to each and every function's paramater list and it's
output tuple. Functional calls would have to be expanded into 'let' statements,
and values from one call would be passed into the next. References in let
statements to one of the global identifiers would be replaced by the
appropriate new identifier.
For example: (hopeish notation)
global symtab;
compiler(a,b,c) <= let coke == addsym(b) in
let toke == lookup(a) in
(toke,coke,c)
would go to:
compiler(a,b,c,symtab) <=
let (coke,symtab') == addsym(b,symtab) in
let (toke,symbtab'') == lookup(a,symtab') in
(toke,coke,c,symtab'')
f(g(x),h(x))
would go to:
let (r1,symtab') == g(x,symtab) in
let (r2,symtab'') == h(x,symtab') in
f(r1,r2,symtab'')
addsym(a) <= let (key,symtab) := insert(a,symtab) in
key
would go (naively) to:
addsym(a,symtab) <= let (key,symtab') == insert(a,symtab) in
(key,symtab')
Unused/unmodifed values could then be removed - much of the work is already
done by strictness analysis.
Before the hidden-state flames start coming in, can I add that this sort of
notational convenience really belongs in an editor, and not in a compiler; the
programmer should be able to swap between one format and the other so that it
remains quite clear where each value is coming from, and so that 'real'
transformations don't need to know about this pseudo-state.
Any comments?
Simon
--
ses@techunix.technion.ac.il | Look at them Iraqis, that's the way you do it,
ses@techunix.bitnet | Your fire your missles on the CNN.
------------------------------------------------------------------------------
Tel +272-4-292658, Fax +272-4-236212, Tlx 46406 |A Corner of a Foreign field.
Transformation Cookbook (was Re: Various Subjects)
Author: Eerke Boiten
Date: Fri, 01 Feb 1991 14:23
Date: Fri, 01 Feb 1991 14:23
126 lines
5004 bytes
5004 bytes
In article <9883@discus.technion.ac.il> ses@techunix.BITNET (Simon E Spero) writes:
>Cookbook:
> Can anybody give me a reference for a transformation cook-book;
>something covering various tried and tested transformation tactics? Does one
>exist; if not can anyone suggest a good set of review papers?
There is a matter of taste involved. If you like a calculational approach,
you might look at Backus' paper introducing FP:
@ARTICLE{
Bac78,
Author= {Backus, J.},
Title= {Can Programming be Liberated from the {V}on {N}eumann Style?
{A} Functional Style and its Algebra of Programs},
Journal= cacm,
Volume= 21,
Pages= {613--641},
Month= Aug,
Year= 1978}
or at the Bird-Meertens formalism (there are other and maybe better
references):
@INCOLLECTION{
Bir89b,
Author= {Bird, R.S.},
Title= {Lectures on Constructive Functional Programming},
Crossref= {NATO.ASI.F55},
Pages= {151--218}}
(Marktoberdorf 1988; crossref's: see at the end of this article).
Both of the above methods are concerned with functional formalisms only.
An alternative is the wide-spectrum approach of the CIP project in
Munich:
@string{sv= {Springer-Verlag}}
@BOOK{
Bau82a,
Author= {Bauer, F.L. and W{\"o}ssner, H.},
Title= {Algorithmic Language and Program Development},
Publisher= sv,
Address= {Berlin},
Year= 1982}
%% Bau82a: an early textbook on the transformational development of
%% programs according to the CIP method.
@BOOK{
CIP85,
Author= {Bauer, F.L. and Berghammer, R. and Broy, M. and Dosch, W.
and Geiselbrechtinger, F. and Gnatz, R. and Hangel, E. and
Hesse, W. and Krieg-Br{\"u}ckner, B. and Laut, A. and Matzner, T.
and M{\"o}ller, B. and Nickl, F. and Partsch, H. and Pepper, P.
and Samelson, K. and Wirsing, M. and W{\"o}ssner, H.},
Title= {The {M}unich Project {CIP}. Volume {I}: The Wide Spectrum
Language {CIP-L}},
Series= lncs,
Volume= 183,
Publisher= sv,
Address= {Berlin/Heidelberg/New York},
Year= 1985}
%% CIP85: defining report of the wide spectrum language CIP-L, including
%% (definitional) transformations.
@BOOK{
Par90a,
Author= {Partsch, H.},
Title= {Specification and Transformation of Programs - a Formal
Approach to Software Development},
Address= {Berlin},
Publisher= sv,
Year= 1990}
%% Par90a: recent textbook on transformational development, CIP method,
%% contains a large number of transformations.
Below I've included some other interesting references:
@CONFERENCE{
Fea87,
Author= {Feather, M.S.},
Title= {A Survey and Classification of some Program
Transformation Approaches and Techniques},
Crossref= {Mee87},
Pages= {165--196}}
%% Useful reference article. Contains no transformations as such, but
%% surveys classifies transformations and strategies in literature.
@TECHREPORT{
Sta76,
Author= {T. A. Standish and D. C. Harriman and D. F.Kibler and
J. M. Neighbors},
Title= {The Irvine Program Transformation Catalogue},
Institution= {Department of Information and Computer Science, University
of California at Irvine},
Type= {Technical Report},
Month= jan, Year= 1976}
%% I haven't seen this; maybe someone from Irvine can tell more about
%% this. (I know you're out there ...)
@ARTICLE{
Dar76,
Author= {J. Darlington and R.M. Burstall},
Title= {A system which automatically improves programs},
Journal= acta,
Volume= 6, Number= 1,
Pages= {41--60},
Year= 1976}
%% Dar76: early paper about unfold-fold methodology. Contains a number
%% of transformation rules.
Now for crossref'd proceedings:
@PROCEEDINGS{
Mee87,
Booktitle= {Program Specification and Transformation. Proceedings of
the {IFIP} {TC2}/{WG2.1} Working Conference on Program
Specification and Transformation},
Title= {Program Specification and Transformation. Proceedings of
the {IFIP} {TC2}/{WG2.1} Working Conference on Program
Specification and Transformation},
Editor= {Meertens, L.G.L.T.},
Publisher= nhpc,
Address= {Amsterdam},
Year= 1987}
@PROCEEDINGS{
NATO.ASI.F55,
Title= {Constructive Methods in Computing Science.
{NATO ASI} Series Vol. {F}55},
Booktitle= {Constructive Methods in Computing Science.
{NATO ASI} Series Vol. {F}55},
Editor= {M. Broy},
Publisher= sv,
Address= {Berlin},
Year= 1989}
--
Eerke Boiten
Department of Informatics (STOP Project), K.U.Nijmegen
Toernooiveld, 6525 ED Nijmegen, The Netherlands
Tel. +31-80-652236. Email: eerke@cs.kun.nl
Thread Navigation
This is a paginated view of messages in the thread with full content displayed inline.
Messages are displayed in chronological order, with the original post highlighted in green.
Use pagination controls to navigate through all messages in large threads.
Back to All Threads