Printer prints too much brackets
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)
-
-
- edited description
-
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.
-
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
-
- changed title to Printer prints too much brackets
-
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
-
Dus in dit voorbeeld is het de
-(f)
die moeilijk doet?
-
exact
-
Dus: er mogen geen haakjes rond prefix functietermen en atomen.
Lijkt dat een goede algemene regel?
-
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)
-
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.
- Log in to comment
https://bitbucket.org/krr/idp/commits/18465ce5848aef9b77279a2aa94b9ebdd0897088#comment-1421802