How is ML (and its variants e.g. SML) a metalanguage. What is the object language that ML describes? Is it just because functions are considered values, therefore code is treated in the same way as data?
It actually comes from its original use case.
ML was designed as a language to write theorem provers. In this case, ML is the programming language that you use to describe the theory. It's the language above the theory: the meta-language. Or, as Milner would put it in the original paper:
We also discuss extending these results to richer languages; a type-checking algorithm based on W is in fact already implemented and working,
for the metalanguage ML in the Edinburgh LCF system.
The name stuck, so now it's called like this, even though it doesn't describe an object language in the general sense.
ML originally was the meta language for the LCF theorem prover developed by Milner in the 70s. You could use it define and perform proofs in this system, e.g., by writing proof tactics in ML. See also the Wikipedia article
Related
There are programming languages and theorem prover based on higher order logic (HOL). Examples include Twelf, lambda prolog, Isabelle. For example Twelf is is both a programming language and a theorem prover, while Isabelle is mainly a theorem prover, but for Isabelle code extraction is available.
I am looking for a HOL programming language based on haskell. The reason is that I like, for instance, lambda prolog very much, but it is not meant as a practical programming language. Lambda prolog lacks a standard library and interfacing with external libraries doesn't seem trivial. The problem is if you need some functionality, like writing a parser for a text file, you can't interface, say, with the many available existing libraries for haskell, and further, there is no standard library so you start from scratch.
Today I came across the Caledon programming language that was implemented as a master thesis, it seems. From the github page:
Caledon is a dependently typed, polymorphic, higher order logic
programming language.
This is interesting, since it is written in haskell so it should be easy to extend and interface with existing haskell libraries. But it seems that the project is in a bit early stage, I am not sure if input-output (IO) is implemented. Since I learned only today about Caledon, I think I might have missed some further projects. (BTW, I am not interested in standard logic programming languages like prolog).
Are there programming languages based on higher order logic besides Caledon that are implemented in haskell?
(I am asking for "implemented in haskell", as it is rather easy to connect programming languages that can be extracted to or are implemented in haskell. For example the Agda programming language can compile to haskell code and haskell libraries can be used conveniently and is extremly easy to use haskell libraries if you know how. Many other programming languages (e.g., ATS) I belive only provide the smallest common denominator which is a C based foreign function interface (FFI). In my eyes it is quite cumbersome to connect two higher programming languages via their respective C-based FFI interface. Thus the seemly abitrary part that "it should be implemented in haskell". Further, as a side note some users have downvoted in the past for my description of Agda as a programming language, but of course this is not true, i.e., consider Curry-Howard )
"Haskabelle is a converter from Haskell source files to Isabelle/HOL theories implemented in Haskell itself."
Haskabelle
Strange Statement: Haskell' is a higher order logic programming language based on Haskell. Type inference in Haskell with multiparameter type classes, type families, undecidable inference and whatnot actually forms a higher order logic programming language. This probably doesn't help you very much because:
The spec is literally constantly changing (I've had a few packages loose compatibility as they were based on hacks that got "fixed")
The type system itself doesn't have IO (yet?)
It can't really call other Haskell libraries from type inference
Its not very fast.
The logic programming semantics aren't exactly clear or stable.
It doesn't permit you to unify with lambdas or other type classes, although it does permit unification with functions.
Sadly, I know of extraordinarily few full HOL languages let alone ones implemented in Haskell - it turns out higher order unification is a huge pain to implement.
short answer: i don't know. long answer: you have small chances you will find purely academic language with thousands of libraries and tools for it. if you for some reason need that specific language for some specific problem then use it ONLY for that problem. not for parsing files, calculating taxes or launching rockets. create library and link it with other programs. or even better: create a microservice or connect the programs in other way (e.g. standard input/output) that doesn't require much effort. always use best tool for the job
I've just started learning J, which is very interesting, but I was wondering what kind of language it is exactly, in relation to common paradigms and classifications. For example, you could say that F# is a strongly typed, mainly functional (it supports OO and procedural programming, but it's considered to be "functional") language which belongs to the ML family. For J, however, I couldn't find much on how to classify it "conventionally", or find anything on Stackoverflow confirming that it's a functional programming language. Wikipedia says that it "is a very terse array programming language", "supports function-level programming", and "is not a Von Neumann programming language", none of which are more helpful.
I have a couple of questions:
What main paradigm (procedural, OO, functional, logical) do J/K/APL fall under? If their paradigm is only "array programming", what paradigm does that fall under or is most similar to?
What well-known programming languages are J/K/APL most similar to? For example, I'd guess that they're like Lisp, since they operate on arrays (lists) and have minimal, no comma syntax.
I'm just trying to categorize these languages in my head according to what I already know. Thank you.
J is related to the kind of functional programming (sometimes known as function-level programming, as opposed to value-level) advocated by John Backus, who is probably better known as the inventor of Fortran but spent the latter part of his career trying to move programming away from the style used by Fortran.
In his Turing Award Lecture entitled "Can Programming be Liberated from the von Neumann Style?" Backus presented an overview of his ideas, which he experimented with in his FP and FL languages. Those were inspired largely by Ken Iverson's APL, and Iverson in turn borrowed from Backus' languages when he developed J.
The key idea behind these, which was expanded and developed as a paradigm as the language family grew, was the formation of an algebra of programming. Using these algebraic tools, a programmer could derive or calculate a correct program to solve a problem by combining standard higher-order functions according to well-known mathematical rules. From the abstract of the lecture above:
Associated with the functional style of programming is an algebra of
programs whose variables range over programs and whose operations are
combining forms. This algebra can be used to transform programs and to
solve equations whose "unknowns" are programs in much the same way one
transforms equations in high school algebra. These transformations are
given by algebraic laws and are carried out in the same language in
which programs are written. Combining forms are chosen not only for
their programming power but also for the power of their associated
algebraic laws. General theorems of the algebra give the detailed
behavior and termination conditions for large classes of programs.
Although there doesn't seem to be a lot of recent research that uses the notation of this family of languages, the key ideas have seen somewhat recent development in other functional languages. Richard Bird and Lambert Meertens worked on a related formalism for algebraic manipulation and derivation of programs and the data they operate on; this is known as the Bird-Meertens Formalism or, informally, Squiggol.
Bird and Philip Wadler later wrote a text, "Introduction to Functional Programming", which introduced students to the more well-known "value-level" functional programming based on the lambda calculus. It originally used the Miranda programming language, a forerunner to Haskell, but in its 2nd edition was translated to use Haskell. I mention this because Erik Meijer, Maarten Fokkinga, and Ross Paterson used the example functions in the text as the motivating examples in their well-known paper "Functional Programming with Bananas, Lenses, Envelopes, and Barbed Wire", where they extend the Bird-Meertens Formalism, give it a basis in Category Theory, and show how the solution to each of the examples can be calculated based on the laws of the formalism and the recursion schemes captured by its higher-order functions.
These ideas took root in Haskell, and there you can find a style of programming known as "point-free" that bears a strong resemblance to FP programming. It eschews named variables and creates a new function purely by composition of other functions. Most of the language is not optimized for this use, so many functions are awkward to create in point-free style using only the standard libraries, but alternate libraries that provide more Squiggol-style combinator functions are available.
The algebraic style of constructing programs, thanks to its mathematical nature, is amenable to high-level analysis and transformation by sophisticated compilers. This has led to developments in "Fusion" or "Deforestation" optimizations in functional language compilers that allow algorithms expressed in this style to be reduced to highly efficient machine code loops without all the garbage data and redundant loops that a more naive translation would require. Earlier this year, a framework for generalized stream fusion was presented that showed very practical results from this style of programming.
Hopefully this background gives you a better idea of what the Wikipedia article was talking about and how the underlying paradigm works.
While other tags could also apply (as with other languages), J is certainly a functional language. It has most major attributes attributed to functional languages, such as functions being 'first class citizens,' currying, higher order functions, etc. Furthermore, if it means anything to you, I have read articles where the language creators themselves described the language as 'functional.'
You could also say that it is an array programming language, as all functions operate on arrays vs. single elements.
I think the short answer you are looking for is that J is a functional array programming language. You could also throw other descriptors out there, such as non-statically typed, etc.
As to your numbered questions:
Functional and array programming.
As far as array programming goes, they are not similar to any other well-known language; rather they are in their own category of 'array programming languages.' As far as functional aspects go, they'd be in the functional category.
It'a a well-known fact that UML does not Turing complete (in contrast to usual programming languages). But it seems to me UML is even more flexible than traditional languages. I can't imagine a problem you can describe by means of such language as C++ (f.e) but at the same time can't describe by means of UML. Quite the contrary it's much more easier for me to fancy a construction existing in UML but unreliazable in C++ (Java, Delphi, VB and so on...)
Could you help me to understand this moment? I really can't catch it.
I´d say that UML IS a turing complete language since the addition of the Action Semantics package (this happened in UML 1.5 version).
Now UML includes an imperative action language (not to be confused with OCL) that allows a precise definition of the behaviour of class methods. This imperative action language includes the typical set of assignments, if conditions, iterators,... you´d expect from any programming language.
This action language is one of the popular components of Executable UML approaches but it´s now part of the UML standard itself
Interesting question. A couple of points come to mind, although there's probably a whole more to it. Apologies it's quite long.
What can you describe with e.g. C++ that you can't describe with UML?
First, you have to define what you mean by "UML". Generally, people tend to mean the 'core' elements - those on Class Diagrams, State Diagrams, Activity Diagrams etc. - plus OCL (the constraint language).
Given those elements you can't specify imperative algorithms. Specifically, anything that requires assignment. You can however get very close: the steps and decision logic can be expressed using e.g. Activity Diagrams, and the function of each step defined as pre- and post-conditions in OCL. However, you never quite get to fully specifying the behaviour. Take an example of an atomic step whose purpose is to increment the value of an integer. The input is an integer - say X. The output is described by the post-condition X == X#pre+1. However, there's nothing in UML to actually implement the step.
Now it's entirely conceivable to extend usage of UML to address above. The UML Action Semantics were developed precisely to enable specification of actions. Doing so makes the language computationally complete. The problems are merely practical:
There's no universally agreed and adopted syntax for the semantics;
There are very few implementations
What can you describe with UML that can't be implemented in e.g. C++?
In essence nothing. However there are two practical limitations:
UML "specifications" are usually imprecise, ambiguous and/or incomplete. Activity Diagrams, for example, often leave paths dangling. Could it be represented directly in C++? Yes. Would it compile? No.
Some of the mappings for UML constructs to imperative, stack based languages are non-trivial. State Models are an example: while there are well-known patterns, the mapping is quite complex. This is especially true for hierarchical and/or concurrent behaviour. In an activity Diagram, it's easy to express that two activities happen in parallel and then synchronise before moving to the next step. That can of course be done in C++ but requires the use of e.g. threading libraries.
It can however be done. In fact, it's what the Executable UML tools do: Model Compilers take an executable UML model and translate it into 100% functioning imperative code.
hth.
As the name implies UML is a modelling language. It can sometimes be applied as a methodology for designing software.
Once upon a time they were dreaming up ways of automatic code generation, they were called CASE tools. They failed to get the code generators to work effectively, although they did remove a lot of boiler plate code from the language. This augmentation became the key to UML as it provided a way to augment the experience of designing and programming software.
I don't know if UML is "Turing Complete", I hope it is, wouldn't it be great to come up with solutions by describing the problem to the computer in pictorial format and letting the computer do all that hard nasty programming for you.
UML is the meta language to the doing in the code. It describes artefacts, how they relate/interact and what they do.
UML is being added to, new design artefacts are being added year by year, and if it is not already Turing Complete I don't see why it couldn't be.
However I think somewhere along the line I read something about languages being "Turing Equivalent" if they could both express and solve the same solution.
Since UML is the design language and code is the implementation language based on the UML design I would say that UML and code (c#, java, etc) are Turing Equivalent. If they are agreed to be Turing Equivalent then UML must be Turing Complete.
i have planned to develop a tool that converts a program written in a programming language (eg: Java) to a common markup language (eg: XML) and that markup code is converted to another language (eg: C#).
in simple words, it is a programming language converter that converts program written in one language to another language.
i think it is possible but i don know where to start. i wanna know the possibilities to do so and information about some existing system.
What you are trying to do is extremely hard, but if you want to know what you are up for I've listed the steps you need to follow below:
First the hard bit:
First you obtain or derive an operational semantics for your source and target languages.
Then you enhance the semantics to capture your source and target memory models.
Then you need to unify the two enhanced-semantics within a common operational model.
Then you need to define a mapping from your source languages onto the common operational model.
Then you need to define a mapping from your operational model to your target language
Step 4, as you pointed out in your question, is trivial.
Step 1 is difficult, as most languages do not have sufficiently formal semantics specified; but I recommend checking out http://lucacardelli.name/TheoryOfObjects.html as this is the best starting point for building a traditional OO semantics.
Step 2 is almost certainly impossible in general, but may be merely obscenely difficult if you are willing to sacrifice some efficiency.
Step 3 will depend on how clean the result of step 1 turned out, but is going to be anything from delicate and tricky to impossible.
Step 5 is not going to be trivial, it is effectively writing a compiler.
Ultimately, what you propose to do is impossible in general, due to the difficulties inherited in steps 1 and 2. However it should be difficult, but doable, if you are willing to: severely restrict the source language constructs supported; pretty much forget handling threads correctly; and pick two languages with sufficiently similar semantics (ie. Java and C# are ok, but C++ and anything-else is not).
It depends on what languages you want to support, but in general this is a huge & difficult task unless you plan to only support a very small subset of each language.
The real problem is that each programming languages has different features (with some areas that overlap and others that don't) and different ways of solving the same problems -- and it's pretty tricky to detect the problem the programmer is trying to solve and convert that to a new idiom. :) And think about the differences between GUIs created in different languages....
See http://xmlvm.org/ as an example (a project aimed at converting between source code of many different languages, with an XML middle-point) -- the site covers in some depth the challenges they are tackling and the compromises they take, and (if you still have any interest in this kind of project...) ask more specific followup questions.
Notice specifically what the output source code looks like -- it's not at all readable, maintainable, efficient, etc..
It is "technically easy" to produce XML for any single langauge: build a parser, construct and abstract syntax tree, and dump out that tree as XML. (I build tools that do this off-the-shelf for many languages). By technically easy, I mean that the community knows how to do this (see any compiler textbook, e.g., Aho&Ullman Dragon book). I do not mean this is a trivial exercise in terms of effort, because real languages are complicated and messy; there have been many attempts to build C++ parsers and few successes. (I have one of the successes, and it was expensive to get right).
What is really hard (and I don't try to do) is produce XML according to a single schema in which the language semantics are exposed. And without that, it will be essentially impossible to write a translator from a generic XML to an arbitrary target language. This is known as the UNCOL problem and people have been looking since 1958 for the answer. I note that the Wikipedia article seems to indicate the problem is solved, but you can't find many references to UNCOL in the literature since 1961.
The closest attempt I've seen to this is the OMG's "ASTM" model (http://www.omg.org/spec/ASTM/1.0/Beta1/); it exports XMI which is XML. But the ASTM model has lots of escapes built into it to allow langauges that it doesn't model perfectly (AFAIK, that means every language) to extend the XMI in arbitrary ways so that the language-specific information can be encoded. Consequently each language parser produces a custom version of the XMI, and thus each reader has to pretty much know about the extensions and full generality vanishes.
What would be a good choice of programming language in which to implement a decision tree? The results of the implementation will be for personal use only, so no need to consider ability to publish etc.
I have heard that Octave is a good option, can anyone explain why a matrix based language is recommended for implementing decision trees?
I have used Standard ML both to implement decision trees and to write a compiler from a domain-specific language into decision trees. I've also compiled similar decision trees into C code.
It really depends what you want to do with decision trees. If you are trying to do something sophisticated or you are trying to make the decision trees especially easy to read and write, I would suggest either creating a domain-specific language or embedding domain-specific operators into Haskell or Standard ML. If you just want to get going, you could start with ML (easier than Haskell for a beginner) and that preserves some options for later.
In general, ML and Haskell are both very good at representing and manipulating trees of all kinds.
I can't explain why someone would recommend a matrix-based language for decision trees.
I am pretty sure that the first decision tree was written in LISP.
Still many such algorithm is still written in LISP.
You can find many documentation if you decide to choose LISP.
Scheme is also a good language for that purpose and it is simpler/smaller than LISP.
Also the learning curve is fast in both languages.
IMHO