Which of the model transformation languages are ocl-based?
Is Epsilon Transformation Language (ETL) ocl-based?
Most transformation languages like ATL, QVT and ETL are OCL-based, specially when it comes to define the pattern-matching part of the transformation
QVT is strongly OCL-based; the OMG specification specifies that all three QVT languages extend OCL. Similarly Acceleo follows the MOFM2T specification which extends OCL.
ATL is strongly influenced by OCL, but takes a few liberties through lack of support for shorthands, type inference and indeed strong typing.
EOL and so ETL is influenced by OCL. EOL makes some deliberate deviations such as eliminating the power/confusion of "."/"->".
Xtend/Xbase and OCL share the same functional programming influences and so some aspects of Xtend can seem familiar to OCL users.
Related
I don't know a lot about declarative languages. I'm looking for simple and minimalistic language to describe objects, their attributes and a way that they react when any environment event occurs.
I would like to use, process and write this code from c++.
It would be useful for 2d rogue-like or strategy games, any simulations etc.
Does exist anything like that or similar?
I would like to try to write this on my own, but I don't want to reinvent the wheel :)
I am pretty sure there are no Declarative Languages that do what you are looking for. Declarative Languages are highly tailored to their problem domain. When you say you want a language that describes "a way that [objects] react when any environment event occurs" makes me think that a Declarative Language is not what you're looking for since that implies side effects.
If you are looking for Embeddable Languages then Lua and Python are both proven. The Warcraft 3 engine used a Lua derivative for its scripting which is very similar to what you are describing, and Python is widely used for embedding in general.
If you are looking for a standard minimalistic data format, JSON is pretty much the way to go, and lord knows there are standard parsers out there.
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
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.
For example pattern matching is a programming language feature that can be added to the clojure language through macros: http://www.brool.com/index.php/pattern-matching-in-clojure
What other language features can be added to the language?
Off the top of my hat I have two examples, but I'm sure there are more.
Contracts programming: https://github.com/fogus/trammel
Declarative logic: https://github.com/jduey/mini-kanren
I think its a stupid question to ask what can be added, what you should ask is what you cant add. Macros allow you to hook into the compiler that mean you can do almost anything.
At the moment you cant add your own syntax to the language. Clojure does not have a user extenseble reader, this means you don't have any reader-macros (http://dorophone.blogspot.com/2008/03/common-lisp-reader-macros-simple.html). This is not because of a technical problem but more a decition by Rich Hickey (the Clojure creator).
What you can not do is implement features that need virtual maschine support like add tail call semantics or goto.
If you want to see some stuff that has been done: Are there any Clojure DSLs?
Note that this list is not 100% up to date.
Edit:
Since you seem you took pattern matching as an example (it is a really good example for the power of macros) you should really look at the match library. Its probebly the best fastest pattern matching library in Clojure. http://vimeo.com/27860102
You can effectively add any language features you like.
This follows from the ability of macros to construct arbitrary code at compile time: as long as you can figure out what code you need to generate in order to implement your language features, it can be achieved with macros.
Some examples I've seen:
Query languages (Korma)
Logic programming (core.logic)
Image synthesis DSL (clisk)
Infix notation for arithmetic
Algebraic manipulation
Declarative definition of realtime data flows (Storm, Aleph)
Music programming (Overtone, Music As Data)
There are a few caveats:
If the feature isn't supported directly by the JVM (e.g. tail call optimisation in the mutually recursive case) then you'll have to emulate it. Not a big deal, but may have some performance impact.
If the feature requires a syntax not supported by the Clojure reader, you'll need to provide your own reader (since Clojure lacks an extensible reader at present). As a result, it's much easier if you stick to Clojure syntax/forms.
If you do anything too unusual / unidiomatic, it probably won't get picked up by others. There is a lot of value in sticking to standard Clojure conventions.
Beware of using macros where they are not needed. Often, just using normal functions (perhaps higher order functions) is sufficient to implement many new language features. The general rule is: "don't use macros unless you absolutely need to".
Several questions about functional programming languages have got me thinking about whether XSLT is a functional programming language. If not, what features are missing? Has XSLT 2.0 shortened or closed the gap?
XSLT is declarative as opposed to stateful.
Although XSLT is based on functional programming ideas, it is not a full functional programming language, it lacks the ability to treat functions as a first class data type. It has elements like lazy evaluation to reduce unneeded evaluation and also the absence of explicit loops.
Like a functional language though, I would think that it can be nicely parallelized with automatic safe multi threading across several processors.
From Wikipedia on XSLT:
As a language, XSLT is influenced by
functional languages, and by
text-based pattern matching languages
like SNOBOL and awk. Its most direct
predecessor was DSSSL, a language that
performed the same function for SGML
that XSLT performs for XML. XSLT can
also be considered as a template
processor.
Here is a great site on using XSLT as a functional language with the help of FXSL. FXSL is a library that implements support for higher-order functions.
Because of FXSL I don't think that XSLT has a need to be fully functional itself. Perhaps FXSL will be included as a W3C standard in the future, but I have no evidence of this.
I am sure you guys have found this link by now :-) http://fxsl.sourceforge.net/articles/FuncProg/Functional%20Programming.html .
Well functions in XSLT are first class-citizens with some work arounds after all :-)
That is sort of how it feels when I am programming it.
XSLT is entirely based on defining functions and applying them to selected events that come down the input stream.
XSLT lets you set a variable. Functional programming does not allow functions to have side effects - and that is a biggie.
Still, writing in XSLT, one has the same "feel as working in an FP fashion. You are working with input - you are not changing it - to create output.
This is a very, very different programming model from that used when working with the DOM API. DOM does not separate input and output at all. You are handed a data structure - and you mangle it how you see fit - without hesitation, restriction, or remorse.
Suffice it to say if you like FP and the principles behind it, you will probably feel comfortable working in it. Just like experience with event driven programming - and XML itself - will make you comfortable with it as well.
If your only experience is with top-down, non event driven programs - then XSLT will be very unfamiliar, alien landscape indeed. At least at first. Growing a little experience and then coming back to XSLT when XPath expressions and event-handling are really comfortable to you will pay off handsomely.
For the most part, what makes XSLT not a 100% functional programming language is it's inability to treat functions as a first-class data type.
There may be some others -- but that's the obvious answer.
Good luck!
Saxon-SA has introduced some extension functions which make XSLT functional. You can use saxon:function() to create a function value (actually a {http://net.sf.saxon/java-type}net.sf.saxon.expr.UserFunctionCall value) which you then call with saxon:call().
Saxon-B has similar functionality with the pairing of saxon:expression() and saxon:eval(). The difference is that saxon:expression() takes any XPath expression, and saxon:eval() evaluates it, whereas saxon:function() takes the name of a function which saxon:call() calls.
That is not really an argument, since you can only declare variables, not change their values after declaration. In that sense it is declarative not imperative style, as stated in Mr Novatchev's article.
Functional programming languages like Scheme or Erlang enable you to declare variables as well, and in Haskell you can also do that:
-- function 'test' takes variable x and adds it on every element of list xs
test :: [Int] -> [Int]
test xs = map (+ x) xs
where x = 2