Re: "ocaml_beginners":: ocamllex/ocamlyacc, types and real world languages
- Il Wednesday 15 January 2003 21:27, oliver@...-berlin.de ha scritto:
> Hi,Let's stay cool... and step back a little. I know a very sound way of
> On Mon, Jan 13, 2003 at 12:16:12PM +0100, Stalkern 2 wrote:
> > Il Monday 13 January 2003 11:26, oliver@...-berlin.de ha scritto:
> > > But when I add string-type in the parser.mly and the lexer.mll
> > > I got problems.
> > This likely occurs because you have not modified the yacc rules
> > consequently.
> > The types are defined in the type part of the yacc file.
> > They are used in the lex file for casting the recognized tokens to a
> > consistent token type:
> > (stream-of-chars)->LEXER->(tokens-with-their-types)
> OK, the confusing thing is, that the lexer (written in lexer.mll)
> only gives back the values in appropriate types, but the declaration
> of the types is done in the parser-definition (parser.mly).
> And additionally, if I have a "main: (...);" with
> a complex type definition, I have to check the
> type again in the calc.ml file.
> It's good to have some hints of you all from the mailinglist,
> but to be honest, I'm nevertheless confused.
correcting myself :-)
It's based upon tracking my moves stepwise, starting from the very beginning.
It's my best recipe, so I'd try to suggest it to you.
You wanted to learn ocamllex and ocamlyacc for some reason.
1) What was that reason? If this reason goes beyond parsing one-line strings,
see the previous posting by Daniel de Rauglaudre, called "Re:
"ocaml_beginners":: How to get my brain to understand CamlP4", sent on Tue,
10 Dec 2002 19:06:51 +0100.
2) Apart from a reason moving you, you may have a purpose in front of you.
What is your purpose at present?
3) You've been studying the example on the tutorial. Does it work? Can you
4) Ocamlyacc is definitely not as clever as us. It's great at finding out
when you didn't close a bracket, as well as at distinguishing Hocus and
Pocus; but it can have problems in distinguishing Turin and Turing . To have
it recognize either an int or a float, you would safely tell to it that a
float is an int... followed by a dot and maybe an int. You'd general safely
tell it that saying that the expression that you're looking for is an int
followed by maybeTheRestOfTheStory. Later on, you have to tell to it that
maybeTheRestOfTheStory can either be a dot, or a dot followed by an int, or
something void. In short, did you remember that ocamlyacc is short-sighted?
5) Ocamlyacc becomes simpler and simpler when you understand its next move.
Can you see how would ocamlyacc parse its tokenized input? This is not so
difficult if you've already started to understand recursive functions. In
both cases, you can be in different places, yet in similar positions.
6) Types are defined in the .mly file, then used for tokens recognized in the
.mll file, then they get into the grammar actions (still in the .mly file).
Grammar rules are generally embedded into each other (just like an algebric
expression can be made of several expressions, and the types must be
compatible when going up and down). Do you have any compile problem due to
breaches in your type set while passing in types entering , so all the type
system must work. Do you get any type error while using the result of a
grammar rule inside a parent grammar rule?
>In the "main" file you'll get the 100% Fruit of the Ocamlyacc :-)
> And I have asked google over and over again, but
> didn't find any good ressources.
> Looking into the OReilly-boook was nice, and I may
> use a lot of tokens and do every specific work with
> that token-definitions.
> But, what type should I use for the main? Well.....
The type of such juicy fruit is NOT the type of the Tokens, but the type of
the result of the action of the main grammar rule. I wish I had told you that
>Just write a funnel!
> > and then the tokens + their types are matched against the grammar in the
> > yacc file.
> > (tokens-with-their-types) -> GRAMMAR RULES -> (actions).
> > Moreover, as Rémi pointed out a long time ago, in grammar actions the
> > evaluation order of the argument of a function may not be specified, and
> > thus fool you.
> > "It's way better to specify explicitly the order of the evaluation by
> > let .. =
> > .. in let .. = .. in ..."
> Well, this only makes a problem, when the evaluation order
> is a problem. WhenI use
> do_something(); do_something_more(); do_anything_else()
> the value of the last term (do_anything-else() is given back
> as the value of the three-termed line.
let action1 = do_something()
let action2 = do_something_more()
let action3 = do_anything_else()
() (*if the final type is void*)
and you'll force ocaml to evaluate expressions and act in the 1-2-3 order.
>Do yourself a favour... :-)
> So this type is, what is counting, here.
> And if I do not start actions in the actions ;-)
> and only set mutable values of a record, then this
> approach should make sense?
> If so, I may do all these value-setting inside the
> parser.mly file and it's actions, and can ignore
> any return value to the main-program?
Use ocamllex and ocamlyacc in a functionalist way, then fight with the side
effects of imperative programming in the main file so to keep the hazardous
(imperative) area carefully bounded.
>No, don't trust that. The parser has some rules on its own, as for the order
> As far as the parsing order itself is determined by the
> parsed text, I think I may have no problems?
of actions in grammar rules.
>Well, C is not strictly and statically typed, but I was told that you can type
> So, I may not need complex types for the main
> rule of the parser (and give back int, because
> using unit-value does not look much like solid
> functional programming...).
> Am I right here, or do I overlook something?
> I have only done some lex/yacc stuff in C,
> but it's many years ago. And the nice (as well
> as the ugly) in C is, that it is not typed.
it out from scratch in half a minute (this would be for Doug Bagley's
language shootout...) :-)
Hope this helps