On Sat, 2009-10-10 at 20:12 +0200, Ben Franksen wrote:
Since 'some' is defined recursively, this creates an infinite production for
numbers that you can neither print nor otherwise analyse in finite time.
Yes, sorry, I should have been more careful there. One has to be careful
to handle EDSLs
On Sun, 2009-10-11 at 21:54 +0200, Ben Franksen wrote:
Ben Franksen wrote:
Next thing I'll try is to transform such a grammar into an actual
parser...
Which I also managed to get working. However, this exposed yet another
problem I am not sure how to solve.
Another option is to not use a
On Tue, 2009-10-13 at 13:28 +0100, Nils Anders Danielsson wrote:
On 2009-10-07 17:29, Robert Atkey wrote:
A deep embedding of a parsing DSL (really a context-sensitive grammar
DSL) would look something like the following. I think I saw something
like this in the Agda2 code somewhere, but I
On Mon, 2009-10-12 at 15:49 +0200, Sjoerd Visscher wrote:
Hi Bob,
I tried to understand this by applying what you said here to your deep
embedding of a parsing DSL. But I can't figure out how to do that.
What things become the type class T?
Here's the API version of the grammar DSL:
On Fri, 2009-10-09 at 18:06 +0100, Philippa Cowderoy wrote:
This leads us to the bikeshed topic: what's the concrete syntax?
I implemented a simple Camlp4 syntax extension for Ocaml to do this. I
chose the syntax:
applicatively
let x = foo
let y = bar
in pure stuff
I quite like
On Wed, 2009-10-07 at 11:32 -0400, Joe Fredette wrote:
So, if I understand this:
Parsec is a DSL, I'm going to venture it's a Deep embedding -- I
don't understand the internals, but if I were to build something like
Parsec, I would probably build up a Parser datastructure and then
What is a DSL?
How about this as a formal-ish definition, for at least a pretty big
class of DSLs:
A DSL is an algebraic theory in the sense of universal algebra. I.e. it
is an API of a specific form, which consists of:
a) a collection of abstract types, the carriers. Need not all be of
On Mon, 2009-10-05 at 19:22 -0400, David Menendez wrote:
The two obvious options are
call-by-name and call-by-value.
I wonder how easily one can provide both, like in Algol.
Fairly easy, you can either do a language that has an explicit monad (a
bit like Haskell with only the IO monad), or
On Mon, 2009-10-05 at 22:06 -0400, Chung-chieh Shan wrote:
Robert Atkey bob.at...@ed.ac.uk wrote in article
1254778973.3675.42.ca...@bismuth in gmane.comp.lang.haskell.cafe:
To implement the translation of embedded language types to Haskell types
in Haskell we use type families
On Mon, 2009-10-05 at 22:42 +0100, Robert Atkey wrote:
There is a difference in the syntax between CBN and CBV that is not
always obvious from the usual paper presentations. There is a split
between pieces of syntax that are values and those that are
computations. Values do not have side
Hi Günther,
The underlying problem with the implementation of 'lam' is that
you have to pick an evaluation order for the side effects you want in
the semantics of your embedded language. The two obvious options are
call-by-name and call-by-value.
The tricky point is that the types of the
11 matches
Mail list logo
