I was wondering about notation in the documentation of PostgreSQL.
[ ], { }, [ ... ], [ , ... ], ( ) etc...
You can see these signs from SQL query example etc.
What do these signs mean?
[square brackets] indicate optional parameters. You can include any number of these, or none.
(parentheses) are simply part of the SQL code, and does not indicate any deeper meaning in the documentation.
{curly braces} and verical lines | indicate that there are a limited amount of options to choose, and you must choose one alternative or another.
[] - There are called "square brackets"
{} - These are called "curly brackets".
() - These are simply called "brackets".
I hope I answered your question?
[ is a square bracket, ( is a round bracket, { is a curly bracket .... so I believe
Use the word left or right in front of them. The ones above are left
Round bracket also known as parenthesis
Related
I want to add a comment like this
/**
* #param scrollFraction In range [0..1].
*/
But Dokka/Kdoc interprets stuff inside square brackets as a reference. This leads to badly rendered comments when you check the function's documentation in the IDE or generate the docs. How can I escape square brackets/other symbols in Dokka/Kdoc?
You should be able to do it using ` symbol, like this:
/**
* #param scrollFraction In range `[0..1]`.
*/
However, using ` symbol will show everything in between as a code block.
To just use square brackets without a reference inside, use HTML symbols, like [ and ] from the #yuvgin's answer.
You can use HTML escaping:
/**
* #param scrollFraction In range [0..1].
*/
should output in Dokka as range [0..1]., since [ escapes as [ and ] escapes as ].
Note this will not work inside a section of inline code (between grave accents - like this). For such cases use square brackets ([ and ]) normally, as was suggested in Demigod's answer.
I believe my syntax is correct on this one, but for some reason the Anura FFL parser is not recognizing the second identifier choice defined in my where clause. What am I missing?
def(class creature creature, class game_state game) ->commands [
if(creature.choices,
if(choice < size(player.deck), [
set(player.deck, player.deck[0:choice] + player.deck[choice+1:]),
game.crypt.spawn_cards(creature.summoner, [card]),
set(creature.effects_tracking['Buried Treasure'], card),
] where card=player.deck[choice]
) where player=game.players[creature.summoner],
choice=creature.choices[0]
),
]
It gives me this error:
formula.cpp:1067 ASSERTION FAILED: Unknown identifier 'choice' :
if(choice < size(player.deck), [
^-----^
Note: if I change it to where a=... where b=... instead of where a=... , b=... then it parses.
The comma is being interpreted as an argument separator for if() -- it's ambiguous and impossible for the parser to tell intent. You have to use parens to disambiguate it, though I just recommend using there where...where syntax, as it's much more reliable. Commas are just too open to problems like this so this syntax on where clauses is deprecated.
I was wondering if there is a way to also return the original value of an entity from Wit.Ai.
For instance, my entity "states" correctly maps the misspelled and lower case word massachusets to Massachusetts. But it does not return the original word. So, I cannot easily tag the incorrect word.
{
"msg_id": "a6ac0938-d92c-45f4-8c41-4ca990d83415",
"_text": "What is the temperature in massachusets?",
"entities": {
"states": [
{
"confidence": 0.7956227869227184,
"type": "value",
"value": "Massachusetts"
}
]
}
}
I really appreciate if you know how I can accomplish that with Wit.Ai.
Thanks
Keep the search strategy of "states" as free-text & Keywords. This way you can extract the original word in the message. Declaring it as keyword matches it with the close one and returns that keyword where as if it is a free-text it returns original word in the message.
You may have to train wit each time to do so, by highlighting "Massachusetts" as a resolved value. This will make wit understand that you do not agree with the autocorrection.
This isn't really a problem, but more of a curiosity of mine that I haven't been able to resolve by my own means. I surely won't be losing any sleep over it.
In VB.NET, the switch statement syntax is (as documented on MSDN here):
Select [ Case ] testexpression
[ Case expressionlist
[ statements ] ]
[ Case Else
[ elsestatements ] ]
End Select
Note that in the first line, Case is in square brackets, meaning that it is optional.
And indeed, the following example compiles and executes in the same way as if the Case keyword had been included, at least, in the rudimentary examples I've tried:
Select myIntVar
Case 0
Return "Nothing"
Case 1
Return "Just one"
Case Else
Return "Something else"
End Select
Therefore my question is as follows:
Aside from syntax, is there any difference between opening a switch statement with Select and Select Case?
I did a small experiment. I made up a small console application like so:
Module Module1
Sub Main()
Dim myStr As String = GetString(1)
End Sub
Private Function GetString(myIntVar) As String
Select myIntVar
Case 0
Return "Nothing"
Case 1
Return "Just one"
Case Else
Return "Something else"
End Select
End Function
End Module
The first run was as pictured above, and then I compiled it again inserting the Case keyword. I disassembled both created executables using ILDasm and pasted the IL of the GetString function into this online diff site: http://www.diffchecker.com/9ef7z423
Looks to me like Select Case and plain old Select are purely syntax differences (this is of course excluding the usage of Select in LINQ queries).
I would say there is no difference between the two forms. However, my only evidence is by way of an absence of drawing any distinction. Rather than looking at the Language Reference, the definitive place to look is in the Language Specification1.
In Version 11, under section 10.8.2, the Select Case statement is discussed, and the syntax shown is:
SelectStatement ::=
Select [ Case ] Expression StatementTerminator
[ CaseStatement+ ]
[ CaseElseStatement ]
End Select StatementTerminator
So, it's clear that this section does cover both forms. However, in the preceding 5 paragraphs (the entirety of the specification for Select Case Statements) no distinction is drawn between the two forms.
1The Reference tries to be descriptive, give examples, and uses (at times) looser language. The Specification should be followable to create a Visual Basic compiler. If something is missing from the former, then it may just be an omission. If something is missing from the latter, then it's not officially part of the language.
I think this comes from VB 6.0 where Select Case was mandatory - Select wasn't a statement on its own. This would mean that it's now just down to personal preference in VB.NET.
Edit: Strangely, if you do choose to omit it, Visual Studio will add it automatically.
Maybe it's just a difference in syntax, in terms of between languages, such as VB and C#
a switch statement requires the keyword break in order to break out of the loop.
Can't think of anything major, in terms of differences... sorry.
Is there a name for a syntax used for SQL?
E.g.) When you go to this page on BOL (SQL Books OnLine),
it shows the syntax of BEGIN DIALOG CONVERSION
BEGIN DIALOG [ CONVERSATION ] #dialog_handle
FROM SERVICE initiator_service_name
TO SERVICE 'target_service_name'
[ , { 'service_broker_guid' | 'CURRENT DATABASE' } ]
[ ON CONTRACT contract_name ]
[ WITH
[ { RELATED_CONVERSATION = related_conversation_handle
| RELATED_CONVERSATION_GROUP = related_conversation_group_id } ]
[ [ , ] LIFETIME = dialog_lifetime ]
[ [ , ] ENCRYPTION = { ON | OFF } ] ]
[ ; ]
What is the name/terminology of the syntax used above?
Transact-SQL Syntax Conventions (Transact-SQL) does not mention the name of their "Syntax Conventions".
I don't know whether this notation has a specific name, but it is not BNF - Backus-Naur Form, nor is it EBNF (extended BNF, aka ISO/IEC 14977:1996). It is loosely related, but only loosely related. In particular, BNF specifies that a non-terminal name is defined as some list of values. An example would be this CREATE TABLE statement from the SQL 2003 standard:
<table definition> ::=
CREATE [ <table scope> ] TABLE <table name> <table contents source>
[ ON COMMIT <table commit action> ROWS ]
The LHS ('<table definition>') is a non-terminal that can be referenced elsewhere. The '::=' operator is the 'is defined as' operator. The terms in angle brackets '<>' are more non-terminals (sometimes the same as the LHS, though not in this example), for which there is a definition somewhere else. The parts in square brackets '[ ... ]' are optional (may either be present - once - or may be omitted altogether). The SQL standard uses the notation:
<non-terminal> { [ , <non-terminal> ] }...
to indicate repetition.
The snippet in the question is not directly BNF because it does not use the 'LHS ::= RHS' notation; it effectively assumes the LHS does not need to be named. It also not clear from the notation (as shown - it may be clearer in the original document) whether things like 'CURRENT DATABASE' and 'target_server_name' are terminals or non-terminals (most likely, the current database is a terminal and target server name is not - but BNF would make that clear).
It's an informal, slightly abbreviated form of EBNF:
(http://en.wikipedia.org/wiki/Extended_Backus%E2%80%93Naur_Form)
used in Computer Language Documents at least since the late 60's.
I agree with Liao.
There is more to it. This is used not just for SQL syntax but to describe/define grammars of various artificial languages (programming languages belonging here as well).
I've seen this sort of syntax description for a long time. If you're interested in ancient history, take a look at the TOPS-10/TOPS-20 COBOL-74 Language Manual (AA-5059B-TK).