Posting for two reasons: (1) I was stuck on unhelpful compiler errors for far too long for such a simple issue and I want the next person to google those messages to come upon my (or other) answers, and (2) I still don't understand disallowing a use clause, so my own answer is really incomplete.
In order to call a program in two places with mostly the same arguments, I want to use the '&' to append to a default list inline:
declare
Exit_Code : constant Integer := GNAT.OS_Lib.Spawn (Program_Name => "gprbuild", Args => (Default_GPR_Arguments & new String'(File_Name_Parameter)));
begin
if Exit_Code /= 0 then
raise Program_Error with "Exit code:" & Exit_Code'Image;
end if;
end;
However, the compiler complains that System.Strings.String_List needs a use clause:
operator for type "System.Strings.String_List" is not directly visible
use clause would make operation legal
But inserting use System.Strings.String_List yields:
"System.Strings.String_List" is not allowed in a use clause
I also got this warning:
warning: "System.Strings" is an internal GNAT unit
warning: use "GNAT.Strings" instead
So I substituted GNAT for System in the with and the use clause and got an extra error in addition to the original 'you need a use clause for System.Strings.String_List' one:
"GNAT.Strings.String_List" is not allowed in a use clause
Why is GNAT.Strings.String_List not allowed in a use clause? Section 8.5 on use clauses doesn't seem to state anything on disallowed packages, so is this a compiler bug? Is it possible to define a new package that cannot have a use clause?
In a use clause of the form
use Name;
Name must be a package name. GNAT.Strings.String_List is a subtype name, not a package name.
There are a number of ways to invoke "&" for String_List. The simplest is to use the full name:
GNAT.Strings."&" (Left, Right)
but presumably you want to be able to use it as an operator in infix notation, Left & Right. Ways to achieve this, in decreasing specificity:
function "&" (Left : GNAT.Strings.String_List; Right : GNAT.Strings.String_List) return GNAT.Strings.String_List renames GNAT.Strings."&"; This makes this specific function directly visible.
use type GNAT.Strings.String_List; This makes all primitive operators of the type directly visible.
use all type GNAT.Strings.String_List; This makes all primitive operations of the type (including non-operator operations) directly visible.
use GNAT.Strings; This makes everything in the package directly visible.
Looks like it is a design decision. And many other packages in System follows this rule. From the s-string.ads (package specification for System.String):
-- Note: this package is in the System hierarchy so that it can be directly
-- be used by other predefined packages. User access to this package is via
-- a renaming of this package in GNAT.String (file g-string.ads).
My guess why this is done in that way: because it isn't in the Ada specification, but extension from GNAT.
Related
I am coding in R and due to stability purposes when I have to deploy something, I call every function with the syntax package::function(arguments) just to avoid conflicts that as you know may happen when using a lot of packages. It helped me a lot over the years.
I know that if is a reserved word so technically speaking it is impossible (or at least it should be in my knowledge) for someone to define an object and name it if.
I am also aware that it belongs to control flow statement (which I think are a different "thing") and due to the previous consideration I am also aware that the following questions might be useless. My pure technical doubts are:
Why if I embrace it in back-ticks the function class returns "function" as a result?
Why without back-ticks I get an error? and last but most important
Why I am unable to access it via the usual base::if() syntax?
As I said, most likely useless questions but at this point I am curious about the details underneath it.
> class(if)
Error: unexpected ')' in "class(if)"
> class(`if`)
[1] "function"
> base::if(T) T
Error: unexpected 'if' in "base::if"
> if(T) T
[1] TRUE
> base::if(`T`) T
Error: unexpected 'if' in "base::if"
if-with-backticks actually returns .Primitive("if")
The R language definition section on "Internal vs Primitive" specifies that .Primitive objects include
“Special functions” which really are language elements, but implemented as primitive functions:
{ ( if for while repeat break next
return function quote switch
The reason that a naked "if" without backticks or base::if don't work is that the "language elements" above are treated as special cases by R's parser. Once you have typed base::, R's parser expects the next symbol to be a regular symbol that can be looked up in the base namespace. base::if, base::for, and base::( all return errors because R does not expect these special elements to occur at this position in the input stream; they are syntactically incorrect.
I'm looking for idea on how to overwrite a function without modify the source. Like if I have foo() in the original source, I want to overwrite it with my own version with the same function name by adding it in a C file, which may also contains other overwrite functions. Sort of like strong/weak compilation. Currently I have to go in the source files and ifdef with __FRAMAC__. I don't want to touch the source files. Is there some kernel option to not use the second instance of foo() function?
Your question does not specify whether you want to replace a function declaration or a function definition. Since they are handled differently by Frama-C, I'm going to detail both.
Duplicate definitions at the kernel level
Currently, at the parsing level, there is no option in Frama-C to completely ignore the definition of a function that is present in one of the files given for parsing. The Frama-C AST will incorporate the definition of all functions it finds.
There is no exact equivalent for strong/weak symbols.
If a second definition for the same function is found, one of the following will happen:
If both definitions occur in the same compilation unit, there is an error.
If each definition happens in a different compilation unit, Frama-C will try to find a plausible solution:
If both occurrences have the same signature, Frama-C will emit a warning such as:
[kernel] b.c:2: Warning:
dropping duplicate def'n of func f at b.c:2 in favor of that at a.c:1
In this case, you just need to ensure the definition you want appears later in the list of sources to be parsed.
If the occurrences have different signatures, but one of the functions is never actually used, you may have a warning such as:
[kernel:linker:drop-conflicting-unused] Warning:
Incompatible declaration for f:
different number of arguments
First declaration was at a.c:1
Current declaration is at b.c:2
Current declaration is unused, silently removing it
However, if both occurrences are used, then you have an error:
[kernel] User Error: Incompatible declaration for f:
different type constructors: int vs. int *
First declaration was at a.c:1
Current declaration is at b.c:2
Duplicate declarations at the kernel level
Considering function declarations, Frama-C will, in accordance with the C standard, accept as many of them as are given, provided they are compatible. If they have ACSL specifications, those specifications will be merged.
Multiple incompatible declarations are handled as before, with warnings or errors depending on whether both versions are used (in which case Frama-C is unable to choose).
Plugin-specific options
Plug-ins may have specific options to override the default behavior of functions in the AST. For instance, Eva has option -eva-use-spec <fns>, which tells the analysis to ignore the definitions of functions <fns>, using only their specifications instead.
I get ERROR: LoadError: UndefVarError: Expression not defined for the following code:
struct IntLiteral
value::Int
end
struct Plus
left::Expression
right::Expression
end
struct Minus
left::Expression
right::Expression
end
const Expression = Union{IntLiteral, Plus, Minus}
If I declare Expression ahead of Plus and Minus, I get a similar error. Wrapping the code in a module doesn't change anything, either.
Is there a way to reference a type ahead of its declaration in Julia? If not, what is the recommended solution for cases like this, where two types depend on each other? Just remove the type annotations?
In this particular case, I believe I could make Expression an abstract type, and have the others be subtypes of it. Is that recommended in this case? What about the general case?
Not currently, no. See issue #269 for more details.
I have just started using Ada, and I'm finding the generic package declarations to be rather silly. Maybe I'm not doing it right, so I'm looking for better options.
Take a look at the below example.
package STD_Code_Maps is new
Ada.Containers.Map(Key_Type => STD_Code_Type;
Element_Type => Ada.Strings.Unbounded.Unbounded_String);
STD_Code_Map : STD_Code_Maps.Map;
-- . . .
procedure Do_Something is
Item : Ada.Strings.Unbounded.Unbounded_String;
begin
Item := STD_Code_Maps.Element(STD_Code_Maps.First(STD_Code_Map));
-- Do something with the Item
-- . . .
end Do_Something;
It would be much cleaner to simply be able to write STD_Code_Map.First.Element instead of the godforsaken STD_Code_Maps.Element(STD_Code_Maps.First(STD_Code_Map));
Obviously I'm doing this wrong -- I think. I'm repeating the phrase STD_Code_Map at least thrice over there. I'm all for verbosity and everything, but really the code I'm writing seems bad and silly to me.
I was wondering if there is solution that doesn't require you to rename the package to something like package Map renames STD_Code_Maps; which would of course shorten the code but I don't want to do this on each and every procedure entry. I really think something like STD_Code_Map.First.Element would be much simpler. Can this be done in Ada 2012?
Note: Using the Unbounded_String package by default is also so difficult. Did the standard library designers actually give much thought to the ridiculous and overly long package hierarchy?
Thanks for reading this, and potentially helping me out. I'm new to Ada.
GNAT GPL 2012 and 2013, and FSF GCC 4.7 and 4.8, support the new container indexing scheme of Ada 2012, which means that you can write
Item := STD_Code_Map ({some Cursor});
And you can do this even with the -gnat05 switch to force Ada 2005 mode! (which has to be a bug).
Ada 2005 allows you to call a primitive function of a tagged type using object.function notation, provided that the first operand is of the tagged type; so you can write STD_Code_Map.First as shorthand for STD_Code_Maps.First (STD_Code_Map).
Putting these together, you can write
Item := STD_Code_Map (STD_Code_Map.First);
which is quite short!
The issue has nothing to do with generics. As Simon pointed out, you can say STD_Code_Map.First, since the type of STD_Code_Map is a tagged type and Ada supports this notation for tagged types. On the other hand, the type of STD_Code_Map.First is a Cursor type, which isn't tagged (making it tagged would have caused problems declaring certain operations that take both a Cursor and a Map). But even without the Ada 2012 container indexing that Simon mentioned, you can say
STD_Code_Maps.Element(STD_Code_Map.First);
which is a little better. Besides renaming a package, you can also rename the function:
function Elem (Position : STD_Code_Maps.Cursor) return STD_Code_Maps.Element_Type
renames STD_Code_Maps.Element;
and you can now use just Elem instead of STD_Code_Maps.Element wherever the renaming is directly visible. (You could call it Element if you want to. The renaming name can be the same or it can be different.) This could be helpful if you use that function a lot.
Ada was designed for readability and maintainability. (written once, read & maintained for much longer) This means that it does get a little verbose at times. If you prefer terse & cryptic there are plenty of other languages out there !
If you want to avoid typing STD_Code_Map all the time, just use a use clause:
use STD_Code_Map;
which would mean your code of
Item := STD_Code_Maps.Element(STD_Code_Maps.First(STD_Code_Map));
would become
Item := Element(First(STD_Code_Map));
Getting names nice and readable in Ada can sometimes be tricky. Often times language designers made the task worse than it had to be, by designing Ada standard library packages for use with Ada use clauses, without a thought to how they'd look to some poor sap who either can't or doesn't want to use that feature.
In this case though, there are things you can do on your own end.
For example "_Maps.Map" is redundant, so why not get rid of it from the package name? Why not use names so that you can write:
package STD_Code is new
Ada.Containers.Map(Key_Type => STD_Code_Type;
Element_Type => Ada.Strings.Unbounded.Unbounded_String);
Map : STD_Code.Map;
-- . . .
procedure Do_Something is
Item : Ada.Strings.Unbounded.Unbounded_String;
begin
Item := STD_Code.Element(STD_Code.First(Map));
-- Do something with the Item
-- . . .
end Do_Something;
Now Code looks like a bit of a null-meaning word too. Everything in a program is a code. So I'd consider ditching it as well. Unsually I name my Ada container packages something that says their basic theoretical function (eg: STD_to_String), while objects are more specific nouns.
Also, I should point out that if your map is constant and you can live with names that look like identifiers, often times you can get rid of maps to strings entirely by using an enumerated type and the 'image attribute.
If you're using Ada 2012 the STD_Code_Maps.Element(STD_Code_Maps.First(STD_Code_Map)); could become:
Function Get_First( Map : STD_Code_Maps.Map ) return Unbounded_String is
( STD_Code_Maps.Element(Map.First) );
That is an example of the new Expression-functions, which were mainly introduced for pre- and post-conditions.
Of course, if you're using Ada 2012 then the precise map you'd likely want is Ada.Containers.Indefinite_Ordered_Maps -- the Indefinite_* containers are those that [can] have indefinite elements, like String.
In addition to TED's comment, using an enumeration when the maps are constant have even more advantages, namely case coverage: the compiler will flag as an error any case-statement that doesn't cover all alternatives. So if you add a new code it will flag all the case-statements that you need to modify. (Of course this benefit is lost when you use the others case.)
I try to evaluate a field in my report but it fails every time :
= IIf(Fields!lectcrs_hrs.IsMissing,
Round(Fields!lectcrs_fee.Value * "1.00", 2),
Round(Fields!lectcrs_fee.Value * Fields!lectcrs_hrs.Value, 2))
in the case of Fields!lectcrs_hrs.IsMissing = true my field is empty and i find that the reason that the second case Round(Fields!lectcrs_fee.Value * Fields!lectcrs_hrs.Value, 2) contains a missing field Fields!lectcrs_hrs .why it checks the second case if it passes the first one !
How to fix this problem ?
The behavior you are looking for is called "short-circuiting" and, unfortunately, the IIf function in Visual Basic does not offer that. The reason being is that IIf() is a ternary function and, as such, all arguments passed into it are evaluated before the function call occurs. A ternary operator (If() in VB 9+), on the other hand, does support conditional evaluation. However, I do not believe that the If() operator can be used as a part of an expression in SSRS.
Given the fact that you are trying to use a field which may or may not exist at run time, I suggest that you create a custom function in your report to handle the proper checking and return values. For reference, take a look at this blog post, which covers the same scenario.