Printer prints too much brackets

Issue #852 new
Pieter Van Hertum created an issue

Dit parst niet:

vocabulary V {
  type X isa int
  type XX isa int
  p
    c : XX
    f : X
}

theory T : V {
  (f  >  5).
(c  =  sum{ : p : -(f) }).
(c  =  -6).
}

structure S : V {
  X = { 1..10 }
  XX = { -100..100 }
  p = false
}

Comments (11)

  1. Ingmar Dasseville

    problem, zonder arbitraire lookahead, kan bison onmogelijk weten of (P(x)) een predicaat of een functie is, tot nu toe kon je dit alleen schrijven voor predicaten, en niet voor functies.

    Functies toevoegen, vereist een major refactoring van de parser, zodat functies en predicaten langs dezelfde regels kunnen werken.

  2. Bart Bogaerts

    Hmm... Wat is het probleem juist? @ingdas En: als het niet gefixt wordt, welke haakjes zijn dan precies verboden?

    @pietervh de verboden haakjes zouden niet geprint mogen worden

  3. Ingmar Dasseville

    haakjes rond dingen waarvan, als je ze in isolatie leest, niet kunt weten of het een term of een predicaat is:

    (f(x) + f(y)) = allowed, want de + toont aan dat het een term is (f(x)) = niet allowed, want f kan een predicaat of een term zijn

  4. Bart Bogaerts

    Dus: er mogen geen haakjes rond prefix functietermen en atomen.

    Lijkt dat een goede algemene regel?

  5. Bart Bogaerts

    De "prefix" is belangrijk: dat is volgens mij het enige geval waarin het probleem kan optreden (ik kijk naar @ingdas voor bevestiging).

    Bovendien: in het geval van prefix kan er geen ambiguiteit optreden door haakjes weg te laten (wat bij infix wel kan)

  6. Ingmar Dasseville

    Het is zelfs nog preciezer dan dat, +(a,b) is er ook geen probleem, want de parser weet dat + verbonden is aan termen, maar bij alle andere prefix-functies, is het inderdaad het probleem.

    Ik denk dat in de huidige versie er technisch gezien wel haakjes mogen rond atomen, maar dat is niet consistent met de termen, en een consistente richtlijn lijkt mij aangewezen.

  7. Log in to comment