Christopher League pushed to branch report/els-2017 at Stefan / Typer
Commits: ce345fff by Christopher League at 2017-02-06T21:28:26-05:00 Rephrase conclusion paragraph, other minor stuff
- Fix overfull hbox due to Barendregt - De-gender Nemerle - Plurality agreement on "extension node" - Second sentence of conclusion was kind of a run-on, and had awkward "Lisp macros's" -- I think this improves.
Thx for the ack. This paper really helped me understand better what you're trying to do. I'll try to help more substantially with future work!
- - - - -
1 changed file:
- paper.tex
Changes:
===================================== paper.tex ===================================== --- a/paper.tex +++ b/paper.tex @@ -224,7 +224,7 @@ mixfix elements. The parser is still very primitive, since it uses an operator precedence grammar~\cite{Floyd63}, but is already powerful enough to handle a syntax that should feel familiar to ML and Haskell users.
-Typer's core language is based on a Pure Type System~\cite{Barendregt91b}, +Typer's core language is based on a Pure Type System \cite{Barendregt91b}, so as to use a single syntactic category for types and expressions. More specifically, its core language is similar to that of proof assistants such as Coq~\cite{Coq00} and can also be used to write logical propositions @@ -1078,7 +1078,7 @@ somewhat similar to Lisp's S-expressions. %% tokens to an AST before sending it to the macro and avoids the %% programmer the struggle of parsing the input by hand.
-Another part of Nemerle macros similar to Typer's macro system is his +Another part of Nemerle macros similar to Typer's macro system is its program analysis capabilities. Nermerle macros have access to the compiler API and can ask the compiler to elaborate one of its arguments for example to find its type (if known to the compiler). %% This functionality is similar @@ -1103,7 +1103,7 @@ Recent versions of OCaml (after version 4.01.0) also come with \emph{extension points}, which work like macros, by mapping OCaml AST to OCaml AST. The grammar now accepts annotations to the source file and a special construct, extension nodes, for syntax extension. When the -compiler encounters an annotated branch in the AST or an extension nodes in +compiler encounters an annotated branch in the AST or an extension node in an expression it calls the macro associated with the annotation. Of course, as in the case of Template Haskell, this means that uses of those extensions have to use a special syntax and hence feel like second-class features. @@ -1134,12 +1134,13 @@ domain specific language tailored for this task. \section{Conclusion and future work} \label{sec:conclusion}
-We have presented the syntactic structure of the programming language Typer. -This shows how to extend Lisp's S-expressions with an infix syntax without -losing Lisp macros's power and flexibility, by using an operator precedence -grammar, which is a sweet spot that is flexible enough to provide a familiar -infix syntax, yet restricted enough that S-expressions can still be parsed -without needing to know anything about macros. +We have presented the syntactic structure of the programming language +Typer. It demonstrates how to extend Lisp's S-expressions with an +infix syntax without losing the power and flexibility of Lisp macros. +To do so, we use an operator precedence grammar, a sweet spot that is +flexible enough to provide a familiar infix syntax, yet restricted +enough that S-expressions can still be parsed without needing to know +anything about macros.
Typer's implementation is available online from \url{http://gitlab.com/monnier/typer%7D. It is currently still
View it on GitLab: https://gitlab.com/monnier/typer/commit/ce345fff2678625896494dd4136538eeb915...
Afficher les réponses par date
Hi Chris,
- Fix overfull hbox due to Barendregt
Thanks. BTW, I notice that my PDF is *very* different (as in: the end of the intro sometimes is a bit before the end of the 1st page and sometimes a bit after) depending on which machine I run pdflatex. Part of the difference between the two machines is that one has Debian stable the other has Debian testing, but maybe the cause is elsewhere. It's the first time I see such large differences without an actual teX error along the way.
- De-gender Nemerle
Poor guy!
Thx for the ack. This paper really helped me understand better what you're trying to do.
Thanks, that was definitely the motivation, so I'm happy to see at least it works for some people,
Stefan
Stefan Monnier monnier@IRO.UMontreal.CA writes:
Thanks. BTW, I notice that my PDF is *very* different (as in: the end of the intro sometimes is a bit before the end of the 1st page and sometimes a bit after) depending on which machine I run pdflatex. Part of the difference between the two machines is that one has Debian stable the other has Debian testing, but maybe the cause is elsewhere. It's the first time I see such large differences without an actual teX error along the way.
That's alarming. It would be surprising if TeX itself produced different output, but with so many packages on top of other packages, a different version of the TeX-live tree could probably do it, I guess.
I've been playing with NixOS lately -- as in, wasting enough time on it that I made it my primary laptop and email server distro -- so I'm interested in the idea of *reproducible builds*. Nix seems to go pretty far toward supporting the idea, but it does so by relying on a half-gigabyte repository of "nix pkgs", which itself doesn't even contain much upstream source, so in turn it relies on collections of repositories that have differing standards for releasing and archiving.
All upstream sources are checksummed, but even so... that means you can definitely *detect* when you don't have the exact same build, I'm not sure how far it goes to ensuring you always will be able to *reproduce* some historical build. But anyway...
CL