I have ANTLRWorks 1.5.2. I need to resolve Decision can match input using multiple alternative warnings in my one grammar file which imports another file.
parser grammar PL;
import SQL;
I need to bring both of the files in antlr works. But Antlr Works throws undefined import error. How can I have both the files in ANTLR Works at the same time? The error has been generated by adding a rule in PL and it conflicts with the rule in SQL. These are very large grammar files and visualization can help to solve the problem.
ANTLRWorks actually imports the import grammar at runtime if import grammar is placed in the same folder. If grammar is placed at C:\test and import grammar is also placed at C:\test then ANTLRWorks reads the file from. When I generated the code it throws warnings in the imported grammar.
Related
I found that very useful Go library in the web https://github.com/deckarep/golang-set that tries to port Python sets to Go.
Thanks to Visual Studio Code I eventually got it to work by importing the library import "github.com/deckarep/golang-set" and calling a function in my code:
mySet := mapset.NewSet()
VS Code automatically recognizes the alias and replaces the import directive:
import mapset "github.com/deckarep/golang-set"
However, being someone who finds those aliases confusing, I was trying to remove it but doing so, VSCode removes it from both the import statements and my code. VS Code then tells me:
undeclared name: NewSet compiler(UndeclaredName)
The package name from NewSet(...) is also package mapset. So I thought I could simply remove it. But it does not work.
I also tried to work analogously to other 3rd party packages and call the functions by the repository's name:
mySet := golang-set.NewSet()
This also leads to an error. Is the removing of the alias not possible here due to the hyphen maybe or am I overseeing something else?
Several things here:
mapset is the package name. You can see this by looking at the package source code.
While the import alias, in this case, is not strictly needed from a language standpoint, it's added for clarity, since the package name (mapset) does not match the import path (golang-set). Without the alias in the import statement, there's no way to tell how the package is referenced. This is why it's important for it to be there.
You cannot use golang-set as your import name, becuase the - character is not permitted in an import alias. However, if you really want to, you could use golang_set or similar, by explicitly providing this as your alias:
import golang_set "github.com/deckarep/golang-set"
Note that this goes against naming conventions, in that packages should not have _ characters in the name. But it should still be valid.
Best practice would be just to use mapset as the alias. It's the least confusing of all the available options (which is why it's automatically selected).
I'm learning the Go language by following a tutorial. Not wanting to just blindly copying the examples, but understanding what's going on, I came accross the following puzzling case:
In the tutorial the import statement was written as:
import (
"fmt"
"example.com/greetings"
)
I first was surprised about the empty line between the two strings and thought that this is just following some style guide, and when creating my program, I wrote it simply as
import (
"fmt"
"example.com/greetings"
)
To my astonishment, when saving the code (I was using Visual Studio Code for editing at that time), the editor re-inserted the empty line, so I reckon that there must be a deeper reason for it.
I can't see any effect on my program, because when I later removed the line with a less presumptuous editor (nano), my program seemed to run the same as with empty line included ... but maybe I just missed something. So, my question, does this empty line have a deeper meaning, which I just don't grasp yet?
There is no significance to the empty lines in the import group.
Some editors (including VSCode) put standard library imports first, then add an empty line, and then other (3rd party imports). Also the 2 groups are sorted alphabetically.
Again, there is no significance to this other than being easier to read. It also comes handy if everyone formats imports like this, so there are no "meaningless" commits in a version system due to different import sorting / organizing.
I am developing a go package, which is a little bit complex and thus I want to organize the source code into multiple directories.
However, I don't want the users of the package to have to use too long imports. Anyways, the internal structure of the package isn't their concern.
Thus, my package structure looks so:
subDir1
subSubDir1
subSubDir2
subDir2
subSubDir3
...and so on. All of them have their exported calls.
I would like to avoid that my users have to import
import (
"mypackage/subDir1"
"mypackage/subDir1/subSubDir2"
)
...and so on.
I only want, if they want to use an exported function from my package, they should have access all of them by simply importing mypackage.
I tried that I declare package mypackage in all of the .go files. Thus, I had source files in different directories, but with the same package declaration.
In this case, the problem what I've confronted was that I simply couldn't import multiple directories from the same package. It said:
./src1.go:6:15: error: redefinition of ‘mypackage’
"mypackage/mysubdir1"
^
./src1.go:4:10: note: previous definition of ‘mypackage’ was here
"mypackage"
^
./src1.go:5:15: error: redefinition of ‘mypackage’
"mypackage/mysubdir2"
^
./src1.go:4:10: note: previous definition of ‘mypackage’ was here
"mypackage"
^
Is it somehow possible?
You should not do this in any case, as the language spec allows a compiler implementation to reject such constructs. Quoting from Spec: Package clause:
A set of files sharing the same PackageName form the implementation of a package. An implementation may require that all source files for a package inhabit the same directory.
Instead "structure" your file names to mimic the folder structure; e.g. instead of files of
foo/foo1.go
foo/bar/bar1.go
foo/bar/bar2.go
You could simply use:
foo/foo1.go
foo/bar-bar1.go
foo/bar-bar2.go
Also if your package is so big that you would need multiple folders to even "host" the files of the package implementation, you should really consider not implementing it as a single package, but break it into multiple packages.
Also note that Go 1.5 introduced internal packages. If you create a special internal subfolder inside your package folder, you may create any number of subpackages inside that (even using multiple levels). Your package will be able to import and use them (or to be more precise all packages rooted at your package folder), but no one else outside will be able to do so, it would be a compile time error.
E.g. you may create a foo package, have a foo/foo.go file, and foo/internal/bar package. foo will be able to import foo/internal/bar, but e.g. boo won't. Also foo/baz will also be able to import and use foo/internal/bar because it's rooted at foo/.
So you may use internal packages to break down your big package into smaller ones, effectively grouping your source files into multiple folders. Only thing you have to pay attention to is to put everything your package wants to export into the package and not into the internal packages (as those are not importable / visible from the "outside").
Inside your package source code, you have to differentiate your source directories by renamed imports. You can declare the same package mypackage in all of your source files (even if they are in different directories).
However, while you import them, you should give an induvidual names to the directories. In your source src1.go, import the other directories on this way:
import (
"mypackage"
submodule1 "mypackage/mySubDir"
)
And you will be able to reach the API defined in "mypackage" as mypackage.AnyThing(), and the API defined in mySubDir as submodule1.AnyThing().
The external world (i.e. the users of your package) will see all exported entities in myPackage.AnyThing().
Avoid namespace collisions. And use better understable, intuitive naming as in the example.
Yes, this is doable without any problems, just invoke the Go compiler by hand, that is not via the go tool.
But the best advice is: Don't do that. It's ugly and unnecessarily complicated. Just design your package properly.
Addendum (because the real intention of this answer seems to get lost sometimes, maybe because irony is too subtle): Don't do that!! This is an incredible stupid idea! Stop fighting the tools! Everybody will rightfully hate you if you do that! Nobody will understand your code or be able to compile it! Just because something is doable in theory doesn't mean this is a sensible idea in any way. Not even for "learning purpose"! You probably even don't know how to invoke the Go compiler by hand and if you figure it out it will be a major pita.
Assume there is a function F in package A that some code I'm creating needs to call. How do I call it?
If I'm Calling it from outside package A, then I uses A.F(...) and if I'm inside A I uses F(...). But what if Murphy prevents me from knowing which is true or requires a byte identical line work in both?
[note: I'm taking it as a given that such a case will occur because, in my experience and observations, that is generally a safe assumption. Even in the absence of technical reasons for it, PHBs and legislators are good sources of the ridiculous.]
There is no such syntax. Observe the following things:
Cyclical imports are forbidden. This especially means that a package cannot import itself. Thus, a package cannot refer to one of its symbols S with the pkg.S syntax because it will not be able to import itself.
Even if you solved that problem, observe that packages can be given an arbitrary name once imported. For instance, you could do:
import bar "foo"
Which imports S from package "foo" as bar.S as opposed to the expected foo.S.
The following things could be used to work around this:
In the package "foo", create an internal object foo whose members are the symbols foo exports. This allows you to use the foo.S syntax in foo itself, but is a horrible kludge.
Use an import declaration like
import . "foo"
which allows you to use symbol S from package "foo" as S, i. e. without prefix. Notice that this kind of import declaration, called dot imports, is considered bad style and might break things if the set of symbols you declare / the package you import declares changes.
I am trying to add some support for D programming language to my vim config. For autocompletion I need to detect packages that are included. This is not exactly hard to do in simple case:
import std.stdio;
import std.conv;
My config:
set include=^\\s*import
set includeexpr=substitute(v:fname,'\\.','/','g')
Works great.
However, imports can have more complicated format, for example:
package import std.container, std.stdio = io, std.conv;
I was not able to find a simple way to parse this with include and includeexpr.
Also there is a second problem: import can have different access modifiers, like public and private. VIM scans included files recursively, import statements from included files are parsed too. But I need to distinguish between the file I am working with now and files which are scanned automatically: in current file all imports should be detected, but in other files only public import statements should add more files to the search.
Thanks for help.
Update
It's a shame if this can not be done without full parsers. Essentially, I only need two things:
ability to return an array from includeexpr instead of one file name
ability to distinguish between includes in current and other files
I think only way to do it reliably is to use complete parser and semantic analyzer. D Completion Daemon (https://github.com/Hackerpilot/DCD/tree/master/editors/vim ) has vim plugin and is not very resource-hungry.
Vim's include mechanism and 'includeexpr' are heavily influenced by the C programming language and only work for single files. You cannot return a list of filenames, so it won't be possible to support D's complex include mechanism with Vim. Use an IDE that is fully tailored to support the programming language, not a general-purpose text editor.