Loading ...
Sorry, an error occurred while loading the content.

Re: "ocaml_beginners"::[] ocamllex/ocamlyacc, types and real world languages

Expand Messages
  • Stalkern 2
    ... Let s stay cool... and step back a little. I know a very sound way of correcting myself :-) It s based upon tracking my moves stepwise, starting from the
    Message 1 of 9 , Jan 15, 2003
      Il Wednesday 15 January 2003 21:27, oliver@...-berlin.de ha scritto:
      > Hi,
      > 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.

      Let's stay cool... and step back a little. I know a very sound way of
      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
      compile it?
      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?
      7)... ...
      > 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.....

      In the "main" file you'll get the 100% Fruit of the Ocamlyacc :-)
      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
      before :-<

      > > 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.
      Just write a funnel!
      Try :
      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.

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

      Do yourself a favour... :-)
      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.

      > As far as the parsing order itself is determined by the
      > parsed text, I think I may have no problems?

      No, don't trust that. The parser has some rules on its own, as for the order
      of actions in grammar rules.

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

      Well, C is not strictly and statically typed, but I was told that you can type
      it out from scratch in half a minute (this would be for Doug Bagley's
      language shootout...) :-)

      Hope this helps
    Your message has been successfully submitted and would be delivered to recipients shortly.