Re: [Caml-list] what do I need to know to understand camlp4
bluestorm
> simple camlp4 extensions?
For an accessible introduction to modern (>= 3.10) Camlp4, you may be
interested in Jake Donham's blog post series "Reading Camlp4" :
http://ambassadortothecomputers.blogspot.com/search/label/camlp4
You will also find valuable (though incomplete) information on the
camlp4 wiki : http://brion.inria.fr/gallium/index.php/Camlp4
The older version of camlp4 (< 3.10, now called camlp5) also provides
a documentation
http://caml.inria.fr/pub/docs/tutorial-camlp4/index.html , and you can
also use to Martin Jambon's tutorial
http://martin.jambon.free.fr/extend-ocaml-syntax.html (for the older
camlp4).
_______________________________________________
Caml-list mailing list. Subscription management:
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
Archives: http://caml.inria.fr
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs
Jake Donham
> For an accessible introduction to modern (>= 3.10) Camlp4, you may be
> interested in Jake Donham's blog post series "Reading Camlp4" :
> http://ambassadortothecomputers.blogspot.com/search/label/camlp4
You can also see the articles in sequence at
http://ambassadortothecomputers.blogspot.com/p/reading-camlp4.html
which I recommend since later articles depend on earlier material.
Jake
Michael Ekstrand
> Could someone give any idea how I can begin to understand how to write
> simple camlp4 extensions?
Shameless self-plug, but I wrote a blog post this summer about my
experience figuring out how to do it. I provide a walk-through and
explanation of a minimal syntax extension which adds lazy list pattern
matching support based on Batteries. The URL:
http://www.elehack.net/michael/blog/2010/06/ocaml-syntax-extension
I do assume a basic knowledge of parsing context-free grammars, but a
generic tutorial on parsing with a tool such as Yacc can fill in that
gap. The Wikipedia article[1] may also be helpful.
Once you've lept the hurdle of figuring out what pieces you need to
write and build a syntax extension, the remaining tricky part is to
figure out what pieces of the grammar you need to extend to accomplish
your objective. For that, I consult the definition of the OCaml parser
in Camlp4OCamlParser.ml in the OCaml source tree.
- Michael
1. http://en.wikipedia.org/wiki/Context-free_grammar
--
Web/blog: http://elehack.net/michael
Jabber/Google Talk: this e-mail address
Twitter: http://twitter.com/elehack
mouse, n: a device for pointing at the xterm in which you want to type
ben kuin
ben kuin
conclusion that for understanding and using camlp4 the notion of
quotations and antiquotations is fundamental. My absolute lack of
knowledge in this area might be a reason why I can't figure out how
camlp4 works.
Jake Donham
> thanks Jake, after browsing through those articles I came to the
> conclusion that for understanding and using camlp4 the notion of
> quotations and antiquotations is fundamental. My absolute lack of
> knowledge in this area might be a reason why I can't figure out how
> camlp4 works.
Unfortunately quotations are a rather leaky abstraction. You need to
understand what is happening at the AST level to do anything
complicated, and to understand what's wrong when you get an error.
Anything you can do with quotations you can of course do directly with
the AST, since quotations are just syntactic sugar for the AST. But to
make the code readable quotations are essential.
Yoann Padioleau
On Sep 23, 2010, at 11:49 AM, ben kuin wrote:
> thanks Jake, after browsing through those articles I came to the
> conclusion that for understanding and using camlp4 the notion of
> quotations and antiquotations is fundamental. My absolute lack of
> knowledge in this area might be a reason why I can't figure out how
> camlp4 works.
Do you know how macros work in other languages ?
You could have a look at Lisp macros which are simpler than OCaml macros:
http://cl-cookbook.sourceforge.net/macros.html
Understanding lisp macros could be a good step towards understanding ocaml macros.
ben kuin
I'm not actually new to OCaml, but although I've read every notable
book about OCaml and a lot of good code of other OCaml programs, OCaml
is still very foreign and counter-intuitive too me.
I know what you're might thinking now: why the hell does he still bother?
The 'problem' is that every time I read something in Python or worse
in Java/C++ I instantly miss the lightweight types/pattern matching
facility the ability to easily pass functions around. Then I read
functional Ruby or Scala code, and I begin to hate fp because in these
context it only makes the code harder to read.
So why does the whole world tries to hammer some functional features
into his imperative language? Why not maximize the imperative features
of a functional language? I know only one big project where the
explicitely use an imperative style in ocaml? But this code looks
(syntax wise) still too much functional for my taste.
> with its syntax (somewhat quirky[1], I admit).
For me it's worse, the syntax doesn't look quirky, but rather random
too me. It's not like cpp where the syntax is utterly pragmatic,
without any aesthetic claim. In OCaml it feels like someone
deliberately neglected the syntax.
> [1] Compared to other programming languages. I know the syntax is > the way it is for precise reasons (currying, closer to mathematical
> notation, ...).
Would you mind to list a few mathematical subjects that help me to
understand OCamls syntax?
thanks a lot
ben
Elias Gabriel Amaral da Silva
>> [1] Compared to other programming languages. I know the syntax is > the way it is for precise reasons (currying, closer to mathematical
>> notation, ...).
> Would you mind to list a few mathematical subjects that help me to
> understand OCamls syntax?
I suppose one is lambda calculus. Function application is
left-associative in ML. That is, if $ is an operator such as a $ b
means "a applied to b", then it is more natural to interpret a $ b $ c
as (a $ b) $ c[1]. The apply "operator" is simply not written in
OCaml, so we write just a b c, and it means (a b) c.
This is due to the fact that a N parameter function is just a
single-parameter function that return a new "curried" function that
gets N-1 parameters - just like lambda calculus. So one could write
let f = a b in f c to make this explicit as well. (This gets a bit
more complicated with optional parameters)
In fact, you want some mathematical background on functional
programming aesthetics (and whatnot),
http://en.wikipedia.org/wiki/Lambda_calculus may be a good
introduction.
[1] Pervasives should define it. In fact, even though ** is
right-associative, it looks like any user-defined operator is
left-associative by default. So it works like Haskell:
# let ($) a b = a b;;
val ( $ ) : ('a -> 'b) -> 'a -> 'b = <fun>
# fun x y z -> x $ y $ z;;
- : ('a -> 'b -> 'c) -> 'a -> 'b -> 'c = <fun>
# let q = fun x y z -> x $ y $ z;;
val q : ('a -> 'b -> 'c) -> 'a -> 'b -> 'c = <fun>
# let q' = fun x y z -> (x $ y) $ z;;
val q' : ('a -> 'b -> 'c) -> 'a -> 'b -> 'c = <fun>
# let q'' = fun x y z -> x $ (y $ z);;
val q'' : ('a -> 'b) -> ('c -> 'a) -> 'c -> 'b = <fun>
# let q''' = fun x y z -> x $ y z;;
val q''' : ('a -> 'b) -> ('c -> 'a) -> 'c -> 'b = <fun>
--
Elias Gabriel Amaral da Silva <tolki...@gmail.com>
David House
<tolki...@gmail.com> wrote:
> [1] Pervasives should define it. In fact, even though ** is
> right-associative, it looks like any user-defined operator is
> left-associative by default. So it works like Haskell:
>
> # let ($) a b = a b;;
> val ( $ ) : ('a -> 'b) -> 'a -> 'b = <fun>
> # fun x y z -> x $ y $ z;;
> - : ('a -> 'b -> 'c) -> 'a -> 'b -> 'c = <fun>
> # let q = fun x y z -> x $ y $ z;;
> val q : ('a -> 'b -> 'c) -> 'a -> 'b -> 'c = <fun>
> # let q' = fun x y z -> (x $ y) $ z;;
> val q' : ('a -> 'b -> 'c) -> 'a -> 'b -> 'c = <fun>
> # let q'' = fun x y z -> x $ (y $ z);;
> val q'' : ('a -> 'b) -> ('c -> 'a) -> 'c -> 'b = <fun>
> # let q''' = fun x y z -> x $ y z;;
> val q''' : ('a -> 'b) -> ('c -> 'a) -> 'c -> 'b = <fun>
Incidentally, ($) in Haskell is right-associative; however the
consensus in the Haskell community (in my experience) is that this is
a mistake. If it were left-associative, you would lose the ability to
say f $ g $ x, but this can be written f . g $ x anyway (dot is
function composition (a -> b) -> (b -> c) -> a -> c, and does
right-associate), but many things would require fewer parentheses,
e.g. f (g x) (h y) can be written f $ g x $ h y.
In fact, the strict function application operator ($!) *is* left-associative.
See http://hackage.haskell.org/trac/haskell-prime/wiki/ChangeDollarAssociativity
for more information.
Also, you say "Pervasives should define it" -- the important thing
about dollar in Haskell is that it has very low precedence, hence its
ability to save parentheses. I didn't think OCaml allowed us to
specify the operator precedence of the infix operators we define.
David MENTRE
2010/9/23 ben kuin <ben...@gmail.com>:
> So why does the whole world tries to hammer some functional features
> into his imperative language? Why not maximize the imperative features
> of a functional language?
Because some algorithms or way to solve problems (think pattern
matching) are inherently better expressed using a functional approach
than an imperative one, and vice versa for others.
> For me it's worse, the syntax doesn't look quirky, but rather random
> too me. It's not like cpp where the syntax is utterly pragmatic,
> without any aesthetic claim. In OCaml it feels like someone
> deliberately neglected the syntax.
I would say: go beyond syntax ben! :-) This is not very important.
What is important are the concepts behind the syntax and the way to
use them to improve your programs (like phantom types to add static
checks without any runtime penalty to give just one example).
For me, OCaml is probably one of the best language if you need to
maintain a bug free program over a long period: type inference and
efficient garbage collector to program efficiently and safely at the
same time, compilation to native code to have good to very good
performance, a very active community and a lot of libraries, etc. I
don't like OCaml's syntax, but this is the way it is. :-)
And if you don't like it, just use another language that better fits
your feeling. But for me you'll make a mistake if you not try to grasp
the OCaml Way of Doing Things(tm). ;-)
Sincerely yours,
david
Elias Gabriel Amaral da Silva
> Incidentally, ($) in Haskell is right-associative; however the
> consensus in the Haskell community (in my experience) is that this is
> a mistake. If it were left-associative, you would lose the ability to
> say f $ g $ x, but this can be written f . g $ x anyway (dot is
> function composition (a -> b) -> (b -> c) -> a -> c, and does
> right-associate), but many things would require fewer parentheses,
> e.g. f (g x) (h y) can be written f $ g x $ h y.
>
> In fact, the strict function application operator ($!) *is* left-associative.
>
> See http://hackage.haskell.org/trac/haskell-prime/wiki/ChangeDollarAssociativity
> for more information.
Oops. Still learning the basics of Haskell. Interesting, thanks :)
> Also, you say "Pervasives should define it" -- the important thing
> about dollar in Haskell is that it has very low precedence, hence its
> ability to save parentheses. I didn't think OCaml allowed us to
> specify the operator precedence of the infix operators we define.
Yes, the observation was made after seeing that $ would have lower
precedence than function application itself, but this does not say
anything about precedence in relation to other operators..
--
Elias Gabriel Amaral da Silva <tolki...@gmail.com>
_______________________________________________