27 views

Skip to first unread message

Sep 23, 2010, 11:26:12 AM9/23/10

to ben kuin, caml...@inria.fr

> Could someone give any idea how I can begin to understand how to write

> simple camlp4 extensions?

> 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

Sep 23, 2010, 12:24:24 PM9/23/10

to OCaml List

On Thu, Sep 23, 2010 at 8:25 AM, bluestorm <bluesto...@gmail.com> wrote:

> 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

> 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

Sep 23, 2010, 12:29:12 PM9/23/10

to caml...@inria.fr

On Thu, 2010-09-23 at 16:56 +0200, ben kuin wrote:

> Could someone give any idea how I can begin to understand how to write

> simple camlp4 extensions?

> 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

Sep 23, 2010, 2:43:20 PM9/23/10

to Michael Ekstrand, caml...@inria.fr

thanks a lot for this information and the links, this is very helpful

Sep 23, 2010, 2:50:00 PM9/23/10

to Jake Donham, caml...@inria.fr

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.

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.

Sep 23, 2010, 2:54:34 PM9/23/10

to ben kuin, caml...@inria.fr

On Thu, Sep 23, 2010 at 11:49 AM, ben kuin <ben...@gmail.com> 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.

> 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.

Sep 23, 2010, 3:07:22 PM9/23/10

to ben kuin, caml...@inria.fr

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.

Sep 23, 2010, 3:50:40 PM9/23/10

to David MENTRE, caml...@inria.fr

> If you are new to OCaml,

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'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

Sep 23, 2010, 8:15:07 PM9/23/10

to ben kuin, caml...@inria.fr

2010/9/23 ben kuin <ben...@gmail.com>:

>> [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>

Sep 24, 2010, 3:35:55 AM9/24/10

to Elias Gabriel Amaral da Silva, caml...@inria.fr

On 24 September 2010 01:15, Elias Gabriel Amaral da Silva

<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>

<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.

Sep 24, 2010, 3:48:47 AM9/24/10

to ben kuin, caml...@inria.fr

Hello,

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

Sep 27, 2010, 7:43:34 AM9/27/10

to David House, caml...@inria.fr

2010/9/24 David House <dmh...@gmail.com>:

> 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>

_______________________________________________

Reply all

Reply to author

Forward

0 new messages

Search

Clear search

Close search

Google apps

Main menu