Re: bracket/list processing

[Hans Aberg]

At 16:45 +0300 2001/02/03, —៊Պ" ڍÀ¦× wrote:
>1) Every expression can be in brackets - for obvious Math reasons.
>
>But I can not get it working.
>
>2) I meet also the strings with lists like:
>
>    A = {x} but also :  A = {x,y} , A = {x,y,z} and so on
>
>3) The easiest Q - should I treat the "unary minus" exactly as standard
>manual (calc sample) tells?
>
>
>Every wise words or ideas are welcome. The real samples are even better :-)

My guess is that you will soon be on your own with your problem, unless you
find somebody working with exactly yours.

Have you checked with "William F. Hammond" <address@hidden>, who is
working on a math typesetting language? See
  http://math.albany.edu:8010/pers/hammond/glf/
  http://www.albany.edu/~hammond/gellmu/tarball.html.

When I try to fix a grammar, I look around in books, and grammars of
computer languages (such as C++) in order to get inputs.

When you translate the math natural language (i.e. used naturally in
everyday life by mathematicians), expect some of the same problem as when
dealing with a natural language such as English, even though not as severe.
It means that it will probably contain some context dependencies
(grammatical and/or semantic) that formally cannot be treated by Bison,
without either tweaking the grammar given to Bison or by requiring
additional markup in the math input.

In your case, I guess you want something like
  set:
      '{' variable '|' statement '}' { ... }
    | '{' element_list '}'           { ... }

  element_list:
                               { */ empty */ }
    | element_list ',' element { ... }

  element:
    ...
(Here you have a semantic dependency, as the `statement' must be an
expression in the named variable.)

However, if you later want to use the braces `{}' in some other context,
you may run into troubles.

Therefore you may have to introduce some syntactic elements that surely
that is a set in a context free manner.

You may also want to write your grammar as
  %token set_begin set_middle set_end
  %%
  set:
      set_begin variable set_middle statement set_end { ... }
    | set_begin element_list set_end                  { ... }
or what amounts the same as
  %token set_begin "{"
  %token set_middle "|"
  %token set_end "}"
  %%
  set:
      "{" variable "|" statement "}" { ... }
    | "{" element_list "}"           { ... }
because now "{", "|", and "}" are just substitute names for the tokens
set_begin set_middle set_end.

You then have made you grammar "extensible" in a primitive way, because
Bison only cares about getting the macro-numbers set_begin set_middle
set_end from yylex, and not what these represent in reality. So you could
let your favorite method to identify set tokens, and get around the problem
that the symbols '{' '|', and '}' in another context means something else.

  Hans Aberg