Is there a BNF type grammer description of the Purescript language?
It is hard to get a good handle on the language when the syntax is buried and scattered into various documentation of concepts and intent and so forth.
The closest thing to that would be the Parser.y file, in the purescript-cst sub-project.
Related
I need to do a presentation on a paper which at some point makes use of Isabelle/Isar and Isabelle/HOL.
I tried researching online about Isabelle/HOL and Isabelle/Isar to be able to eplain the relations in one or two slides.
Here are the relations as I currently understand them:
Isabelle - provides a generic infrastructure for deductive systems
Based on Standard ML programming language
provides an IDE which allows you to write theories which can be later be proved.
Isabelle/Pure - minimal version of higher-order logic according to this link:
Is it an actual language that can be inputted into isabelle IDE?
Or is it a technical specification?
Isabelle/HOL(Higher Order Logic):
Is it a library or a language?
How does it relate to Isabelle/Pure?
Is it procedural in nature?
Do tactics only exist in Isabelle/HOL?
Is it LCF - Logical Commutable Functions?
Isabelle/Isar:
Structured proof language based on Isabelle/Pure
Declarative
Is it an extension of Isabelle/HOL as stated at here?
Do locales only exist in Isabelle/Isar?
What does the Isabelle/IDE supports by default?
Just feels like I'm getting conflicting information from different sources and would like to sort this out.
Thanks in advance
Edit - Check out this highly related question and Manuel Eberls answer here: What are all the isabelle/slashes?
As this is an answer to a homework question and I myself only have limited understanding of all parts of the Isabelle project, this answer merely tries to point you in the right direction for at some parts of your question.
From the Isabelle/ISAR reference manual:
The Isabelle system essentially provides a generic infrastructure for building deductive systems (programmed in Standard ML), with a special focus on interactive theorem proving in higher-order logics.
It continues to also introduce ISAR:
In contrast Isar provides an interpreted language environment of its own,
which has been specifically tailored for the needs of theory and proof development.
[...]
The main concern of Isar is the design of a human-readable structured proof
language
Let's try to connect Pure to all of this by looking at publications from Makarius Wenzel regarding the topic:
Thus Isar proof texts may be understood as structured compositions of formal entities of the Pure framework, namely propositions, facts, and goals
In colloquial terms, Pure is the semantic foundation. Isar is a language that "follows" this semantic and provides syntax for it. Isabelle is just (one of the) platforms it all runs on.
Some of your confusions around the distinction between Pure and Isar seem to stem from the fact that the Isabelle Pure source code defines, or at least seems to define, both the semantics (Pure) and the syntax (Isar) in one go:
(* The Pure theory, with definitions of Isar commands and some lemmas. *)
In my humble opinion, this might be related to your understanding of syntax, semantics and "implementations" of the two. "Pure" outside of computers or paper is just semantics and thus, like math, just a thing in our brains. Give it syntax and you can put it to paper or type it into a machine. For the machine to be able to process your text (since this is ultimately what we after), it needs an implementation. Some framework telling it how to read the syntax and how to then process it. This framework is Isabelle. On top of Isabelle, there is Isabelle/Pure, which defines the semantics (the processing) and Isabelle/Isar, which defines syntax. For practical reasons, Isabelle's Pure implementation already provides the Isar syntax in one go.
From all of this, you might be able to figure HOL out yourself!
Some more references:
The Isabelle/Isar Implementation
Does anyone know where I can get the BNF or EBNF for the LOGO programming language?
A BNF grammar might not be too useful in certain circumstances...
Writing a LOGO that's accurately compatible with existing/historical implementation isn't an easy task (I worked on such a project). The problem is that the parser doesn't do the full job, and the evaluator (interpreter) has to work with partial data. Consider this example:
proc1 a b proc2 c
It could mean proc1(a, b, proc2(c)) or proc1(a, b, proc2(), c) according to the number of parameters for proc1 & proc2.
Furthermore the LOGO interpreters I know, for example Berkely LOGO, seem from a cursory glance not to write a traditional parser that additionally has access to each procedure and its arity; instead they run the procedures and the procedures 'eat up' the number of parameters that they need. This makes the parser a little naive and the main role is that of an interpreter, and thus parsing is kind of unusual.
There is no standard LOGO implementation.
Your best call is probably to look at the source of a popular implementation, such as UCBLogo
I seldom see static analyzer for functional programming languages, like Racket/Scheme, I even doubt that whether there are any. I would like to write a static analyzer for functional languages, say Scheme/Racket. How should I go about it?
Yes, there is some work on static analysis of dynamic languages like Scheme. For instance, see the work of Olin Shivers (http://www.ccs.neu.edu/home/shivers/citations.html) and Manuel Serrano (http://www-sop.inria.fr/members/Manuel.Serrano/index-1.html).
There's already, e.g., typed racket: http://docs.racket-lang.org/ts-guide/index.html
Since valid racket code is valid typed racket, you just have to change the language you're working in. Then, for libraries with typed versions, load those instead of the untyped versions, and certain type errors can get caught statically already. Further type annotations can be added to your own code to get guarantees of type correctness beyond that...
First read this paper by Shivers, explaining why there is no static control flow graph available in Scheme.
Might implemented k-CFA in Scheme. Matt Might's site and blog is a good starting point for exploring static analysis of higher-order languages.
I did some static analysis implementations for Scheme in Java as well:
k-CFA implementation
Interprocedural Dependence Analysis implementation based on a paper by Might and Prabhu
I am taking a course on abstract interpretation, but I haven't seen any examples of how the theory maps down to actual code.
I am looking for short code examples, where I preferably won't have to work with a whole compiler. The analysis doesn't have to be useful, I would just like to see an example where the analysis is derived and then implemented.
Does anyone know of any such examples, perhaps from a university course?
AI is based on a mathematic theory name Galois Connection. The theory is very simple:
Abstract the behaviour of the program.
Perform the analysis on the abstract level.
Galois connection: To relate the Actual and Abstract program.
This is the best tutorial I have seen so far about Abstract Interpretation:
There is this paper by Bertot
Structural abstract interpretation, A formal study using Coq
That gives a full implementation of an abstract interpreter for a simple toy language using the Coq Proof Assistant. I used this for a concrete reference, and found it useful, although a little hard going, which is to be expected given the subject matter. Coq is a great little piece of software.
I also came across in a Cousot paper:
A gentle introduction to formal verification of computer systems by abstract interpretation
rough details (but I am sure there will be useful citations for full details) of an implementation in Astrée, I am not familiar with Astrée, so didn't actually read that section, but I think it meets your criteria.
If you come across anymore, please let me know! Would especially like to see a prolog abstract interpreter.
Maybe this tool is also interesting for you:
Interproc Analyzer
It is an abstract analyzer for a very simple language, which however offers
interprocedural analyses. You can try out the analysis and get numerical invariants about the analyzed program. The source code is available (OCaml).
A really thorough and precise course, given by one of the "creators" of Abstract Interpretation, Patrick Cousot (already mentioned in one of the answers):
MIT course about Abstract Interpretation. The course also offers assignments, in OCaml.
There is MonoREIL, which comes with the recently open sourced tool BinNavi.
See here is a short intro.
Note that the context of the MonoREIL framework is not compilers but the analysis of binary code. Yet, it has been used for real world applications, see slide 34 ff of this introduction (which contains more formal background).
Suppose I want to implement an interpreter for a functional language. I would like to understand the issues involved in doing so and suitable literature that is available. This is a new language that is in early design stages, that is why the question is broad in scope.
For the purpose of this discussion we can assume that the purpose of the language is not important and that its functional features can be changed (even drastically) if it makes a significant difference in the ease of writing an interpreter.
The MIT website has an online copy of Structure and Interpretation of Computer Programs as well as videos of the MIT 6.001 lectures using Scheme, recorded at HP in 1986. These form a great introduction to language design.
I would highly recommend Structure and Interpretation of Computer Programs (SICP) as a starting point. This book will introduce the idea of what it means to write an interpreter (and a compiler), and is generally a must-read for anybody designing languages.
Implementing an interpreter for a functional language isn't likely to be too much different from implementing an interpreter for any other general purpose language. There's lexical analysis, parsing, AST construction, semantic analysis, plus execution (for a pure interpreter) or code generation and optimisation (for a compiler, even compiling to bytecode like Java/Perl/Python). SICP will introduce the difference between "applicative order" and "normal order" evaluation, which may be important for you in a pure functional context.
For just about any language interpreter or compiler, the main issues are the same, I think.
You need to decide certain basic characteristics of the language (semantics, not syntax), and the bulk of the design of the thing follows from that.
For example, does your language have
a type system? If so, what sorts of
types does it have? Is it going to be
statically typed, dynamically typed,
duck-typed?
What sort of expressions are you
planning to support? Do you need to
define an order of operations? Will
you even have operators?
What will you use as the run-time
representation of the program? Will
you convert the text to a byte-code
representation, or an AST, or a
tokenized form of the source text?
There are toolkits available to help take some of the tedium out of the actual parsing of text (ANTLR and Bison, to name two), but I don't know of anything that helps with the actual interpretation part of the task. I'm sure somebody will suggest something.
The main issue is having a semantics for the language you're implementing -- with that, the implementation becomes straightforward. Otherwise, this question is incredibly broad and hard to answer.
I'd recommend Essentials of Programming Languages as a good complement to SICP, particularly if you're interested in interpreters: Official EOPL site. You may want to check out the third edition-- the site hasn't been updated for it yet.
Edit: spam prevention is making me choose between links, so the official page is now unheated. It's easily Google-able, though.