I'm using Swift 3 and xcode 8. I'm very new to objective-C and fairly new to swift, so maybe this is an idiot question. But here goes!
I'm bridging from objective-C to swift 3. Here's a code snippet of the objective-C:
typedef NS_ENUM(NSInteger, MaplyMapType) {
MaplyMapType3D,
MaplyMapTypeFlat,
};
#interface MaplyViewController : MaplyBaseViewController
/// #brief Initialize as a flat or 3D map.
- (nonnull instancetype)initWithMapType:(MaplyMapType)mapType;
In my Swift 3 source file I instantiate a MaplyViewController. The following is the WORKING code (it compiles and runs, and no xcode errors).
theViewC = MaplyViewController(mapType: .typeFlat)
Why does this work? From references https://developer.apple.com/library/content/documentation/Swift/Conceptual/BuildingCocoaApps/InteractingWithCAPIs.html and other references I think the correct code should be:
theViewC = MaplyViewController(mapType: .flat)
But that won't compile.
MORE INFO FROM ONE DAY LATER: Amin Negm-Awad in his comment below has almost explained this. The simple bridging rules cannot be used to produce identifiers .flat and .3D because identifier .3D is not allowed. The language reference says "Identifiers begin with an uppercase or lowercase letter A through Z, an underscore (_), a noncombining alphanumeric Unicode character in the Basic Multilingual Plane, or a character outside the Basic Multilingual Plane that isn’t in a Private Use Area. After the first character, digits and combining Unicode characters are also allowed."
So the bridging cannot result in enum identifiers .flat and .3d. I could not find any reference to explain the rules bridging uses to come up with the alternative identifies, namely .typeFlat and .type3D in this case.
Likely it is, because the other identifier (MaplyMapType3D) would be 3Dinstead of type3D, but identifiers must not start with a digit. So one has to keep type.
Related
Edit/Update:
Thank you all for responding. I understand I was being too vague, but wasn't sure if posting naked lines of code would be useful in this case.
In my .vb file I have a pulldown control with its validation values as:
TempUnit.DataSource = {"°C", "°F", "°R", "K"}
...which is stored in a variable:
Dim unit As String = TempUnit.SelectedItem.ToString
...which gets passed into a function along with other variables:
Function xxx(..., ByVal unitT As String) As Double
... which finally calls the .fs file and gets evaluated using:
let tempConv t u =
match u with
|"°C" -> t * 9.0 / 5.0 + 32.0
|"°R" -> t - 459.67
|"K" -> t * 9.0 / 5.0 - 459.67
|_ -> t
If any temperature unit other than Kelvin is selected, the match fails and defaults to the else case (which is Fahrenheit in this context). I ended up bypassing the degree symbol entirely by evaluating the substring instead:
Dim unit As String = TempUnit.SelectedItem.ToString.Substring(1)
The program is working again, but I have no idea what I changed, if anything, to make the string match stop working. The first thing I tried was to copy/paste from one file to other to ensure they were identical strings, in addition to trying other symbols, but to no avail. The degree symbol is what caught my attention, but then I checked the pressure units and found the exact same issue with the micro prefix.
Thank you, Hans Passant, I had unicode in mind as a possible solution, but it didn't seem like an easy fix in the heat of the moment. I appreciate your link.
Original Post:
I have a VB program referencing a function stored in an F# library file whose arguments include unit of measure strings containing special characters (e.g. "°C" "µBar").
The strings are identical in the .vb and .fs files; and there was no issue until the F# library file stopped recognizing the Alt-Code characters for reasons unbeknownst to me.
The program works as intended if I remove the offending Alt-Code character from the string definitions in the F# and VB files.
What would cause a match to fail between two identical strings that happen to contain an Alt-Code character?
What is the proper way to handle Alt-Code characters in F# (and VB for that matter)?
The µ glyph is a bit infamous. Unicode has two codepoints that look like that: U+03BC = "Greek small letter Mu" and U+00B5 = "Micro sign". One is a letter in the Greek alphabet, the other is a symbol that often appears in math and units.
Compare μ and µ. Looks almost identical in most fonts (you can see the difference with Segoe UI) and very easily fools the human eye. Typographers insist they are not the same, particularly if they are Greek I'd imagine. Nor does a computer, the problem you are surely dealing with.
Copy/paste or re-type to fix. The Charmap.exe applet in Windows is very handy to get this right.
I am studying YACC and the concept of a terminal symbol vs a token keeps coming up. Could someone explain to me what the difference is or point me to an article or tutorial that might help?
They are really two names for the same thing, but usually "terminal" is used to describe what the parser is working with, while "token" is used to describe the corresponding sequence of symbols in the source.
In a parser generator like yacc, the grammar of the language is defined in terms of an "alphabet" of "terminals". The word "alphabet" is a little confusing because they are strings, not letters. But from the parser's perspective, every terminal is an indivisible unit indistinguishable from any other use of the same kind of terminal. So the source code:
total = 17 + subtotal;
will be presented to the parser as something like:
ID EQUALS NUMBER PLUS ID SEMICOLON
There is a correspondence between the stream of terminals which the parser sees and substrings of the input language. So we say that the "token" total is an instance of the "terminal" ID. There may be an unlimited number of potential tokens corresponding to a given terminal (or they may be just one, as with the terminal EQUALS) but what the parser actually works with is a smallish finite set of terminals.
(Question by John Williams, from a Coursera forum, which I decided to share with the community, since I haven't been able to find this answered anywhere.)
The following code runs without error:
int _j = 1;
//int 2var = 2;
int var2 = 2;
int Kvar = 3; // first letter can be uppercase
int spec$var = 4;
int com_pound_var = 5; // compounding without camel case
int com$pound$two = 6;
int $var = 199;
println(_j);
println(var2);
println(Kvar);
println(spec$var);
println(com_pound_var);
println(com$pound$two);
println($var); //first character can be special
Since the compiler accepts _j, Kvar, and $var as valid variable names, it is clear that variable names do not need to start with a lowercase letter.
I was unable to locate the variable naming rules anywhere in the reference.
What are the variable naming rules for the Processing language?
Quick answer: can start with any letter, underscore and dollar signs, continue with letters, numbers, underscore and dollar signs. Details below.
I could also not find anything in the reference or the documentation at all. However, inspecting the source code, I found that Processing is not a language of its own, but rather a framework in which you run some commands. The difference is that you're actually writing a different language, and Processing just gives you some basic scaffolding where you build on top of.
For some technical details: Processing compiles a Java Build with some flags, spins up a virtual machine (Java VM, not same thing as a full fledged virtual machine) and connects to it to get input and output streams (this is why you can interact with the mouse or get the console output of your own program in a separate window). (Source.)
This language, which you may have guessed already, is Java.
With that said, the actual docs that answer this question is the Java Language Specification, which, to simplify things, is as close as you can get to an answer. (But if you really want to know, it's a mess.)
Specifically, the section on Identifiers, which I'll sum up below:
Can start with any letter (A-Z, a-z), underscore (_), dollar sign ($), or any unicode "letter" (accented, chinese, etc. Details.)
Can continue with any of the above, and can also continue with digits (0-9). Can also contain other unicode "letters" (Details.)
Can have unlimited length
Cannot be any Java keyword (list here)
Cannot be false, true, null
They can look the same and still be different if their codes are different (some Unicode letters look just like letters but are different ones)
I hope this helps! Investigating was fun.
What does plus mean in method declarations in Perl6?
Here is an example from spec
submethod BUILD (+$tail, +#legs, *%extraargs) {
$.tail = $tail;
#:legs = #legs;
}
2019 Update See the section Variadic positionals destructuring; +#foo and *#foo in my answer to the SO question "variable number of arguments to function/subroutine".
In 2015 Larry Wall introduced the + parameter prefix, one of four parameter prefixes (*, **, +, |) that signify slurpy (variadic) parameters. He added it to the Rakudo compiler, added some tests, gave a brief informal description of it on the irc channel, and added a section on it to the relevant language design doc.
The example quoted in the original question is taken from an archive of an informal document written and frozen in time over a decade ago. At that time a + parameter prefix signified a named parameter as contrasted with a positional one. Nowadays we use : for that, thus:
submethod BUILD (:$tail, :#legs, *%extraargs) {
$.tail = $tail;
#.legs = #legs;
}
Your "spec" links goes to a historical document, and the syntax has long gone from Perl 6. I'm not sure what it used to do, maybe "at least one argument", in analogy to the + quantifier in regexes.
For an up-to-date specification, please read http://perlcabal.org/syn/S06.html which contains all the information on signatures and subroutines.
I'm trying to simplify my code by using #define statements. This is because it contains a lot of repetitive "chunks" of code that cannot be repeated using the obvious alternative, functions, because in these chunks, variables need to be declared like you'd do in a #define statement, e.g. #define dostuff(name) int name##Variable;.
Code
#define createBody(name,type,xpos,ypos,userData,width,height) b2BodyDef name##BodyDef;\
name##BodyDef.type = type==#"dynamic"?b2_dynamicBody:b2_staticBody;\
name##BodyDef.position.Set(xpos,ypos);\
name##BodyDef.userData = userData;\
name=world->CreateBody(&name##BodyDef);\
b2PolygonShape name##shape;\
name##shape.SetAsBox(width/ptm_ratio/2,height/ptm_ratio/2);
... and applying that in the following:
createBody(block, #"dynamic", winSize.width*5/6/ptm_ratio, winSize.height*1/6/ptm_ratio, ((__bridge void*)blockspr), blockspr.contentSize.width, blockspr.contentSize.height)
// error appears there: ^
Now my point is that everything's working great, no errors, except a single one that's freaking me out:
Expected unqualified-id
which points at the first bracket in ((__bridge ..., as indicated. (That argument gets passed via the userData argument to createBody.)
I know this code is nowhere near simple, but since everything else is working, I believe that an answer must exist.
This is my first question on SO, so if there's anything unclear or insufficient, please let me know!
I'm trying to simplify my code by using #define statements.
This sounds an alarm in my mind.
Break this down into functions. You said you can't. I say you can.
Notice that your macro here:
createBody(name,type,xpos,ypos,userData,width,height);
It has exactly the same syntax as a C function. So you've already created a function, you only declared it as a macro. There's no reason why you couldn't rewrite it as a function (C or Objective-C doesn't matter). You do not need to give each body its own name, instead you could store them in a dictionary (careful though because Box2D takes ownership of the bodies).