Re: argument about encapsulating data sublanguage

On 2006-12-29, Walt wrote:

> When you hide your formulas behind a procedure, what does the
> procedure stand for? Does it stand for the hidden formulas, or for
> the results the hidden formulas yield?

Precisely. What is/does the procedure? In functional programming languages, without side effects, the intent and semantics are clear, by design: the function/procedure calculates a result solely dependent on its arguments. In procedural languages there might be untold, messy, side effects. They make the precise semantics of the procedure quite unclear.

In a language devoid of side effects, like Haskell or SML, and with a strong enough type system, it shouldn't be too difficult to model relational algebra at the language level. After that, it shouldn't be too difficult to make the compiler really understand relations, in the sense that a DBMS understands relational algebra specified thru SQL.

My own programming style is far more dataflow than procedural. That's why I can also appreciate the purely functional approach: it specifies the flow of data much more explicitly than the procedural style, and so enables the declarative content to be utilized more fully by the compiler. That's also why I can relate easily to the relational model: the RM comes close to dataflow programming, in that it has explicit assignment, but yet guards unexpected side effects extremely tightly, given the transactional semantics.

-- 
Sampo Syreeni, aka decoy - mailto:decoy_at_iki.fi, tel:+358-50-5756111
student/math+cs/helsinki university, http://www.iki.fi/~decoy/front
openpgp: 050985C2/025E D175 ABE5 027C 9494 EEB0 E090 8BA9 0509 85C2