Map
Index
Random
Help
th

QuoteRef: backJ8_1978a

topics > all references > ThesaHelp: references a-b



ThesaHelp:
ACM references a-e
Topic:
program source as truth
Topic:
programming language design
ThesaHelp:
references a-b
Topic:
problems with the von Neumann architecture
Group:
access to data
Topic:
no need for replacement
Topic:
programming as mathematics
Topic:
expression language
Topic:
statement language
Topic:
programming language
Topic:
language flexibility
Topic:
programming style
Topic:
extensible languages
Topic:
transformation of programs
Topic:
function definition
Group:
function
Topic:
universal data type
Topic:
function application
Topic:
functional programming
Topic:
exception handling by unique value
Topic:
lattice theory of types
Topic:
reduction languages
Topic:
top-down vs. bottom-up design
Group:
program control
Topic:
no need for variables
Topic:
undefined, null, and other signal values
Topic:
procedures as data
Group:
program proving
Topic:
reduction machines
Topic:
binding of names to objects
Topic:
value as an object
Topic:
higher-order functions and combinators
Topic:
symbol table
Topic:
hash table and hash functions
Topic:
programming with a database of modules
Topic:
state machine
Topic:
state
Group:
naming
Topic:
variable as function that accesses an object's value

Reference

Backus, J., "Can programming be liberated from the von Neumann style? A functional style and its algebra of programs", Communications of the ACM, 21, 8, pp. 613-641, August 1978. Google

Quotations
614 ;;Quote: few programming languages are sufficiently cheaper or more reliable to justify producing or using them
QuoteRef: backJ8_1978a ;;614 "Underlying every programming language is a model of a computing system that its programs control
615 ;;Quote: the 'von Neumann bottleneck' is the channel between the CPU and memory
615 ;;Quote: much of memory traffic is data addresses and operations and data for computing addresses
615 ;;Quote: programming is basically planning and detailing the enormous traffic of words through the von Neumann bottleneck
615+;;Quote: in von Neumann architectures much of memory traffic is for finding data
615 ;;Quote: conventional programming languages are modeled on the 'von Neumann' computer
616 ;;Quote: the assignment statement keeps us thinking in word-at-a-time terms
616 ;;Quote: the world of expressions is orderly, has useful algebraic properties, and performs most useful computation
616 ;;Quote: the world of statements is a disorderly one, with few, useful mathematical properties
617 ;;Quote: a programming language provides a fixed framework and changeable parts
617+;;Quote: von Neumann languages must have their semantics closely coupled to the state; every computational detail changes the state
617 ;;Quote: von Neumann languages provide an immense framework and limited changeable parts
617 ;;Quote: a programming language should have a small framework that can accommodate many powerful features as changeable parts
618 ;;Quote: with an algebra, can prove theorems by mechanical transformations using algebraic laws
619 ;;Quote: a functional programming system is made of a fixed set of functional forms
619+;;Quote: all functions in a functional programming system map an object into another object
620 ;;Quote: a Red object is an atom, a sequence, or bottom
620 ;;Quote: an FP system has a single operation, application; in f:x, f is the operator and x is the operand
620 ;;Quote: all functions in an FP system map objects into objects; bottom-preserving, f.bottom. = .bottom.
622 ;;Quote: in FP, a functional definition consists of a function name and a functional form that replaces the name
623 ;;Quote: a functional program for matrix multiply is hierarchically constructed from simpler components; without word-at-a-time programming
623+;;Quote: a functional program for matrix multiply contains no variables, no loops, no control statements, no initializations, no declarations
623+;;Quote: a functional program for matrix multiply does not name its parameters or intermediate results
623 ;;Quote: a functional program for matrix multiply yields .bottom. for inappropriate arguments; it is perfectly general
623 ;;Quote: could use FP to transform a matrix multiply program which is space inefficient to efficient code
623 ;;Quote: if function expressions are not objects, then can not compute a program or define new functional forms
624 ;;Quote: with reduction languages, can derive proofs in terms of the algebra instead of a separate logical system
631 ;;Quote: a functional form is a sequence of objects, the first determines the form, the others are parameters
632 ;;Quote: meaning of an FFP expression found by replacing innermost application with its meaning
632 ;;Quote: in an FFP system, use a representation function to associate objects to functions
632 ;;Quote: in Red, each object is its own meaning
632 ;;Quote: after metacomposition, the operator of a sequence has the original sequence and operands as its operand; can rearrange and reapply at will
632 ;;Quote: the meaning of an FFP application x:y is the meaning of the result of applying the function represented by x to y
633 ;;Quote: dictionary by triples ; the functional form 'fetch' can retrieve value given a name
634 ;;Quote: defines semantics of FFP systems by the least fixed point operator; determines value given an expression
635 ;;Quote: the state of an Algol program is modified by an 'enormous cable' of specialized 'wires' for every statement type
635 ;;Quote: with 'von Neumann' languages can not modify the state as a whole
635 ;;Quote: a programming system should allow large state transformations by general functions
635+;;Quote: program semantics should not depend on baroque protocols for communicating with the state
635 ;;Quote: AST systems can retrieve the whole state, retrieve the definition of a function, or compute the new state
638 ;;Quote: AST applies 'SYSTEM' to the input and obtains its meaning from the current set of definitions D; produces output and a new D'
638+;;Quote: the state of an AST system is a set of definition rules for determining transitions
638 ;;Quote: a major weakness of von Neumann languages is not treating names as functions


Related Topics up

ThesaHelp: ACM references a-e (259 items)
Topic: program source as truth (17 items)
Topic: programming language design (53 items)
ThesaHelp: references a-b (396 items)
Topic: problems with the von Neumann architecture (11 items)
Group: access to data   (12 topics, 307 quotes)
Topic: no need for replacement (4 items)
Topic: programming as mathematics (27 items)
Topic: expression language (13 items)
Topic: statement language (10 items)
Topic: programming language (29 items)
Topic: language flexibility (34 items)
Topic: programming style (47 items)
Topic: extensible languages (69 items)
Topic: transformation of programs (27 items)
Topic: function definition (25 items)
Group: function   (12 topics, 232 quotes)
Topic: universal data type (18 items)
Topic: function application (18 items)
Topic: functional programming (43 items)
Topic: exception handling by unique value (8 items)
Topic: lattice theory of types (15 items)
Topic: reduction languages (17 items)
Topic: top-down vs. bottom-up design (30 items)
Group: program control   (27 topics, 547 quotes)
Topic: no need for variables (13 items)
Topic: undefined, null, and other signal values (33 items)
Topic: procedures as data (22 items)
Group: program proving   (10 topics, 310 quotes)
Topic: reduction machines (14 items)
Topic: binding of names to objects (16 items)
Topic: value as an object (29 items)
Topic: higher-order functions and combinators (19 items)
Topic: symbol table (4 items)
Topic: hash table and hash functions (41 items)
Topic: programming with a database of modules (94 items)
Topic: state machine (67 items)
Topic: state (35 items)
Group: naming   (32 topics, 784 quotes)
Topic: variable as function that accesses an object's value (21 items)

Collected barberCB 1980
Copyright © 2002-2008 by C. Bradford Barber. All rights reserved.
Thesa is a trademark of C. Bradford Barber.