[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [ProgSoc] CSS and Divs



nbsherid@xxxxxxxxxxxxx wrote:
John Elliot wrote:
So, 'commands' are not 'first class' in (many) functional languages,
such as Lambda calculus. However, as we can use those languages to
encode what are effectively commands (this being true when we can
implement turing machines), to say the language is 'declarative' isn't
really a precise description, in my view.

It isn't really, but it is a "bulk" classification around a large set of different styles of programming languages.

See!? :)

Imperative languages are also known as "procedural languages", because they are
procedural! There is some implied sequence that gives specific directions or
commands.

Here is a purely functional program:

 function a() { return 1; }
 function b() { return 2; }
 function f() { return a() + b(); }

Here is a procedure:

 int f() {

   int a, b;

   a = 1;
   b = 2;

   return a + b;

 }

Now, because of the nature of the functional program, which we assert is 'pure', we can parallelise the computation of a() and b(). That is, we know there will be no side-effects, so there is no need to conduct this processing in any particular order. However, before we can return our result for f() we will indeed need to have completed the evaluation of each of these functions. That is, we can't know the result of f() until *after* we know the result of a() and b().

In the procedure, before we can return the result of f(), we need to have determined the state of a and b. That is, we can not know the result of f() until *after* we know the state of a and b.

However, there is nothing about the program which precludes the parallelisation of the 'evaluation' of state a and b. That is, the *syntax* of this programming paradigm has nothing to do with the order of state evaluation. It is perfectly clear that the result of the state determination for a, and the state determination for b, do not cause effects in the same domain, and are independent of each other. Thus, we can determine that state in parallel (ignoring the fact that our compiler would optimise the entire thing away, for now). We haven't asked for a to be assigned its value before b is assigned its. We have just shown two independent things which need to happen before we can determine our result.

It is perfectly reasonable to expect that an execution environment (i.e. a compiler, CPU, etc.) could unwind this 'planar graph' of our state dependencies.

I say these two programs are semantically identical. They are syntactically different, but beyond that they mean *exactly* the same thing.

Declarative languages do not impose such a sequence. Functional does it through
recursion, logical does it through deduction, abduction, etc. Rule engines do
it through backward- and forward-chaining.

'Procedural' languages don't impose sequence either, though. Not more so than functional, at least. (I know very little about logical programming languages (is there even one other than Prolog?) or rule engines.)


To the extent that side-effects do not occur in the same domain, the order of evaluation of the components of a procedure is irrelevant.

Imperative languages generally require explicit state, assignments and
(potentially) side-effects to actually get anything done.

So called 'imperative languages' don't 'require' this, though. (I can implement a C# program with no assignments, no explicit state management, and without side-effects.)


And turing machines do. (I can (actually... *I* can't, but someone can :) implement a lambda calculus program with assignments, explicit state management and side-effects.)

Pure declarative
languages only use state implicitly (or indirectly), because they are
implemented on von Neumann or Harvard architecture microprocessors. In this
environment, a declarative language must always have a 'virtual machine'
because it cannot be directly converted to executing on these microprocessors
without some direct sequencing of logic (either during compilation or runtime
interpretation).

Are there any other type of processors yet?

















-
You are subscribed to the progsoc mailing list. To unsubscribe, send a
message containing "unsubscribe" to progsoc-request@xxxxxxxxxxxxxxxxxxx
If you are having trouble, ask owner-progsoc@xxxxxxxxxxxxxxxxxx for help.