I am looking at this line of EBNF:
<zeg> = <zig>|<zag>[<zug><zug>]
Does [<zug><zug>] only become available when <zag> is used, or is it always available, even with <zig>?
The | would be the most-loosely bound thing. In other words:
<zeg> is equivalent to <zig> | (<zag>[<zug><zug>])
and NOT equivalent to (<zig> | <zag>)[<zug><zug>].
So your first interpretation.
Related
Consider the following grammar:
module Tst
lexical Id = [a-z][a-z0-9]* !>> [a-z0-9];
layout Layout = WhitespaceAndComment* !>> [\ \t\n\r];
lexical WhitespaceAndComment
= [\ \t\n\r]
| #category="Comment" ^ "*" ![\n]* $
;
start syntax TstStart = Id*;
then
start[TstStart] t = parse(#start[TstStart], "*bla\nABC");
gives an ambiguity, probably because the comment can be placed before or after the empty list of strings.
So, I have 2 questions:
How can I use diagnose() to get a diagnosis? I have tried diagnose(t) and diagnose(parse(#start[TstStart], "*bla\nABC")), without success.
What is the ambiguity and how can I resolve it?
Sorry, it has been a while ago. The comment definition contains a flaw, it has to be corrected as follows:
#category="Comment" ^ "*" ![\n]* $
This resolves the ambiguity, but I still would like to know how to use diagnosis().
The ambiguity is caused by ![*]* which can eat a \n or not, because the whitespace notion can also eat the \n or not.
The diagnose function is notoriously bad at spotting issues with whitespace. That can be improved.
The solution is to use ![*\n]* and end the comment line with "\n"
Another ambiguity will happen with actual * comments in the code, between String* and Id* the comments would go before or after the empty lists. To fix this: layout Layout = WhitespaceAndComment* !>> [\ \t\n\r] !>> [*]; adding the follow restriction with the [*] will help.
When I make the example slightly more complicated I get another ambiguity.
module Tst
lexical Id = [a-z][a-z0-9]* !>> [a-z0-9];
lexical String = "\"" ![\"]* "\"";
layout Layout = WhitespaceAndComment* !>> [\ \t\n\r];
lexical WhitespaceAndComment
= [\ \t\n\r]
| #category="Comment" ^ "*" ![\n]* $
;
start syntax TstStart = String* Id*;
Then "*bla\nABC" gives an ambiguity again. Probably because the comment can be placed before, within and after the empty list of strings. How to resolve it?
In OCaml when I do a pattern matching I can't do the following:
let rec example = function
| ... -> ...
| ... || ... -> ... (* here I get a syntax error because I use ||*)
Instead I need to do:
let rec example1 = function
|... -> ...
|... | ... -> ...
I know that || means or in OCaml, but why do we need to use only one 'pipe' : | to specify 'or' in pattern matching?
Why don't the usual || work?
|| doesn't really mean "or" generally, it means "boolean or", or rather it's the boolean or operator. Operators operate on values resulting from the evaluation of expressions, its operands. Operations and operands together also form expressions which can then be used as operands with other operators to form further expressions and so on.
Pattern matching on the other hand evaluate patterns, which are neither boolean or expressions. Although patterns do in a sense evaluate to true or false if applied to, or rather matched against, a value, they do not evaluate to anything on their own. They are in that sense more like operators than operands. Furthermore, the result of matching against a pattern is not just a boolean value, but also a set of bindings.
Using || instead of | with patterns would overload its meaning and serve more to confuse than to clarify I think.
I am working on doing some code cleanup and need to make sure that my gsub! only runs on a small section of code. The portion of the code I need to examine starts with {{Infobox television (\{\{[Ii]nfobox\s[Tt]elevision to be technical) and ends with the matching double brackets "}}".
An example of the gsub! that will be run is text.gsub!(/\|(\s*)channel\s*=\s*(.*)\n/, "|\\1network = \\2\n")
...
{{Infobox television
| show_name = 60 Minutos
| image =
| director =
| developer =
| channel = [[NBC]]
| presenter = [[Raúl Matas]] (1977–86)<br />[[Raquel Argandoña]] (1979–81)
| language = [[Spanish language|Spanish]]
| first_aired = {{Date|7 April 1975}}
| website = {{url|https://foo.bar.com}}
}}
...
Note:
Using sub instead of gsub is not an option due to the fact that multiple instances of the parameter needed to be substituted may exist.
I cannot just look for the first set of }} as there may be multiple sets as show in the example above.
You may use a regex with a bit of recursion:
/(?=\{\{[Ii]nfobox\s[Tt]elevision)(\{\{(?>[^{}]++|\g<1>)*}})/
Or, if there are single { or } inside, you will need to also match those with (?<!{){(?!{)|(?<!})}(?!}):
/(?=\{\{[Ii]nfobox\s[Tt]elevision)(\{\{(?>[^{}]++|(?<!{){(?!{)|(?<!})}(?!})|\g<1>)*}})/
See the Rubular demo
Details:
(?=\{\{[Ii]nfobox\s[Tt]elevision) - a positive lookahead making sure the current location is followed with {{Infobox television like string (with different casing)
(\{\{(?>[^{}]++|\g<1>)*}}) - Group 1 that matches the following:
\{\{ - a {{ substring
(?>[^{}]++|\g<1>)* - zero or more occurrences of:
[^{}]++ - 1 or more chars other than { and }
(?<!{){(?!{) - a { not enclosed with other {
(?<!})}(?!}) - a } not enclosed with other }
| - or
\g<1> - the whole Group 1 subpattern
}} - a }} substring
Can't give you a direct answer without spending a lot of time on it.
But it is noteable that the first bracket set is at the beginning of a line, as is the last one.
So you have
^{{(.*)^}}$/m
The m means multiline match. That will match everything between the braces - the () brackets mean that you can pull out what was matched inside the braces, for example:
string = <<_EOT
{{Infobox television
| show_name = 60 Minutos
| image =
| director =
| developer =
| channel = [[NBC]]
| presenter = [[Raúl Matas]] (1977–86)<br />[[Raquel Argandoña]] (1979–81)
| language = [[Spanish language|Spanish]]
| first_aired = {{Date|7 April 1975}}
| website = {{url|https://foo.bar.com}}
}}
_EOT
matcher = string.match(^{{(.*)^}}$/m)
matcher[0] will give you the whole expression
matcher[1] will give you what was matched inside the () brackets
The danger with this is that it will do "greedy" matching and match the largest piece of text it can, so you will have to turn this off. Without more info on what you're trying to do I can't help any more.
NB - to match () brackets you have to escape them. See https://ruby-doc.org/core-2.1.1/Regexp.html for more info.
I want to check if a non letter/number or \W is at the beginning or the end of a variable, just a true or false. The usual code that I would use would be:
str.match( /^\W) || str.match( /\W$/ )
Of course, one could accomplish that using mutltiple ways, such as:
[ /^\W/, /\W$/ ].index{ | regy | str.match( regy ) }
however, I would like to know if there is a way to this in one regular expression. I.e.
str.match( regy ) # the single regexp handles the or part on it's own.
Thanks
Yes. Use the | in regex:
/^\W|\W$/
apiary shows me how to add descriptions to the parameter. However, what I need is having descriptions on the value.
For example /users{?skills}. I have my own skill codes for this parameter
'1' means can speak English
'2' means can swim
'3' means can drive
Adding them after the parameter description is way to do it. What if I have tones of skill codes? And the formatting of this approach is ugly. How can i achieve it?
There is currently no way to achieve it by using standard instruments of API Blueprint.
Neither
+ Values
+ `A - means something`
+ `B`
+ `C`
or
+ Values
+ `A` means something
+ `B`
+ `C`
will work correctly. I filed a feature request under API Blueprint's repository. If you want to be part of the design process and help us to get the best solution to your problem, you can track it and comment under it.
Appearance
I understand that rendering of this feature isn't very nice in standard docs.
However, in "beta new docs", it looks much better. Try it out - in settings, turn on following switch:
Then the rendering should look like this (two states):
Using tables
When in troubles with API Blueprint, you can always use plain old Markdown in endpoint's description to supplement or substitute what's missing. E.g. you can freely use tables as an addition or replacement to the Values section:
# My API
## Sample [/endpoint{?id}]
Description.
| Value | Meaning |
| ------------ |:----------------:|
| A | Alaska |
| B | Bali |
| C | Czech Republic |
+ Parameters
+ id (string)
Description...
| Value | Meaning |
| ------------ |:----------------:|
| A | Alaska |
| B | Bali |
| C | Czech Republic |
Description...
+ Values
+ `A`
+ `B`
+ `C`
Rendering of tables in old and new docs: