Whether this question is a wide range or not I would like to ask :
Is it possible to implement aspect-oriented programming (AOP) features into OCaml language?
It is interesting to observe that, in contrast to the traditional
concept of crosscutting in the OO setting where aspects typically
crosscut several classes, the majority of the applications of aspects
in functional programming only involve a single function in the
pointcut. We believe the realisation of this difference as concluded
by this paper is important to both the functional and AOP commu- nity.
There is a pressing need to properly interpret and develop of the
concept of ‘crosscutting’ in the functional setting before functional AOP spreads its wings.
[emphasis mine]
What Does Aspect-Oriented Programming Mean for Functional Programmers? (PDF)
Regardless, there are direct attempts/translations of AOP to OCaml or ML systems. From my comment, I don't find these convincing, and believe that proper use of modules and functors can do a lot to capture the demarcation of concerns. Those direct attempts are,
Aspectual Caml
PolyAml(PDF)
Aspect ML
Related
I'm looking for examples of usages in OCaml to demonstrate simple properties or theorems.
An example may be, given an ocaml definition of binary trees, demonstrate that the maximum number of nodes is 2^(h+1)-1.
I have founds such kind of examples for binary trees and graphs but nothing else.. any suggestion or links?
If you are speaking of proofs written on paper, the usages are essentially the same that with other languages: an informal reasoning based on a reasonable (but not formalized) model of the semantics of the program. To handle your case I would write two functions size and height, and prove by inductive reasoning on the tree that size h <= pow 2 (height h + 1) - 1, using an induction hypothesis on the two subtrees -- I can make this explanation more detailed but prefer to let you do it yourself if you wish.
If you want more formal proofs, there are several approaches.
Proof techniques based on hoare logics have been adapted to functional programming languages. See for example the 2008 work of Régis-Gianas and Pottier, A Hoare logic for call-by-value functional programs. They provide a formal basis for what can be used, still in hand-written proofs, to give a more rigorous (because down-to-the-metal) proof of your claim. It could also be used in a theorem prover but I'm not sure this approach has been fully worked out yet.
Another natural approach would be to write your program directly in the Coq proof assistant, whose programming language is mostly a purely functional subset of OCaml, and use its facilities for proving. This is not exactly like writing in OCaml, but quite close; then you can either mirror the implementation in OCaml directly, or use the extraction facility of Coq to get honest-looking OCaml code that has been "compiled" from the Coq program. This approach has been used to formalize the implementation of the balanced binary trees present in the OCaml standard library, and the two implementations (the OCaml one and the Coq one) are sufficiently synchronized that you can transfer results to prove some OCaml-side changes correct.
In the same vein, there are some attempts to design languages for certified programming that may be more convenient, on some domains, than a general theorem prover such as Coq. Why3 is such a "software verification platform": it defines a programming languages (not very far from OCaml) and a specification language on top of it. You can formulate assertions about your program and verify them using a variety of techniques such as general proof assistants (eg. Coq) or more automated theorem provers (SMT solvers). Why3 strives to support verification of classic imperative-style algorithm implementations, but also support a functional programming style, so it may be an interesting choice for experiments with certified programming if you don't want to go to full-Coq (for example if you're not interested in ensuring termination of your algorithms, which can be inconvenient in Coq).
Finally, there has been work on the following technique: read your OCaml program and automatically produce a "Coq description" out of it, that you can properties about with the guarantee that what you prove correct also holds in the OCaml implementation. This has been the main result of Arthur Charguéraud's 2010 PhD thesis, where the "Coq description" is based on the technique of "Characteristic fomrulae". He has been able to prove correct ML implementations of relatively sophisticated algorithms such as Union-Find or examples out of the Chris Okasaki's excellent "Purely Functional Data Structures" book.
(I frequently mention the Coq proof assistant; other tools such as Isabelle and Agda are equally suitable, but Coq is closer in syntax to the OCaml language, so is probably a good choice if you want to re-implement ML programs to prove them formally correct.)
If yes, then are there any patterns that are specific to C++, and some that are not?
Which are they, if any? Well I am referring to these design patterns: http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29
RAII is a powerful pattern that relies on C++'s scope cleanup mechanism. In garbage-collected environments this language feature is usually missing. Other languages (e.g. Ruby) have other ways of using user-provided control flow constructions.
I'm not sure if there is another answer other than "Yes".
If the design pattern depends on language-agnostic object behavior, the same DP can be applied across languages.
However if the design pattern is dependent on some language features, then translating it to another language would require some effort or be impossible. Some patterns might come into existence because of some characteristics of a specific language (but are not needed in other languages).
People come up with patterns all the time. So yes.
I think the best answer here is "it depends" because the notion of pattern has some fuzzy boundaries.
If you are willing to say "C++ virtual function" or "Java interface" is a "pattern" then, well, you have by default come up with a "pattern" that is applicable to exactly one language at the exclusion of all others. Given that a pattern is simply a way of solving a problem that can be applied in varying contexts, you could argue technically that single-language patters can in theory exist.
However the common use of the term "pattern" is something slightly more abstract than a specific language feature. What I think most people can agree on is that there are patterns that are specific to certain families of languages, where the family can be very small, e.g., languages supporting OO, supporting actors, supporting channel-based communication, etc.
When your pattern becomes so specific that the language family to which it applies winds all the way down to a single language, you get into the fuzzy area where people might quibble about whether something is a pattern or a language feature. The rationale here is that "well heck, can't someone just create another language based on this language so that the pattern will apply to the derived language too?"
However, if you can reasonably argue that your alleged pattern is indeed a way of solving a problem that can be used in different contexts, and that no other programming language in existence can reasonably implement this solution, then you can say yes.
.... Until someone creates that dialect! :-)
Yes.
The most notable way to see this is to experiment with a paradigm shift. For example, compare Java (OO) to Haskell (Functional).
Let's take the Flyweight pattern, in Java. In Haskell, it's a no-brainer, data (which is immutable) is implicitly shared.
Other example: the Command pattern. Haskell supports first-class functions (and curryism), commands are built-in.
Some will argue that DP exist to cover what a language does not provide in a built-in way. In this sense, the higher level a language, the more DP are embedded.
The patterns which uses the specific language functions like Multiple Inhertance in C++, Dynamic behaviors like Reflections are quite language dependent. GoF design patterns are considered as the base for most of the patterns but as the years went, systems became more complex and distributed. Hence the fundamental design patterns and principles were evolved and extended. Web frameworks and libraries are one of the best examples for implementing real-world scenarios to meet the developers/users need. Like dynamic page generation, AJAX etc. But I seriously believe that, the patterns must be generic and should not rely on languages.
For e.g if you're is using too much patterns which depends on PHP, may not help them to switch to some other dynamic languages like Python. The general/generic implementations can be realized easily across most of the languages.
What are the programming languages we can use in the development of an artificial intelligent system? which operating system should be used? can C or C++ programming languages be used?
What are the programming languages we can use in the development of an artificial intelligent system?
Prolog is a good start for reasoning systems. Lisp is a good start for symbolic systems. Both of those can be embedded in other languages, e.g., C++.
which operating system should be used?
Er.... any?
can C or C++ programming languages be used?
Yes.
You probably want to learn more about programming before you tackle AI.
Definitely. And it's a good choice too, because it can be made pretty well performing (which is the main problem in developing a good AI).
But there is no limitation, really. Any language will do.
Just about any language can be used but you want one that works well with your specific domain, and you are comfortable with using.
As already mentioned, PROLOG and LISP are both traditional AI languages. General purpose languages such as Java, C#, and C++ also have their uses.
Also if you are looking at aural language processing, then a language that is good at text processing and data structures would be ideal. Eg. Python and the NLTK toolkit.
Although some languages are more strongly associated with AI programming than others -- e.g., LISP, Prolog -- many different languages can be used.
Any of the general-purpose operating systems may be used.
You can use a procedural language like C. An OO language like C++, Java or C# offers some advantages. Functional and logical languages are also worth considering.
Personally, I've written one A-B game-playing program now in LISP, Java and C#.
Any language can be used to develop Artificial Intelligence, AI, applications; some make implementing the AI concepts easier than others.
Some old time favorites are LISP and Prolog.
If you are well versed in C or C++, then use either one to implement the concepts.
When you want to learn AI programming you should pick a language where you can concentrate on the problem domain instead of the language.
For example in a typical C program about half of the code concerns itself with memory management and error handling. By using a language that supports garbage collection and exceptions you can reduce this amount drastically.
The choice of language also depends on prior works. Are there any or do you want to start from scratch? If the prior works seem to be good, you can hope that they already chose an appropriate language.
It depends on the niche you are interested in, but C++ is probably the most popular language for artificial intelligence. You will find that most libraries are written for it.
You can use languages other than C++, too. Functional languages, such as LISP and F# are good choices for AI, because they offer good tools for decomposing complicated logic.
The operating system is not much of an issue. Whether you choose Windows, Unix, or Mac, you will find a few libraries that are not cross-platform and unavailable for your platform.
Even though OOP uses objects and data encapsulation, the code still writes out like a procedure. So what makes OOP loose the procedural label? Is it just because it is considered "high-level"?
Thank You.
It's not that Object-orient Programming is "non-Procedural"; it's just that the code we call "Procedural" is not Object-oriented (and not Functional and probably not a couple others)
It's not so much an either-or case, but a slow gradiate:
Spaghetti code -> Structured Code -> Object-oriented code -> Component code.
(UPDATE: Removed "Procedural" from the chart above, since it refers to all of the right 3/4rds of it)
In theory OOP and procedural programming are orthogonal concepts. The fact that they so intertwined in practice is probably more coincidence than anything else. Because it is so familiar, procedural syntax is the most human readable format around. Message-passing, functional computation expressions, and various other formats -- because of their unfamiliarity -- are simply not as easy for most programmers to work with. Couple this with the fact that most OOP systems are based on extensions to procedural languages, and it becomes pragmatically difficult to separate the two paradigms. (As a side note: That's one of the things I like about F#; as a multi-paradigm language, it helps conceptually separate the various aspects of OOP, imperative programming, functional programming, while making all of them available.)
I would say object-oriented and procedural are orthogonal concepts. Many popular object-oriented systems are extensions of procedural languages, but not all. For example, Dylan reads like a blend of functional and object-oriented programming.
This is just a 'convention' thing. When people say 'procedural', it is implied that it isn't OO, and vice-versa.
OOP does not loose procedural label. Procedural programming is imperative programming. OOP extends procedural programming. C++ and Objective C are OO extensions of C. Functional programming usually is declarative - opposite of imperative.
From Wiki (well explained):
The focus of procedural programming is
to break down a programming task into
a collection of variables, data
structures, and subroutines, whereas
in object-oriented programming it is
to break down a programming task into
objects with each "object"
encapsulating its own data and methods
(subroutines). The most important
distinction is whereas procedural
programming uses procedures to operate
on data structures, object-oriented
programming bundles the two together
so an "object" operates on its "own"
data structure.
More can be found here.
The Wikipedia article at http://en.wikipedia.org/wiki/Procedural_programming provides a decent explanation of the differences between object-oriented programming and procedural programming, but in short, object-oriented programming is about the exchange of messages between collaborating objects rather than stringing procedures together to operate upon loose data structures.
Internally, objects do resemble little procedural programs, but their data isn't publically exposed and operated upon by other objects. The "Tell, Don't Ask principle" is an object-oriented design principle that perscribes this interaction between objects. The study of this principle may help to shed further light on the nature and intent of object-oriented design over procedural design.
It never loses procedural label. Its a mis-conception. OOP is much more than encapsulation and objects. Click here for more info.
I think one of the distinctions is that virtual properties and methods are used much more heavily in object-oriented languages than are function pointers in languages like C. In C, if I say foo(x), it's pretty clear that I'm doing one of two things, and the declaration of foo(x) will tell me which one. I'm either calling a function named foo(), or I'm calling a function pointed to by a function pointer named foo(). In an object oriented language, when I write foo(x), that may get implicitly mapped to invoke code which didn't even exist when my module was compiled.
Depends on your definition of 'oriented'.
If 51% of the code is O-O, does it qualify?
OOP is not just encapsulation.
Polymorphism is one of its most powerful feature.
The only one I know of is called "e" which is used for test bench design in hardware design and verification but I want something for general purpose programming.
Aspect oriented programming isn't so much a defining feature of a language, it's a paradigm that can be applied to many existing programming languages. You'd be hard-pressed to find a specific language that's aspect oriented in nature, though one could exist that makes adding cross-cutting concerns easy out of the box. Starting with Wikipedia's entry on Aspect-oriented programming should point you to several implementations specifically for C++.
Although there's a few limitations - C# can be used for AOP.
You might want to look at c-sharpcorner and developerfusion.
Probably Aspect C++ (not that I ever tried it)
If you know e, then try VCS, which supports aspect-oriented extensions to SystemVerilog.
:-)