This question already has answers here:
Creating a Constant Type and Restricting the Type's Values
(2 answers)
What is an idiomatic way of representing enums in Go?
(14 answers)
Closed 8 months ago.
I have a struct Direction with a value of type string. Direction should be N, S, W or E.
type Direction struct {
value string
}
Inspired by an answer of this question: Does Go have "if x in" construct similar to Python? I guess a good way to create Direction in a valid manner can be this one:
func NewDirection(direction string) Direction {
switch direction {
case "N","S","W","E": return Direction{direction}
}
panic("invalid direction")
}
But this is not enough for me because I can still create invalid Direction:
d := Direction{"X"}
I also found this interesting article about enforcing the use of constructor in go. Reading this article I can see that is necessary the usage of another package. May I have a "protected" struct in, for example, main package?
You've already done almost everything you should do by convention:
make the field unexported
provide a constructor
put a comment on the type stating that the constructor should be used, and explain how zero-values are treated (if that matters)
Now users of the package can't modify the field, and the existence of the constrictor makes it clear that it should be called to create valid instances. This is the convention that is set by the standard library.
Sure, there are other ways that you can make it even harder to invalidate values but this is essentially just wasting time and overcomplicating your code for the sake of an unwinnable arms race against an imaginary opponent.
If someone doesn't understand the language and doesn't read documentation, then they're always going to find a way to misuse it. If they are actively trying to sabotage themselves, there's nothing you can do to stop them and no reason to either.
Packages are the smallest functional unit of code organization in Go. There is no way to protect field at, for example, the file level. Even files within the same package effectively operate as if all their code was in the same file. Therefore, any code in the same package as the constructor will have the same privileges as the constructor.
This question already has answers here:
What is this "err.(*exec.ExitError)" thing in Go code? [duplicate]
(2 answers)
What is the meaning of "dot parenthesis" syntax? [duplicate]
(1 answer)
Closed 5 years ago.
Go Newb here -- I've encountered the following bit of Go code that I didn't write
if tc, ok := tng.(ThingClasser); ok {
//... do some stuff ...
}
I won't understand the semantics of tng.(ThingClasser).
In some ways this looks like a method call -- i.e. there are two variables (ec, ok) sitting there ready to accept multiple return values.
However, tng.(ThingClasser) itself looks like its a property access, not a method call.
However however, the parens around ThingClasser are a wrinkle I've never seen before. Also, if it matters, the ThingClasser symbol is defined elsewhere in this project as an interface, so I think maybe this is some syntactic sugar around an does this implement an interface -- but then the two return values confused me.
Googling hasn't turned up anything concrete, but this is one of those hard things to google for.
Does anyone here know what this call/syntax is in GoLang, and possible point me at the relevant manual pages so I can RTFM?
It's a type assertion. The returned values are 1) the object, converted to the given type; and 2) a boolean indicating if the conversion was successful. ThingClasser is the type being converted to. Documentation can be found here: https://golang.org/ref/spec#Type_assertions
This question already has answers here:
Why isn't short variable declaration allowed at package level in Go?
(3 answers)
Closed 8 years ago.
Coming from a background in Java and C# I am very pleased with the brevity of Golang's ability to use the shortcut method for variable declaration for private variables within functions, which allows me to write:
x := 1.5
It reminds me of duck typing in a dynamic language such as Python. However, in declaring global variables outside of the scope of a function you still need to use the more verbose syntax of:
var x float64 = 1.5
I'm just wondering why the shortcut method works for private variables and not globals? I know that the designers of the language are quite experienced so I'm assuming that this isn't reflective of a feature overlooked. Is there a technical reason why this kind of type inference (and I realize that the := shortcut is not the same as proper type inference) wouldn't work at the global scope? It just seems somewhat inconsistent in terms of the design, and as an inexperienced Gopher I must admit to being thrown off by this on a couple of occasions. On the whole however I'm really enjoying Go.
See the Ian's answer in this thread:
https://groups.google.com/forum/#!msg/golang-nuts/qTZemuGDV6o/IyCwXPJsUFIJ
At the top level, every declaration begins with a keyword. This
simplifies parsing.
Actually you don't need to specify type in many cases.
var x = 1.5
should work fine. It's probably as short as it can get and it's not much longer than local variable shortcut.
So there is a shortcut for global.
As to why := can't be used, I would guess that calling out var makes code structure more consistent as other global constructs start with a keyword - func, const, import, type.
What is the difference between syntax and semantics in programming languages (like C, C++)?
TL; DR
In summary, syntax is the concept that concerns itself only whether or not the sentence is valid for the grammar of the language. Semantics is about whether or not the sentence has a valid meaning.
Long answer:
Syntax is about the structure or the grammar of the language. It answers the question: how do I construct a valid sentence? All languages, even English and other human (aka "natural") languages have grammars, that is, rules that define whether or not the sentence is properly constructed.
Here are some C language syntax rules:
separate statements with a semi-colon
enclose the conditional expression of an IF statement inside parentheses
group multiple statements into a single statement by enclosing in curly braces
data types and variables must be declared before the first executable statement (this feature has been dropped in C99. C99 and latter allow mixed type declarations.)
Semantics is about the meaning of the sentence. It answers the questions: is this sentence valid? If so, what does the sentence mean? For example:
x++; // increment
foo(xyz, --b, &qrs); // call foo
are syntactically valid C statements. But what do they mean? Is it even valid to attempt to transform these statements into an executable sequence of instructions? These questions are at the heart of semantics.
Consider the ++ operator in the first statement. First of all, is it even valid to attempt this?
If x is a float data type, this statement has no meaning (according to the C language rules) and thus it is an error even though the statement is syntactically correct.
If x is a pointer to some data type, the meaning of the statement is to "add sizeof(some data type) to the value at address x and store the result into the location at address x".
If x is a scalar, the meaning of the statement is "add one to the value at address x and store the result into the location at address x".
Finally, note that some semantics can not be determined at compile-time and therefore must be evaluated at run-time. In the ++ operator example, if x is already at the maximum value for its data type, what happens when you try to add 1 to it? Another example: what happens if your program attempts to dereference a pointer whose value is NULL?
Syntax refers to the structure of a language, tracing its etymology to how things are put together.
For example you might require the code to be put together by declaring a type then a name and then a semicolon, to be syntactically correct.
Type token;
On the other hand, the semantics is about meaning.
A compiler or interpreter could complain about syntax errors. Your co-workers will complain about semantics.
Semantics is what your code means--what you might describe in pseudo-code. Syntax is the actual structure--everything from variable names to semi-colons.
Wikipedia has the answer. Read syntax (programming languages) & semantics (computer science) wikipages.
Or think about the work of any compiler or interpreter. The first step is lexical analysis where tokens are generated by dividing string into lexemes then parsing, which build some abstract syntax tree (which is a representation of syntax). The next steps involves transforming or evaluating these AST (semantics).
Also, observe that if you defined a variant of C where every keyword was transformed into its French equivalent (so if becoming si, do becoming faire, else becoming sinon etc etc...) you would definitely change the syntax of your language, but you won't change much the semantics: programming in that French-C won't be easier!
You need correct syntax to compile.
You need correct semantics to make it work.
Late to the party - but to me, the answers here seem correct but incomplete.
Pragmatically, I would distinguish between three levels:
Syntax
Low level semantics
High level semantics
1. SYNTAX
Syntax is the formal grammar of the language, which specifies a well-formed statement the compiler will recognise.
So in C, the syntax of variable initialisation is:
data_type variable_name = value_expression;
Example:
int volume = 66 * 22 * 55;
While in Go, which offers type inference, one form of initialisation is:
variable_name := value_expression
Example:
volume := 66 * 22 * 55
Clearly, a Go compiler won't recognise the C syntax, and vice versa.
2. LOW LEVEL SEMANTICS
Where syntax is concerned with form, semantics is concerned with meaning.
In natural languages, a sentence can be syntactically correct but semantically meaningless. For example:
The man bought the infinity from the store.
The sentence is grammatically correct but doesn't make real-world sense.
At the low level, programming semantics is concerned with whether a statement with correct syntax is also consistent with the semantic rules as expressed by the developer using the type system of the language.
For example, this is a syntactically correct assignment statement in Java, but semantically it's an error as it tries to assign an int to a String
String firstName = 23;
So type systems are intended to protect the developer from unintended slips of meaning at the low level.
Loosely typed languages like JavaScript or Python provide very little semantic protection, while languages like Haskell or F# with expressive type systems provide the skilled developer with a much higher level of protection.
For example, in F# your ShoppingCart type can specify that the cart must be in one of three states:
type ShoppingCart =
| EmptyCart // no data
| ActiveCart of ActiveCartData
| PaidCart of PaidCartData
Now the compiler can check that your code hasn't tried to put the cart into an illegal state.
In Python, you would have to write your own code to check for valid state.
3. HIGH LEVEL SEMANTICS
Finally, at a higher level, semantics is concerned with what the code is intended to achieve - the reason that the program is being written.
This can be expressed as pseudo-code which could be implemented in any complete language. For example:
// Check for an open trade for EURUSD
// For any open trade, close if the profit target is reached
// If there is no open trade for EURUSD, check for an entry signal
// For an entry signal, use risk settings to calculate trade size
// Submit the order.
In this (heroically simplified) scenario, you are making a high-level semantic error if your system enters two trades at once for EURUSD, enters a trade in the wrong direction, miscalculates the trade size, and so on.
TL; DR
If you screw up your syntax or low-level semantics, your compiler will complain.
If you screw up your high-level semantics, your program isn't fit for purpose and your customer will complain.
Syntax is the structure or form of expressions, statements, and program units but Semantics is the meaning of those expressions, statements, and program units. Semantics follow directly from syntax.
Syntax refers to the structure/form of the code that a specific programming language specifies but Semantics deal with the meaning assigned to the symbols, characters and words.
Understanding how the compiler sees the code
Usually, syntax and semantics analysis of the code is done in the 'frontend' part of the compiler.
Syntax: Compiler generates tokens for each keyword and symbols: the token contains the information- type of keyword and its location in the code.
Using these tokens, an AST(short for Abstract Syntax Tree) is created and analysed.
What compiler actually checks here is whether the code is lexically meaningful i.e. does the 'sequence of keywords' comply with the language rules? As suggested in previous answers, you can see it as the grammar of the language(not the sense/meaning of the code).
Side note: Syntax errors are reported in this phase.(returns tokens with the error type to the system)
Semantics: Now, the compiler will check whether your code operations 'makes sense'.
e.g. If the language supports Type Inference, sematic error will be reported if you're trying to assign a string to a float. OR declaring the same variable twice.
These are errors that are 'grammatically'/ syntaxially correct, but makes no sense during the operation.
Side note: For checking whether the same variable is declared twice, compiler manages a symbol table
So, the output of these 2 frontend phases is an annotated AST(with data types) and symbol table.
Understanding it in a less technical way
Considering the normal language we use; here, English:
e.g. He go to the school. - Incorrect grammar/syntax, though he wanted to convey a correct sense/semantic.
e.g. He goes to the cold. - cold is an adjective. In English, we might say this doesn't comply with grammar, but it actually is the closest example to incorrect semantic with correct syntax I could think of.
He drinks rice (wrong semantic- meaningless, right syntax- grammar)
Hi drink water (right semantic- has meaning, wrong syntax- grammar)
Syntax: It is referring to grammatically structure of the language.. If you are writing the c language . You have to very care to use of data types, tokens [ it can be literal or symbol like "printf()". It has 3 tokes, "printf, (, )" ]. In the same way, you have to very careful, how you use function, function syntax, function declaration, definition, initialization and calling of it.
While semantics, It concern to logic or concept of sentence or statements. If you saying or writing something out of concept or logic, then you are semantically wrong.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
Okay, this one is pretty hard to google.
Occasionally, I stumble upon code in any language that uses a naming convention where variable names start with the prefix 'the' under certain circumstances.
I could not figure out, however, what these circumstances are. So my questions are:
Is this convention common? Does it have a name?
If 1) is still "ungoogleable": What are the principles behind this convention? What problems does it address? I would like to understand.
If not covered by 1) and 2): Where does the convention come from? What are its origins? Is or was it connected to a specific programming language?
Examples:
From the Steinberg ASIO SDK 2.3, file asiodrivers.cpp, line 88:
extern IASIO* theAsioDriver;
where IASIO is an interface definition.
http://hl7api.sourceforge.net/base/apidocs/src-html/ca/uhn/hl7v2/util/StringUtil.html
http://xml.apache.org/xalan-c/apiDocs/classXStringAllocator.html
http://www.cplusplus.com/forum/beginner/65050/
http://www.cise.ufl.edu/~sahni/dsaac/enrich/c20/fold2.htm
I am hoping for some insight into why people do this. One example might be to tell parameters from members in setter/getter methods, but this choice of prefix seems random to me.
The only time I would be tempted to start a variable name with the would be to indicate that it is a singleton. Other than that its use seems unnecessary.
Based on personal experience (mostly Java, Ruby, Python, and long ago C and C++), the convention you describe is not common.
There is a related convention, the "Type Suggesting Parameter Name" pattern in Kent Beck's "Smalltalk Best Practice Patterns" (an excellent book regardless of whether you write Smalltalk), which names method parameters a(type) or an(type), e.g. anObject. My understanding is that this convention is to make code read a little more like English, not to avoid any naming collision that might otherwise arise. (Smalltalk classes are capitalized, so one could name parameters with downcased class names and there would be no collision.)
An expanded version of this convention which I saw somewhere prefixed parameters or locals with a or an and object instance variables with the, which makes some sense: the instance variable is "the" one most important to the containing object, while the parameter or local is just "a" thing. I wish I could remember where I saw it. I think it was written by a well-known author.
I don't normally use these conventions myself; instead I (like most code I've seen) use this. in Java and self. in Ruby to disambiguate instance variables and rely on short methods to sidestep the need to disambiguate parameters and locals. Naming variables for their roles and not their types (the best practice in any case) also usually eliminates the need for such conventions.
However, inspired by whatever it was I once read, I use the when a local shadows a method or function and I just can't think of a different meaningful name for the local.
In Ruby, a local shadows a method only when the method has no arguments:
def foo
7
end
foo = foo
=> nil # the left hand side shadowed the right hand side
This can be avoided by calling the method with empty parentheses:
def foo
7
end
foo = foo()
=> 7
but empty parentheses seem so un-Ruby to me that I prefer "the":
def foo
7
end
the_foo = foo
=> 7
In Python a local can shadow a function regardless of the function's argument count, so I find myself reaching for the more often.