hpi-swa / ohm-s Goto Github PK

In order to support Pretty Printers, the CST should allow access to whitespace. The whitespace does not have to be explicitly materialized in the CST but could also be re-constructed after the fact.

Here are two suggestions:

• CST nodes support the method skippedSpaces that returns the spaces skipped before the node was applied. There are two options how the spaces could be returned:
  • The spaces are returned as a simple string
  • The spaces are returned as a spaces node
• CST nodes support the method childrenIncludingSpaces that returns a collection of all parsed nodes including the space nodes in between

Any thoughts from your side @Paula-Kli?

• Check whether there are duplicate parameter names
• Cache newly created body in application

I was using the following rules in Ohm-S:

Text {
  TextRule
    = text

  textCharacter
      = "\\\""
      | "\\\\"
      | ~"\\" ~"\"" any

  text
    = "\"" textCharacter+ "\""
}

When trying to match the input Hello World starting from text everything works as expected and the string is correctly matched. When starting from TextRule, however, the expression can not be matched.

I tried the very same setup in Ohm/JS, which was able to match with either rule as the starting rule.

Lexification currently seems to not be supported. Trying to create a grammar using this operator fails, throwing an OhmMatchFailure.

The following rule yields nodes with only four children if the optional part does not match. It yields nodes with five children if it matches. We should check with Ohm/JS if this is intended or accidential behavior.

Pragma =
'<' identifier (':' Literal)? '>'

ohmjs/ohm#38 (comment)

Inline rule names do not match with the message that is sent to semantic actions. It is therefore possible to do the following:

SomeGrammar {
  RuleOne
    = "hello"
  Rule
    = "hello" "world" -- one
}

At the moment inline rule names' underscore is removed and the subsequent character capitalized when searching for methods in semantic actions. Both rules would therefore try to lookup the method RuleOne. Due to differing arities, only one of the rules can be acted upon.

This duplication of rules is not detected, since the inline rule name conforms to the Ohm/JS implementation (Rule_one) and is only later converted.

I stumbled upon this using the interactive ohm editor and confirmed it by setting up ohm/JS locally.

Error: Line 207, col 7:
  206 |     | stringLiteral
> 207 |     | ByteArrayLiteral
              ^~~~~~~~~~~~~~~~
  208 |     | symbolInArrayLiteral
Cannot apply syntactic rule ByteArrayLiteral from here (inside a lexical context)

After converting ByteArrayLiteral and LiteralArrayLiteralInLiteralArray to lexical rules, it does get accepted. I'm not sure, however, if that has an impact on the grammar's correctness.

Tests throughout all Ohm-S packages are consistently placed inside the message category testing instead of the conventional tests.

I have the following set of rules:

integerConstant
	= decimalConstant
	| octalConstant

decimalConstant
	= nonzeroDigit digit*

octalConstant
	= "0" octalDigit*

octalDigit
	= "0".."7"

nonzeroDigit
	= "1".."9"

In a test case (subclass of OhmSyntaxTestCase) I want to make sure an integerConstant rule is parsed as the correct subrule as follows:

testGrammarParsesIntegerConstants

	startRule := #integerConstant.
	self shouldParse: '042' to: #(integerConstant (octalConstant '042'))

While this test passes as expected, I also noticed that it actually passes no matter what rule name I specify in the structure I supposedly assert against:

testGrammarParsesIntegerConstants

	startRule := #integerConstant.
	self shouldParse: '042' to: #(integerConstant (thisCanBeWhatever '042'))

It looks like the rule names are not compared on leaf levels:

Is this correct behavior? And if so, what would be the expected way to write this kind of test?

Matching something like self new test; test it is matched as OperandCascade with self as operand and new test and test as MessageChains. I was wondering whether that should be an UnaryCascade.

In case it shouldn't. What is an UnaryCascade and what a BinaryCascade? I can't find an example that is matched as one of those.

Zum einen beschwert sich die aktuelle Ohm-JS Version über folgende Regel

in der Smalltalk-Grammatik:
BlockLiteral = "[" BlockArguments? ExecutableCode? "]"
mit der Nachricht:
"Nullable expression ExecutableCode is not allowed inside '?' (possible
infinite loop)"

Da ExecutableCode (via MoreExecutableCode und Statements) schon leer
sein kann, habe ich das ? entfernt und es funktioniert.
Nun weiß ich nicht, ob die Smalltalk-Implementierung mit ExecutableCode?
klar kommen würde.

In Ohm v15.3.0 a new operator was added:
ohmjs/ohm@b519a05
https://github.com/harc/ohm/blob/master/doc/syntax-reference.md#defining-extending-and-overriding-rules

The super-splice operator (...) can be used to append and/or prepend cases to the supergrammar rule body. E.g., if the supergrammar defines comment = multiLineComment, then comment := ... | singleLineComment is equivalent to comment := multiLineComment | singleLineComment.

i.e. no matchContents:startingFrom: etc.

Connected to #3

In the latest commit from 07.07.2020 binary cascades are again matched as operand cascades.

We tried matching 1 + 2 negated; negated which was in the commit from 06.07.2020 matched as binaryCascade and in the commit from 07.07.2020 it is matched as operandCascade from OhmExplicitSendsSmalltalk.

Which is somewhat wrong, as there was no further matched child.

https://github.com/harc/ohm/blob/master/doc/syntax-reference.md mentions:

Special characters (", , and ') can be escaped with a backslash -- e.g., """ will match a literal quote character in the input stream. Other valid escape sequences include: \b (backspace), \f (form feed), \n (line feed), \r (carriage return), and \t (tab), as well as \x followed by 2 hex digits and \u followed by 4 hex digits, for matching characters by code point.

Almost all of a rule body is copied during #replaceParametersWithArguments:

On a fresh subclass of OhmGrammarSmalltalkProxy, when writing the class-side serializedGrammar method, the error Error: ByteString called #basicNew: with invalid argument -1 is thrown once the text editor contains the following:

serializedGrammar
^ '

The error is caused because the following code always assumes the opening single quote to be closed in the end:

The cst resulting from parsing aabbbcbcd with the following grammar is ambiguous:

ManyTestGrammar { StartRule = "a"+ ("b"+ "c")+ "d"+ }

We can not determine the matching intervals of "b"+ anymore.

When you compute the value for a _terminal node with memoization, the result is a text instead of a string.
Is this intended behavior?
You can see it in this screenshot:

The memoization is called in the OhmSynthesizedAttribute >> value:

The Method FindFirst:startingAt: is not in the package. It is easy to implement it yourself in your local image but at first is missing.

Also your CI fails due to that ;)

currently the Smalltalk grammar will parse a variable name which starts with a special literal name, such as false, as a unary send without a space

They should be negative but are 0 to: 0 and size to: size

You can see it when using OhmSmalltalk>>number

The Expression 3-6 is evaluated to normalFloatingPointLiteral_exponent. It seems to be an issue of the grammar of the binaryMessageSelectorChar.

It would make the stiling with OmegaPrint correct in the case of using '-' as BinaryMessage. Here you can see a picture of how it is formatted right now.
Thank you.

https://github.com/harc/ohm/blob/master/src/built-in-rules.ohm