"Declarative" or "Functional"

I was playing around for some time with "functional" thing like Haskell and Erlang. Actually I think things like "Scala" (on JVM) and "F#" (on CLR) are very promising.
But I came across with a new view. I know features like "first class functions" and "concurrency"(in Erlang) are very useful.
Now my question is, in syntax level, is to be declarative as important as to be functional?
(Please include enhancements like multiple assignments and list comprehensions in to be declarative.)

I, for one, really don't

I, for one, really don't understand what you are trying to ask. Do you mind trying to rephrase your question? Perhaps give an example of what you have in mind?

In the context of discussion of the sort held here, both "functional" and "declarative" are used as regards language semantics. Both of these are not purely syntactical issues.

By Ehud Lamm at Sun, 2007-04-08 15:00 | login or register to post comments

declarative vs functional

i think "declarative" and "functional" and "procedural" are each best viewed as aspects of computations, or alternative means of expressing computations. "procedural" is command like, and sometimes that's exactly the mode of expression that suits. when procedures get large, and need organizing, a functional means of expression can help do that, and also can help organize the expression of computation so its exposure or "cross section" to changes is minimized. "declarative" sometimes suits when there is an implicit "behind the scenes" procedure or process that's going to do something uniform with the assertions or statements presented.

these pop-up in all kinds of places. the single inheritence hierarchy lookup mechanism in OO is a kind of declarative device. a class library is a kind of declarative assertion, although it is not text or statement-like. (why should declarations not be able to be trees?)

and it oughtn't be surprising that they don't suffice for all contexts. asynchronicity is a world where additional semantics are needed. now, y'might be able to express them using devices like continuations, but there is a need to step outside of declarative, functional, or (IMO) procedural. and asynchronicity is a different beast if it is large grain, such as tasks, or small grain, such as concurrent evaluation of expressions assuming absences of side effects and canonical copy. (for instance, that's what the engine powering Second Life does, although the Linden Scripting Language is hardly something you'd identify as fitting neatly into any of these categories.) the other world is error handling, and it depends upon whether the errors are primarily errors in the software, or if computations can be corrupted by hardware errors, or, as yet another case, whether errors or "surprises" are part of the application, such as controlling a robot arm which is supposed to place or grasp, but no confirming sensor input has been received about its target.

By bayesianlogic at Sun, 2007-04-08 18:42 | login or register to post comments

Well, functional does not

Well, functional does not necessarily mean declarative, and the other way around.

Functional languages, typically are called that because of the use of higher order and first class functions.

Declarative is simply that you can only assign things values once.

There are a few languages which are both, Erlang/Haskell as you've mentioned. But there are some have one but not the other. Scheme is an example of functional, non-declarative language, and Prolog is an example of a declarative, non-functional language.

To me, neither has a huge impact to the syntax, really it's what the author things is nice and makes sense at the time. That, and it's easier to get people to look at your language if your language looks similar to their language :P

By Gavin Harrison at Mon, 2007-04-09 03:48 | login or register to post comments

I respectfully disagree with

I respectfully disagree with this definition. Single-assignment and immutability is not sufficient for a language to be declarative. Declarative means that code does not encode how computations occur, just what occurs. Admittedly, this is a very fuzzy definition, and it is easier to just say declarative = immutability, but that really misses the point. I also think the declarative label should be applied to code rather than languages, as non-declarative code can be expressed in any Turing-complete language.

Code that is declarative does not encode control-flow details, which are dealt with by the language run-time. Prolog can be used as a declarative language in simple contexts, but for complicated programs that require cuts or lots of recursion, code becomes very non-declarative as programmers are exposed to a lot of control details. Likewise in Haskell, especially since imperative programming is conveniently done with monads. IMHO, recursion is as non-declarative as assignment, as it is easy to simulate one with the other. It is definitely possible to express declarative code in Prolog and Haskell, but it is also possible to express declarative code in Java or even assembly. Declarative code in these latter languages would just look really ugly, and their declarative nature would be obscured by syntax.

Syntax issues are important when designing a declarative language. If we want to make two values are equivalent, i.e., x is y, its much better to write x = y or x==y or x is y, rather than x.set(y), where the declarative nature of the code is obscured by syntax (it looks like an assignment rather than a declarative relationship). Expressing declarative code in Java is ugly, as everything is done through assignment, and it is difficult to tell that the code being written down is actually declarative. Also consider expressing declarative rules in Java that execute via a rule engine. On the other hand, Scala list comprehensions provide a nice declarative syntax for abstracting over data that hides less declarative function call and closure creation details. Also, using operator overloading in Scala, it is possible to also write decent Prolog code.

Of course, my definition is controversial. I would like to know if other people here think it is reasonable.

By Sean McDirmid at Mon, 2007-04-09 04:46 | login or register to post comments

Yes, declarative is what should happen, not how.

Single-assignment, immutability, and the elimination of side effects could be applied to any imperative/procedural language without affecting the language's nature at all.

Declarative-ness absolutely lies in the restriction of only being able to specify *what* should happen, rather than how.

I'm always irritated when functional and declarative terminology is mashed together -- I see them as being quite distinct.

By Chas Emerick at Fri, 2007-04-20 17:35 | login or register to post comments

Some Notes ...

I have a view : the software world suddenly understands there is a big problem named concurrency and by now there is a huge short coming about that, the coming up hype around Erlang proves that. At the same time everybody now hurry up to "solve" the problem by i.e. providing something "Erlang-Style" and feeding some buzz.
On the other hand research results are coming out to be used in public pragmatically. Haskell is influencing many things (areas) even new and interesting ones like NixOS.
But always something infects overall direction of software development space ;something like C++, which at it's time was proper. But I hate to start with another C++ the new age (I prefer something mixed up of declarative and functional : Scala i.e.).
What I say is a very simple observing at "feeling" of the syntax; and I think it is important; Ruby proves that. I mean to "feel" declarative in the syntax, while you have a good backbone of type system that gives you enough confidence to continue on your way.
(About dynamic languages : I like them as DSLs but not a developing language. This is not offensive, I do respect all people who try to make a better world of software developing.)
So which aspect is more important to you? more used by you? more pleased you?

By kaveh.shahbazian at Mon, 2007-04-09 08:59 | login or register to post comments

Lambda the Ultimate

User login

Navigation