Like this syntax, I don't know how to distinguish their case, is there a strict limit?
The keyword in NGQL is case-insensitive, while it’s recommended to write upper case for keywords when we could.
Related
Trying to use dictionary bracket syntax in match statements and it doesn't let me. Is this intentional by design, or am I missing something?
Below doesn't work
match curr:
myDict["one"]:
#do something
myDict["two"]:
#do something
I am forced to use the dot syntax instead and it works...is this by design?
I can't conclude that it is intentional, but I can tell you it does not work and will not work.
In Godot 3, the parser does not support this syntax, which might have been oversight. Or it might have been that the parser was already becoming a mess and hard to maintain, so features that weren't critical weren't considered? Perhaps… After all, GDScript was reworked from the ground up for Godot 4. So…
In Godot 4, the compiler does not support it, and there is a reason: it wants a constants, which also allow some optimizations. Does Godot 3 care about that? Nope, you can use variables, and there is no problem. And no, the match is not optimized in Godot 3, nothing is, it is all interpreted.
Do you really care if it was intentional?
You are likely OK to do this with a bunch of if statements. After all, if you are willing to write a case for each item in the dictionary, they probably are a manageable amount.
You could also throw design patterns at it. The strategy pattern comes to mind.
I'm in a situation where I'm modifying an existing compiler written in OCaml. I've added locations to the AST of the compiled language, but it has cause a bunch of bugs, because equality checks that previously succeeded now fail when identical ASTs have a different location attached.
In particular, I'm seeing List.mem return false when it should return true, since it relies on equality.
I'm wondering, is there a way for me to specify that, for any two values of my location type, that = should always return true for any two values of this type?
It would be a ton of work to refactor the entire compiler to use a custom equality everywhere, particularly since many polymorphic functions rely on being able to use = on any type.
There's no existing OCaml mechanism to do what you want.
You can use ppx to write OCaml syntax extensions, and (as I understand it) the behavior can depend on types. So there's some chance you could get things working that way. But it wouldn't be as straightforward as what you're asking for. I suspect you would need to explicitly handle = and any standard functions (like List.mem) that use = implicitly. (Note that I have no experience with ppx.)
I found a description of PPX here: http://ocamllabs.io/doc/ppx.html
Many experienced OCaml programmers avoid the use of built-in polymorphic equality because its behavior is often surprising. So it might be worth converting to a custom comparison function after all.
What an annoying problem to have.
If you are desperate and willing to write a little C code you can change the representation of locations to Custom_tag blocks, which allow customising the behaviour of some of the polymorphic operations. It's a nasty solution, and I suggest you look hard for a better approach before resorting to this one.
One possibility is that most of the compiler does not use locations at all. If so, you might be able to get away with replacing every location in the AST with the same dummy location. That should allow equality to behave as if locations were not there at all. This is rather hacky, and may not be possible if passes later in the compiler make any use of location info.
The 'clean' solution is to define a sane equality operation for ASTs (or to derive one using ppx) and to change the code to use that. As you say, this would be a lot more work.
I would like your opinion about using Upper or lowerCamelCase in a case insensitive and procedural language (Oracle PL/SQL).
Some guys wanna use this pattern in my job, but the programmers don't like the idea...
Oracle Forms and Reports do not support autocomplete.
My opinion: I don't see any reason to use Camel Case in a case insensitive language...
What's your opinion?
CamelCase really increases readability for variables when you need multi-word names, and its easier to write than using underscores for spaces, especially for programmers who use them all the time in most common languages.
in the long run, being case insensitive should free people to use whatever case they prefer, so not sure why this is an issue, but I vote Yes for CamelCase. SQL Keywords should probably be all caps or all lower, depending on your shop standard.
My questions is basically all in the title. I have no real application in mind, I'm just trying to make sure I use generally accepted good coding practices, and I remember my CS professor saying that breaks are generally avoided when possible, but he never told us why.
I would ask him myself, but he's out of his office this summer.
This is a theological issue. People who are opposed to the use of break (or continue for that matter) say that it makes the control flow of the program harder to follow and thus makes the program less readable. But an easier way to make readable code is simply to make shorter functions, use meaningful variable names, comment appropriately, etc.
Sometimes professors are wrong.
He may object to skipping out of a loop right in the middle of it. This is akin to using a return statement in the middle of a function...some consider that blasphemy.
What ever is the simplest, and produces the most easily maintainable code, is what should be used.
Generally speaking, you will use 'break' to get out of cycles when a certain condition is met (for instance, when you've found what you're looking for, etc.); I don't consider it 'evil' such as the infamous GOTO statement, but reasonable people will differ.
What Dijkstra said was harmful about goto statements - http://drdobbs.com/blogs/cpp/228700940
and https://softwareengineering.stackexchange.com/questions/58237/are-break-and-continue-bad-programming-practices
Your professor was saying "breaks should be avoided" because they are similar to the now-taboo goto statement. However to say "breaks should be avoided whenever possible" is just wrong.
Break exists for readability. You can do anything without break that you can with it, but that doesn't mean you should. Sometimes it just makes sense to make a statement like "In this condition, break out of this loop." or "In this condition, return from this function."
It's a bad idea to use break for program flow in a nested for loops in a way that might give a casual reader some confusion.
Simple rule of thumb: Does using break here (instead of additional if/thens, another boolean, etc.) make this easier to understand or harder to understand? It's that simple.
Ask your professor to try writing a switch statement in any C-style language without break. It can be done I'm sure, but the resulting code is not going to be any more readable.
switch (someExpression) {
case enumVar.CaseA:
// do things here, but don't you dare break!
case enumVar.CaseB:
// do other things - possibly unrelated or contradictory to CaseA
// ... and so on
}
I'm writing a parser to parse CSS.
I started by modifying the CSS reference grammar, to use whichever grammar and lexer syntax are supported by the 3rd-party parser generator tool which I'm using.
I think that I've finished coding the grammar: the parser-generator is able now to generate state transition tables for/from my grammar.
The result (the output from the parser-generator) is approximately 116 "rules", which correspond to 116 cases in a switch statement. Examples of these rules/switch statements are:
Stylesheet begins with specifying a charset
Stylesheet begins without specifying a charset:
Stylesheet is empty
Stylesheet begins with whitespace
...etc...
The parser-generator has done all it can for me, and now I'm begining to write (by hand) the various cases of the switch statements, which will build what I think people call an 'abstract syntax tree'.
My question is about how to test this. I think that what I want is a set of CSS files which exercise the various combination and possibilities: e.g. one CSS file which specifies a charset; another file which doesn't specify a charset; etc.
Is there general a way to auto-generate this set of input data, for an arbitrary grammar or set of rules?
Alternatively, is there a set of specifically CSS files, whose purpose is to cover the combination and possibilities allowed by the standard CSS grammar?
Feel free to comment too if I'm going about this all wrong.
At the moment I don't need:
Files to test handling of illegal input (i.e. of files which don't conform to the grammar)
Testing of how various browsers render based on their parsing of CSS
Microsoft made a set of many thousands of CSS tests for IE8 compliance with the CSS spec.
http://samples.msdn.microsoft.com/ietestcenter/css.htm
While they are focused on testing browser compliance, possibly you could adapt them.
There are also the older W3C test suites, which are not as complete, but might serve your purpose:
http://www.w3.org/Style/CSS/Test/
A context free grammar implicitly proposes an infinite set of (parse) trees. Each proposed tree has a set of leaves which make a concrete sentence in the language accepted by that grammar. By exploring the the set of proposed trees (e.g, by expanding each nonterminal according to it possible alternatives), you can generate any arbitrary instance of the language. You can generate a set of tests by walking the tree proposals and making random choices. A more focused approach would be to use iterative deepening search to generate sentences ordered by size. With any interesting grammer, you're likely to get a huge number of instances, but hey, that's what automated testing is for.
What I wouldn't do is generate such sentences from your production grammar, because the sentences you generate will be, by definition, the ones it accepts :-{ What you should do is construct your sentence generator using the reference grammar, to exploit the fact that you what it accepts and what you've implemented might be different.
4 years late for OP but SimonSapin/css-parsing-tests seems like a decent test suite for parsers.