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.
Related
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.
Everyone is aware of Dijkstra's Letters to the editor: go to statement considered harmful (also here .html transcript and here .pdf). I was wondering is anyone attempted to find a way to make code using goto's re-usable and maintainable and not-harmful by adding any other language extensions or developing a language which allows for gotos.
The reason I ask the question is that it occurs to me that code written in Assembly language often used goto's and global variables to make the program work well within a limited space. The Atari 2600 which had 128 bytes of ram and the program was loaded from ROM cartridge. In this case, it was better to use unstructured programming and to make the most of the freedoms this allows to make the most of a very limited space for the program.
When you compare this with a game programmed today without the use of gotos, the game takes up much more space.
Then it occurs to me that perhaps its possible to program with the use of gotos if some rules or other language changes are made to support this, then the negative effects of gotos could be reduced or eliminated. Has anyone tried to find a way to make goto's NOT considered harmful by creating a language or some rules to follow which allow gotos to be not harmful.
If no-one looked for a way to use gotos in a non-harmful way then perhaps we adopted structured programming un-necessarily based solely on this paper? Perhaps there is another solution which allows for the use of gotos without the down-side.
Comparing gotos to structured programming is comparing a situation where the programmer has to remember what every labels in the code actually mean and do, and where there are, to a situation where the conditional branches are explicitly described.
As of the advantages of the goto statement regarding the place a program might take, I think that games today are big because of the graphic and sound resources they use. That is, show 1,000,000 polygons. The cost of a goto compared to that is totally neglectable.
Moreover, the structural statements are ultimately compiled into goto ("jmp") statements by the compiler when outputting assembly.
To answer the question, it might be possible to make goto less harmful by creating naming and syntax conventions. Enforcing these conventions into rules is however pretty much what structural programming does.
Linus Torvald argued once that goto can make source code clearer, but goto is useful in so very special cases that I would not dare use it as a programmer.
This question is somehow related to yours, since I think this one of the most common situations where a goto is needed.
I don't like reinventing the wheel and this seemed like a pretty basic function. The same concept as these two questions except specifically for QStrings? QRegExp has an escape function so I'm wondering if I've just overlooked the QString version or whether there's a good reason there isn't one.
I doubt there would be such a function built into Qt, as it's really unlikely to be a frequently-required thing to do with QStrings. (Or at least, I can't think of any plausible usage that it would be worth the Qt maintainers supporting.)
QRegExp::escape() is a bit different, as it's doing a specific task of escaping characters that are known to have special meaning in regular expressions. Qt provides a method for this because it is a normal and common thing to need to do with regular expressions.
So, I think your best bet is going to be to take one of the example snippets of code that you linked to in the question, and roll your own function.
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
}
How do I declare the types of the parameters in order to circumvent type checking?
How do I optimize the speed to tell the compiler to run the function as fast as possible like (optimize speed (safety 0))?
How do I make an inline function in Scheme?
How do I use an unboxed representation of a data object?
And finally are any of these important or necessary? Can I depend on my compiler to make these optimizations?
thanks,
kunjaan.
You can't do any of these in any portable way.
You can get a "sort of" inlining using macros, but it's almost always to try to do that. People who write Scheme (or any other language) compilers are usually much better than you in deciding when it is best to inline a function.
You can't make values unboxed; some Scheme compilers will do that as an optimization, but not in any way that is visible (because it is an optimization -- so it should preserve the semantics).
As for your last question, an answer is very subjective. Some people cannot sleep at night without knowing exactly how many CPU cycles some function uses. Some people don't care and are fine with trusting the compiler to optimize things reasonably well. At least at the stages where you're more of a student of the language and less of an implementor, it is better to stick to the latter group.
If you want to help out the compiler, consider reducing top level definitions where possible.
If the compiler sees a function at top-level, it's very hard for it to guess how that function might be used or modified by the program.
If a function is defined within the scope of a function that uses it, the compiler's job becomes much simpler.
There is a section about this in the Chez Scheme manual:
http://www.scheme.com/csug7/use.html#./use:h4
Apparently Chez is one of the fastest Scheme implementations there is. If it needs this sort of "guidance" to make good optimizations, I suspect other implementations can't live without it either (or they just ignore it all together).