to express regular languages we use regexp and for context free languages we can use an stack-like memory, I know context free languages have some specifications like center embedding, but still I'm not sure when we can be confidant a given language is context free language? for example why does natural language is not a regular language. is there any reason except center embedding?
Automata theory states that a regular language can be processed by a Finite State Machine (FSM). However, if a language has "center-embedding", then that language is a Context-Free Language(CFL) which requires a Push-Down Automata(PDA).
Importantly, a PDA is a FSM with an additional resource of a memory-like device that is a "stack" or "counter" in order to keep track of the embeddings.
Wikipedia says in Languages that are not context-free :-
To prove that a given language is not context-free, one may employ
the pumping lemma for context-free languages or a number of other
methods, such as Ogden's lemma or Parikh's theorem.
Wikipedia says in Deciding whether a language is regular :-
To prove that a language is not regular, one often uses
the Myhill–Nerode theorem or the pumping lemma among other methods.
why does natural language is not a regular language ?
Chomsky said in (1957): “English is not a regular language”. As for context-free languages, “I do not know whether or not English is itself literally outside the range of such analyses”.
I am adding that English is such a vast language which can't be recognised by a finite machine.
When talking about features of programming languages, such as in Programming Language Comparison and D Language Feature Comparison Table, I was wondering what aspect of languages the concept "features" belong to or are discussed under?
Semantics,
syntax
or something else?
Thanks and regards!
This is just a gut feeling, I'm not a language theory guy or anything. I'd say adding a feature to a programming language means both
adding semantics for certain circumstances or construction (e.g. "Is-expressions return a boolean according whether the type of a template argument matches some type according to the following fifty rules: ...")
defining a syntax that belongs to it (e.g. adding IsExpr : "is" "(" someKindOfExpression ")" in the grammar)
It depends entirely on what you mean by a "feature," and how it's implemented. Some features, like Java's generics, are nothing but syntactic sugar - so that's a "syntax feature." The bytecode generated is unaffected by using Java's generics due to type erasure. This allows for backwards compatibility with pre-generic (e.g. Java 1.5) bytecode.
Other language features go much deeper than the syntactic level, like C#'s generics, which are implemented using reification to provide "first-class" generic objects.
I don't think that there is a clean separation for the concept of programming language "features", as many features like garbage collection (Java) or pattern matching (Haskell) are being provided by the runtime environment. So, generally I would say that the programming language - the grammar - per se provides no features. It just determines the rules of the language (Syntax). As the behaviour is being determined by how the code (produced by the grammar by obeying its rules) is being interpreted, programming language features are a sematic aspect.
I am no language expert but I'm recently into languages and trying to get an overview of major concepts and "their" languages. This is similar to another question about books. So first, what are the major programming language concepts, e.g.
structured
procedural
object orientated
object orientated - prototype based (e.g. Java Script)
functional (e.g. Haskell)
logic orientated (e.g. Prolog)
meta (if a pure concept of it's own?)
stack based (e.g. Forth)
math based/array oriented (e.g. APL)
declarative
concatenative (e.g. PostScript)
(definitely incomplete list...)
and second to get a good crasp of these concepts, what would be the programming language that's based on/implementing its core concept most naturally and pure?
For example Java is OO, but it's not a good example because it's not pure OO due to atoms.
Lisp is a known to be a functional language, but it's multi-paradigm, so it's not pure. But Lisp may be a pure implementation of "list-based" (if it counts as concept).
Is there a language that's structured (no GOTO) but not procedural? (Maybe XSLT v1.x)
The term you're looking for here is "programming paradigm" and there are a whole lot of them out there. You can get a list of languages which support each from that Wikipedia page and its follow-up links.
For "pure" renditions of any of these, that's harder because it depends on what level of purity you're looking for.
For pure structured (under any sufficiently-loose definition of "pure" here) you can look, for instance, at Modula-2.
For pure object-orientation you're looking primarily at Smalltalk and its ilk if you want absolutely everything to be uniformly treated (not actually necessary under the most common definitions!) or you're looking at languages like Java and Eiffel if you'll accept primitive types under that heading.
For functional you're looking most likely at Haskell.
For logic programming the archetypical language is Prolog, but it's not really pure. The only (mostly-)pure logic language I know of is Mercury, and that only if you view its functional chunks as being essentially compatible with its logical chunks.
...and so on and so on. You get the idea.
I think Pascal is the canonical procedural language.
I also think Lisp (ironically not ML) is the canonical "meta" language.
For one, a macro is a program fragment which modifies a data structure that represents a program fragment---so you use the language to tweak the language. Secondly, it's considered common practice to write self-hosting interpretors, traditionally called metacircular evaluators: they are programs which programs and run them.
Of course, any other language can do that. In Python you have access to the python compiler, and PyPy is a python implementation in python. But Lisp has, I think, the strongest tradition of doing this.
But I'm a Lisp outsider, so what do I know... 'hope-this-helps ;-)
Thanks to JUST MY correct OPINION's answer I was pointed in the right direction. I will give the list of paradigms together with their pure languages as far as I found out till now:
imperative
non-structured --- early BASIC, Assembly
structured --- ?
procedural --- ?
modular --- Modula-2, maybe Pascal
object-oriented
class-based --- Smalltalk
prototype-based --- Self, maybe Java Script, Lua
declarative --- SQL, Regular Expressions, CSS
logic --- Mercury, maybe Prolog
functional --- Scheme, Haskell
tacit/point-free
concatenative --- Joy, Cat
On a different "axis" we have
scalar --- most of them
array --- APL
Don't know where to put it:
stack based --- Forth, Postscript
One of the main characteristics of functional programming is the use of side-effectless functions. However, this can be done in an imperative language also. The same is true for recursion and lambda functions (for example C++0x). Therefore I wonder whether imperative programming languages are a superset of functional ones.
I can't really say whether they are subset of one another. What I can tell, though, that (except for really esoteric languages) they are all Turing-complete, which means that in the end they're all equally powerful, but not neccesarily equally expressive.
Generally speaking, no; functional programming is a subset of declarative programming (which includes logic programming languages, like Prolog). Many imperative languages borrow elements from functional programming languages, but simply having lambdas or referentially-transparent functions does not make an imperative language functional; functional programming is about more than just these elements.
It is possible to implement a certain programming paradigm in a language which doesn't support the programming paradigm natively. For example its possible to write Object Oriented Code in C while it is not designed for this purpose.
Functional programming is a well developed programming paradigm of its own and is best learnt through languages like Haskell, LISP etc. And after you have learnt them well, even though you don't use these languages regularly, you may start using those principles in the day to day language you use on regular basis.
Some people may like to Google for Object oriented programming in C
A paradigm is a way of doing things, and there are two main programming paradigms: imperative and declarative. The fact that some languages allow to mix both paradigms doesn't mean that one is included in the other, but that the languages are multi-paradigm.
To clarify it a little bit more, let me continue with your analogy: if Lisp and OCaml (for example) are considered functional languages, and both of them allow imperative style... then should imperative be considered a subset of functional?
Most imperative languages don't have functions as first-order types, whereas most functionald o. (As does C++, via boost::function.)
By first-order type, this meas a value/variable can be of any type, an int, a bool, a function from int->bool. It usually also includes closures or bound values as well, where you have the same function, but some arguments are already filled in.
Those two are what functional programming is mostly about, IMHO.
I think it might be helpful to draw a distinction between paradigm and language.
To me, paradigms represent "ways of thinking" (concepts and abstractions such as functions, objects, recursion), whereas languages offer "ways of doing" (syntax, variables, evaluations).
All true programming languages are equivalent in the sense that they are Turing-complete and able, in theory, to compute any Turing-computable function as well as simulate or be simulated by a universal Turing machine.
The interesting thing is how difficult it is to accomplish certain tasks in certain languages or paradigms, how appropriate the tool is to the task. Even Conway's Game of Life is Turing-complete, but that does not make me want to program with it.
Many languages support a number of paradigms. C++ was designed as an object-oriented extension for C, but it is possible to write purely procedural code in it.
Some languages borrow/acquire features from other languages or paradigms over time (just look at the evolution of Java).
A few languages, like Common Lisp, are impressively multi-paradigm languages. It is possible to write code that is functional, object oriented or procedural in Lisp. Arguably, aspect-orientation is already part of the common lisp object system, and therefore "nothing special". In Lisp, it is easy to extend the language itself to do whatever you need it to do, thus it is sometimes called the "programmable programming language". (I'll point out here that Lisp describes a family of languages of which Common Lisp is only one dialect).
I think it doesn't matter which of the terms, declarative, imperative, functional or procedural, is a subset of which. What matters more is to understand the tools languages you're working with, and how those are different from other tools. Even more important is to understand the different ways of thinking that the paradigms represent, since those are your thought-tools. As with most other things in life, the more you understand, the more effective you become.
One way to look at it (not saying it's the right way 'cos I'm not a lang designer or theorist by any means) is that if the language is essentially converted to something else then that 'something else' must be the superset of the source. So bytecode is necessarily a superset of Java. .NET IL is a superset of C# and of F#. The functional constructs in C# (i.e. LINQ) are thus a subset of the imperative constructs of IL.
Since machine language is imperative, you could take the position that, therefore, all languages are imperative, because they are just abstractions useful for humans that are then boiled away by the compiler to procedural, imperative machine code.
Pattern mapping like
f:: [int] -> int
f [] = 0
f (x:xs) = 1 + f(xs)
is something that is for instance one thing that is not available in imperative languages.
Also constructs like curried functions:
add2 :: int -> int
add2 = (2 +)
is not available in most imperative languages
Yes, functional programming is a subset of imperative programming, but...
Yes, because there is nothing in functional programming that you can't do in imperative programming (syntax differences notwithstanding). You can "do" functional programming in an imperative language.
But...
The things you can't do are the key features of functional programming.
By limiting what you can do,
you make certain mistakes impossible,
you enable features (such as program analysis, simpler concurrency, simpler testing, etc).
Other benefits of functional programming are more subjective.
You often hear these arguments.
State allows side effects. Side effects are bad. Functional programming has no state. You can't have side effects without state.
This is a dubious benefit.
First, only unintended side effects are bad. Proper programming practices, such as limiting modification of state to privileged code, alleviate side effect issues.
Second, functional programming only has no internal state. If the program has IO (accessing files, network, hardware) you have external state, thus the potential of side effects.
Functional programs are easier to debug.
In some ways yes, like knowing the explicit path to an exception.
But having state to examine is a debugging benefit that functional programming does not have.
Functional programs are easier to understand.
This is only true if you are fluent in functional programming and not fluent in imperative programming.
I for one, being more fluent in imperative programming, find this argument to be false.
Are there any conditions that a language must satisfy so that a meta-circular evaluator can be written for that language? Can I write one for BASIC, or for Python?
To quote Reg Braithwaite:
The difference between self-interpreters and meta-circular interpreters is that the latter restate language features in terms of the features themselves, instead of actually implementing them. (Circular definitions, in other words; hence the name). They depend on their host environment to give the features meaning.
Given that, one of the key features of a language that allows meta-circular interpreters to be written for them is homoiconicity, that is, that the primary representation of the program is a primitive datastructure of the language itself. Lisp exhibits this by virtue of the fact that programs are themselves expressed as lists.
You can write it for any language that is Turing-complete, however, your mileage may vary.
For Python, it has been done (PyPy). A list of languages for which it has been done can be found at the Wikipedia article.