I have a simple function, I call it by ABCfunction(); no arguments, nothing.
Is it possible to call it (somehow) with no brackets? Just ABCfunction - to have just as simple call as that?
If I understand you, you're asking if you can call the function like this.
function
instead of like this:
funcion();
The answer is no, even though you're not technically passing anything to the function, those brackets are still needed so that the computer knows that it is a function. Otherwise it could be a variable etc.(In functional programming sometimes you do not need brackets under certain situations, but in those cases the function is a variable.)
Related
I have been looking in Rakudo source for the implementation of require, first out of curiosity and second because I wanted to know if it was returning something.
I looked up sub require and it returned this hit, which actually seems to be the source for require, but it's called sub REQUIRE_IMPORT. It returns Nil and is declared as such, which pretty much answers my original question. But now my question is: Where's the mapping from that sub to require? Is it really the implementation for that function? Are there some other functions that are declared that way?
require is not a sub, but rather a statement control (so, in the same category of things like use, if, for, etc.) It is parsed by the Perl 6 grammar and there are a few different cases that are accepted. It is compiled in the Perl 6 actions, which has quite a bit to handle.
Much of the work is delegated to the various CompUnit objects, which are also involved with use/need. It also has to take care of stubbing symbols that the require will bring in, since the set of symbols in a given lexical scope is fixed at compile time, and the REQUIRE_IMPORT utility sub is involved with the runtime symbol import too.
The answer to your question as to what it will evaluate to comes at the end of the method:
$past.push($<module_name>
?? self.make_indirect_lookup($longname.components())
!! $<file>.ast);
Which means:
If it was a require Some::Module then evaluate to a lookup of Some::Module
If it was a require $file style case, evaluate to the filename
Where in the VB6/VBA project references do Array(), LBound(), and UBound() come from..? When I'm typing in code, they don't appear in the Autocomplete list (ctrl+space), they don't get autocompleted, and they must be typed out completely before the text editor recognizes them. And only when a left-parenthesis is typed will ToolTipText pop up with the command syntax. Also, they do not appear anywhere in Object Explorer.
There's probably a basic concept in play here that I'm not aware of. And it makes me wonder, what other commands/statements/keywords are hidden in the same way..? Is there a list somewhere..? I googled for info but didn't find anything, probably because I don't know what I'm looking for and using the wrong search terms.
I ask these questions because I have the habit of prefixing many VB6 built-in functions like this: VBA.Left(), VBA.Len, VBA.Instr(), and so on. But I can't figure out what reference prefeix to use with Array(), LBound(), and UBound(), or perhaps they're so basic to VB6 that they don't have one.
I do this prefixing because years ago I was working on a large project, and there were functions I was trying to use with the same name in different reference libraries. I was a newbie and it took me a while to figure out, and it was causing tremendous problems since the functions were just NOT working the way I thought they were supposed to. It was then that I developed the prefixing habit after I figured it out. It's just easier that way, and always ensures the expected functions are being used.
The reason that they don't appear as IntelliSense options (and also why they don't appear in the Object Browser) is that they aren't declared in the VBE7.dll typelib for some reason that's beyond me. The Array function is implemented in the .dll as rtcArray. The utility of knowing that is dubious, in that its sole argument is a ParamArray, which means that if you called it directly from VBE7.dll you would need to create an array to have it feed you back the same array... This partially explains why it isn't on the typelib - a COM call would need to do the same thing, and the marshaling would basically be doing the same thing as what you'd expect the function to return.
LBound and UBound don't even appear as functions in the export table, so my guess is that they are handled more like "keywords" than first class functions internally. This makes some sense, in that it's fairly trivial to check the bounds of a SAFEARRAY if you have a pointer to the automation struct (you just index into the rgsabound array at the end of it and read the cElements and lLbound from it. Again a guess, but I'd assume that this allows for flexibility in letting LBound and UBound function with both fixed length and variable length arrays. In the fixed case, the array is basically managed as a block of memory with an indexer (more like a VT_CARRAY than a VT_SAFEARRAY). I'd imagine that handling this internally was easier or more convenient than providing first-class functions.
You won't find Debug in the Object Browser either, nor its methods Assert and Print.
You won't find Statements that are used like methods, like Open, Close, Get and Put, which is why you don't get any Intellisense when you use those statements, and the syntax must be memorized.
You will find Load and Unload as members of VBA.Global, but it's not clear what they belong to otherwise, and their arguments are late-bound Objects. The VBA documentation states that Load and Unload are Statements, even though the Object Browser shows them as Methods.
Keep in mind that you can move the order of references and it will make a difference. Try moving VBA to the top or near the top of your list of references. I believe that if something else also defines a BASIC keyword, it steals it, in a sense. I once had Right disappear and because I was not aware of the order of references, had to change all references of Right to VBA.Right. It's possibly the same with the ubound, lbound, or array.
I am programming in elisp, and I would like to associate a symbol with a function such that an attempt to access the variable instead calls the function. In particular, I want to trigger a special error message when lisp code attempts to access a certain variable. Is there a way to do this?
Example: suppose I want the variable current-time to evaluate to whatever (current-time-string) evaluates to at the time the variable is accessed. Is this possible?
Note that I do not control the code that attempts to access the variable, so that code could be compiled, so walking the tree and manually replacing variable accesses with function calls is not really an option.
You are looking for the Common Lisp define-symbol-macro.
Emacs Lisp lacks this feature, you cannot accomplish what you are trying to do.
However, not all is lost if you just want an error on accessing a variable.
Just makunbound it and access will error out (unless, of course, someone else nds it first).
I don't think you can do that.
As Sam says, define-symbol-macro would be the closest thing in Lisp (tho you make it sound like the accesses might be compiled beforehand, in which case even define-symbol-macro would be powerless). The closest thing in Elisp would be cl-symbol-macrolet, but that is even more limiting than define-symbol-macro since it has to be placed lexically around the accesses.
I'm working on an iOS app using C and Objective-C, and I want to write a very small piece of code that will be executed thousands of times from more than one place. Is it safe to make this an inline function and be sure that it will always be expanded (I won't ever be taking its address) or should I make it a macro? The code is small and it will be executed very frequently, so I'd like to make sure I won't end up with thousands of function calls for it, but still I'd like the type safety of the function approach if possible...
If you want to be sure that a function is inlined, make it "extern inline" (this is a GNU-C feature). Such functions are only used for inlining; the compiler will never generate a "real" function for it. Thus, if the inlining fails, you should be getting linker errors. I assume clang has "inherited" this feature.
In general, always use inline instead of macros, if possible. There's a reason why many C-compilers had it for ages, and C++ finally added it as a core feature; it makes things a lot safer and reliable to use. There are still things that need macros, but those are few and far between.
Yes, you should use an inline function over a macro.
The performance will be identical to a macro (the code is inline, after all) and you'll get type safety as well.
N.B., this assumes that your function is simple enough for the compiler to inline. gcc's -Winline option warns if this isn't the case; not sure what flags do the same on your platform.
Also see this post for cases when you might prefer a macro (e.g., deferred evaluation)--but based on your question it sounds like inline function is the clear choice.
I may be wrong, but I understand a compiler can only inline functions which are in the same source file. If your inline function is in file A and you're trying to use it elsewhere, it cannot be inlined, unless the linker does link-time optimization.
This is because the compiler only compiles one C file at a time into one object file. It cannot obtain the inlined function from another object file, because firstly, it may not yet have been compiled and secondly, it wouldn't know which object file to look for anyway.
In VB.NET, which is better to use: function overloading or default parameters?
if the parameters are optional (i.e. the overloads are a subset of the parameters that the full procedure signature accepts) then default or optional parameters would make more sense.
If the overload is allowing a different type for the parameter or is a semantically different parameter that will be interpreted differently by the routine then overloads would make more sense.
Is the code going to be used by other languages? If so, that swings the balance towards overloads while still bearing Hamish's answer in mind. In particular, C# doesn't support optional parameters - yet...
Admittedly this wouldn't actually prevent someone using your code from C#, it just might be a pain for them.
If there are a lot of parameters and they logically represent something, you might want to consider encapsulating them together, in the same way that Process works with ProcessStartInfo. That's particularly nice from C# due to object initializers.
If this is for construction, you might also consider the builder pattern as a variant of this. For instance, in Protocol Buffers I can do something like:
Person jon = new Person.Builder { Name="Jon", Age=32,
Spouse="Holly", Kids=3 }.Build();
which ends up being very readable while still creating a person in one go (in one expression, and without having to mutate the person itself - indeed the message type is immutable; it's only the builder which isn't).
FYI
If you want to add a parameter to a function or method that is called from other assemblies, then:
You can overload by making an additional function with the extra parameter.
Or you can add an optional parameter, BUT: You have to recompile all of the assemblies that call this function, even if they don't need to use the new optional parameter! This is not usually what people expect (expecially those used to how VB6 works). Basically, you can't slip in a new optional parameter to a function and expect it to be totally backwards compatible. Also, as I understand it, if you change what the default value is, you need to rebuild all calling assemblies for the change to work.