🚀 go-pugleaf

>|>With a referentially-transparant functional language
>|>(free of side-effects) you can argue that certain expressions
>|>denote functions, function arguments, function applications, and so on.
>|>One argues that the entire program can be viewed
>|>as a mathamatical assertion, and thus that the language is declarative.

In article <673@rocksanne.WRC.XEROX.COM> mantha.wbst128@xerox.com writes:
>Surya Mantha
>	Are you saying -- please correct me if I am wrong
>	-- that referential transparency (R.T.) is a *necessary*
>	condition for "declarativeness"?

Since declarativeness is not a mathematically-precise concept,
I'd be a fool to take such a strong stand.
Let's just say that the looser the dependence
of an expression upon its context -- the more declarative.

>	Characterizing the behaviour of logical variables semantically
>	is a problem.

It's not a problem for pure Prolog.  It is a problem
for Prolog with extra-logical features, however.

>	In the presence of "laziness", one has to deal
>	very carefully with unification.  The semantics
>	should not only be bottom-avoiding,
>	it should also be top(error)-avoiding. 

I am revising for publication a paper by Bharat Jayaraman and myself
which combines lazy (outermost reduction, to be precise)
higher-order functional programming with 1st-order horn logic
via relative set abstraction.  Both operational and denotational
semantics are based on conventional domain theory,
(with a few run-time program transformations
thrown in for efficiency).  There is no top(error)-value
in the language -- though certain operations
will be explicitly undefined(bottom).

Logical variables are not _explicit_ features of the language,
but are introduced as an operational optimization
to avoid blind enumeration of certain generator sets.

>	We (Gary Lindstrom and I) have, however,
>	arrived at a somewhat satisfactory account of
>	lazy functional languages with logical variables.
>	We use the notion of Information Systems
>	(introduced by Scott to give an alternative formulation
>	of domain theory) to capture the notion
>	of "constraint solving" inherent in unification.
>	Instead of viewing programs as plain mathematical functions,
>	we view them as entities that impose constraints
>	on the values of logical variables in a *global* logical store
>	-- a term introduced by Saraswat in his thesis.
>	We can show compositionality (modulo the logical store).

I'd welcome seeing anything you've written.

>	The worst (of the logic programmers) are those
>	who palm off EXTRA-LOGICAL features as being
>	*meta-logical*.

Even if a feature _is_ meta-logical --
doesn't that mean it belongs in a _meta-language_
(e.g. a language-oriented programmable environment)?

	Frank Silbermann	fs@cs.tulane.edu
	Tulane University	New Orleans, Louisianna  USA