So, when U build i.e. Python interpreter, U would (automatically, by provided tool) make a new python.js file (from provided grammar and some sugar besides), include it in html and off U go, modifying html DOM from python.
Theoretically, another markup language could be constructed that would replace HTML, if U want that.
CALL FOR PARTICIPATION
SIGPLAN Programming Languages Mentoring Workshop, San Diego, USA
Tuesday January 21, 2014
Co-located with POPL 2014
PLMW web page: http://plmw2014.inria.fr/
After the resounding success of the first two Programming Languages
The purpose of this mentoring workshop is to encourage graduate
We especially encourage women and underrepresented minority students
This workshop is part of the activities surrounding POPL, the Symposium
A number of sponsors have generously donated scholarship funds for
Students attending this year will get one year free student membership
The workshop registration is open to all. Students with alternative
APPLICATION for PLMW scholarship:
The scholarship application can be accessed from the workshop web site
Dear LtU community,
Currently I'm working on combinator of incremental recursive descent parsers based on PEG grammars. And I would like to share my approach with you.
By the term "incremental" here I mean that the resulting parser is able to continue parsing process from any point of source code. i.e. parsers that are usually used in code editors and IDEs for live coding.
Briefly the problem is that performance of ordinary parsers is O(n) in best case, where n is the size of the source code. And we want to optimise the parser to work in O(m) approximately, where m is the size of incoming changes in the code.
Primitive solution for this problem would be memoization of AST. And binding each cached node to appropriate rule. Then running the parser again to reconstruct AST branch that covers changed part of the code.
However this approach has two disadvantages:
1) It is hard to determine which of the parental AST branch better fits to cover all the implications of changes in source code. Of course we can try each parental branch one by one from the deepest descendants up to root. But each parse try may cost additional computation efforts.
2) Another controversial problem is how to choose which nodes to memoise in order to get better performance and to save memory. Caching all nodes is overmuch.
My solution is to cache only the nodes that strongly cover invariant syntax fragments. "Invariant" means that regardless fragment's internal content it will always be parsed by the same parsing rule. And the internal content don't have any affects to the code outside it.
The example of such fragments could be parenthesis in C-like languages. More specific example is a code between function's arguments. No matter what this fragment consists of, it can always be parsed by a function's argument parsing rule only.
Fortunately selection process of such fragments between simple tokens can be performed by State Machine before the Syntax parse stage. And therefore could be easily put on incremental basis as well.
I have implemented the parser combinator in Scala language, and published it on GitHub. Also there is a blog post with some additional details. Here I also want to mention that library supports error recovery mechanism, and provides API to parse precedence operator expressions with Pratt algorithm.
I will be glad to hear any feedback from you on this approach.
Also I would like to know was this approach applied before in other products? Or at least described theoretically in papers? If so I would like to refer to them in my work. Or maybe it is quite unique? Should I try to publish more formal article then?
Thanks in advance.
With XQuery 3.0 support of first class functions and a whole host of other fp goodness
be interested in comment here if 3.0 is missing anything.
Having a small fp language work on declarative markup (as well as json, text, etc) is a powerful idiom.
I am sure I am demonstrating ignorance, but I am not aware of a similar(dynamic, typed) programming language that embodies fp principles so concisely.
Mathematical foundations of Computer Science (CS) require great power as well as extreme rigor because of the requirement that computer systems be able to carry out all reasoning including reasoning about their own reasoning processes. The mathematical foundations of CS have important economic and security consequences.
Following a suggestion of [Scott 1967], mathematical foundations for Computer Science (CS) should be built on *both* types *and* sets:
A natural way to proceed is to construct sets from characteristic functions by composing function spaces on ℕ (as axiomatised by Dedekind/Peano). Proceeding in this way, every set has finite rank. (The foundations of CS don’t seem to need the higher cardinals.
Computer Science needs strong foundations that go far beyond the capabilities of first-order logic. For example, that a computer server provides service(i.e. ∃[i∈ℕ]→ ResponseBefore[i]) in the Actor Model) cannot be proved in a first-order theory.
For further discussion, see “What is Computation? Actor Model versus Turing’s Model”.
Let Peano be the Peano/Dedekind theory of the natural numbers with the following strong induction axiom:
Of course, there are inferentially undecidable propositions Ψ such that
The exact nature of the inferentially undecidable propositions of Peano is currently a matter of great controversy. See “Mathematics Self Proves its own Consistency”.
On Wolfram's blog. What is it? Will it be as revolutionary as claimed or will this just be another new kind of science? Reading the blog, it looks like they are banking on (a) a very rich library and (b) a cloud-based but built-in knowledge base akin to what you might get with F# type providers.
A few months ago I wrote an article on CodeProject detailing my plans for my parser generator and the abstraction it will build upon, something called Loyc trees and LES, hoping to get feedback on my ideas.
I didn't get a single comment, though. I think now that I was just talking to the wrong crowd, and that perhaps the LTU will have richer things to say. Basically LES is an interchange format for syntax trees ("XML for code", I like to say, but since the syntax is concise and intuitive-ish, it's more like "YAML for code"), and Loyc is a project for converting code between programming languages and making source code easier to process by mere mortals. (Plus, I'm developing a programming language called Enhanced C# and would welcome advice about making a hygienic macro system.)
So, I hope you guys will find my idea interesting and offer your feedback. The most up-to-date summary of my ideas are on the Loyc wiki:
And if anybody's interested in a parser generator for C#, LLLPG is getting close to finished now.
I’m working on a statically typed language and finding it slow going. In the history of dynamically vs. statically typed languages, it seems there is a trend: dynamic languages are implemented in a weekend, and refined iteratively for 10–20 years thereafter—static languages are defined and implemented over the course of 10–20 years, after which they’re basically complete.
The disparity is astonishing! Why do expressive static languages seem so much more difficult to implement? I contend that the field of type theory is not mature enough to answer the questions that dynamically typed languages ask.
Is this possible? Have static typing, meaning all types are defined at compile time, and at the same time have direct read/write access to the abstract syntax tree of the program?
Maybe this is possible if type definitions are not part of the AST.
Maybe I am missing or confusing sth. here...
Let me ask a more practical question: How would ANSI C, as an example, would have to be extended in order to provide direct read and write access to the abstract syntax tree at runtime while not loosing its compile-time type-checking feature.
edit: I like to clarify that what I mean by "AST" is not nessessarily a datastructure representing the entire program's contents but can also be seen as a typed representation of the program's entities: e.g. the language exposes the functions etc. as editable values. So the question is: If the program entities (is there a better word?) may be manipulated at runtime, is it still possible to type-check the program at compile-time? Or what restrictions must be applied to the access in order to not loose the compile-time-check-ability.
Active forum topics
New forum topics