Using MarkLogic Xquery, I have a function (admin:add-collection-to-publication) which calls another maintenance function ( admin:check-collections-exists) which checks for an element's presence and if its not present then it creates that particular element.
The way I call the maintenance function is with a let. This seems like a weird way, to do this it requires creating an unused variable. Should I instead return a sequence with the call to admin:check-collections-exists being the first item in the sequence then the subsequent processing being the second element? Just looking for the standard elegant way to do this. My functions are:
declare function admin:add-collection-to-publication($pub-name, $collection-name)
{
(:does this publication have a COLLECTIONS element?:)
let $unnecessary-variable := admin:check-collections-exists($pub-name)
(:now go and do what this function does:)
return "do some other stuff then return"
};
declare function admin:check-collections-exists($pub-name)
{
if(fn:exists($pubs-node/pub:PUBLICATION[pub:NAME/text()=$pub-name]/pub:COLLECTIONS))
then
"exists"
else
xdmp:node-insert-child($pubs-node/pub:PUBLICATION[pub:NAME/text()=$pub-name],<pub:COLLECTIONS/>)
};
Using a sequence is not reliable. MarkLogic will most likely attempt to evaluate the sequence items in parallel, which could cause the creating to happen at 'same' time or even after the other work. The best approach is indeed to use a let. The let's are always evaluated before the return. Note though that let's can be evaluated in parallel as well, but the optimizer is smart enough to detect dependencies.
Personally, I often use unused variables. For example to insert logging statements, in which case I have one unused variable name that I reuse each time:
let $log := xdmp:log($before)
let $result := do:something($before)
let $log := xdmp:log($result)
You could also use a very short variable name like $_. Or you could reconsider actually giving the variable a sensible name, and use it after all, even though you know it never reaches the else
let $exists :=
if (collection-exists()) then
create()
else true()
return
if ($exists) then
"do stuff"
else () (: never reached!! :)
HTH!
Related
To be fair, I cannot be entirely sure the title correctly describes the problem I am having, as it merely mirrors my current understanding of Ada as it is.
The Problem
I have a function:
function Make_Option (Title : String) return Access_Option is
O : aliased Option := (
Title_Len => Title'Length,
Title => Title);
begin -- Make_Option
return O'Unrestricted_Access;
end Make_Option;
This function is supposed to create a new menu option for the user, that may in turn be inserted into a menu (one that you might see in a terminal-based environment). You are all probably sighing, as quite evidently, the O variable would be deallocated at the end of this function (from my current understanding). As such, using the Unrestricted_Access here is just plain stupidity, but it mirrors the result of what it is I am trying to accomplish (as this code indeed does compile successfully).
The Access_Option is defined as following:
type Access_Option is access all Option;
The idea is that with an access to the option, which in turn is a discriminated record, is that we can store it within an array-like structure (as the object itself varies in size).
Beyond doubt, it would be nice if we could instead use the Access attribute for this, as the compiler would then make sure the lifetime is long enough of the O variable we are referencing, but as the lifetime as a matter of fact only exists til the end of the Make_Option function, we are presented with the following:
non-local pointer cannot point to local object
What I am then asking, is: how would I go about having a function to create Access_Options for me? Is such a thing even possible, or am I doing it all wrong? To clarify, what I am trying to do is create a neat way for filling an array with references to discriminated records, that I can then dereference and use.
Thought Process
I personally have not tried too many things, more than think about solutions that may be plausible for the problem. And, frankly, rather than going crazy of working makeshift solutions, it would be nice to have a solution that works for large-scale applications too, without messing up the code base to bad.
Would you perhaps have some sort of object queue to handle it? Does Ada even deallocate resources automatically in the first place? Gah. I am confused.
Would it, in fact, be possible to somehow place the O variable outside of the scope for deallocation to then manually deallocate it later?
Given the example you show above a much simpler approach is to simply make an array of Unbounded_String:
with Ada.Strings.Unbounded; use Ada.Strings.Unbounded;
with Ada.Text_IO; use Ada.Text_Io;
procedure Str_Arrays is
type Arr is array(1..10) of Unbounded_String;
A : Arr;
begin
for S of A loop
S := To_Unbounded_String("Hello World!");
end loop;
for S of A loop
Put_Line(To_String(S));
end loop;
end Str_arrays;
Don't try that.
There are two alternative options:
1) Use Ada.Containers.Indefinite_Vectors instead of a plain array.
2) Give your record discriminant a default value. Then you can store it in a plain array.
You seem to be reinventing the bounded string. Alternatives include
Using an instantiation of Ada.Strings.Bounded.Generic_Bounded_Length
Using Ada.Strings.Unbounded
Using an indefinite container (Ada.Containers.Indefinite_*) to hold type String
I am trying to implement a set of functions in go. The context is an event server; I would like to prevent (or at least warn) adding the same handler more than once for an event.
I have read that maps are idiomatic to use as sets because of the ease of checking for membership:
if _, ok := set[item]; ok {
// don't add item
} else {
// do add item
}
I'm having some trouble with using this paradigm for functions though. Here is my first attempt:
// this is not the actual signature
type EventResponse func(args interface{})
type EventResponseSet map[*EventResponse]struct{}
func (ers EventResponseSet) Add(r EventResponse) {
if _, ok := ers[&r]; ok {
// warn here
return
}
ers[&r] = struct{}{}
}
func (ers EventResponseSet) Remove(r EventResponse) {
// if key is not there, doesn't matter
delete(ers, &r)
}
It is clear why this doesn't work: functions are not reference types in Go, though some people will tell you they are. I have proof, though we shouldn't need it since the language specification says that everything other than maps, slices, and pointers are passed by value.
Attempt 2:
func (ers EventResponseSet) Add(r *EventResponse) {
// ...
}
This has a couple of problems:
Any EventResponse has to be declared like fn := func(args interface{}){} because you can't address functions declared in the usual manner.
You can't pass a closure at all.
Using a wrapper is not an option because any function passed to the wrapper will get a new address from the wrapper - no function will be uniquely identifiable by address, and all this careful planning is for nought.
Is it silly of me to not accept defining functions as variables as a solution? Is there another (good) solution?
To be clear, I accept that there are cases that I can't catch (closures), and that's fine. The use case that I envision is defining a bunch of handlers and being relatively safe that I won't accidentally add one to the same event twice, if that makes sense.
You could use reflect.Value presented by Uvelichitel, or the function address as a string acquired by fmt.Sprint() or the address as uintptr acquired by reflect.Value.Pointer() (more in the answer How to compare 2 functions in Go?), but I recommend against it.
Since the language spec does not allow to compare function values, nor does it allow to take their addresses, you have no guarantee that something that works at a time in your program will work always, including a specific run, and including different (future) Go compilers. I would not use it.
Since the spec is strict about this, this means compilers are allowed to generate code that would for example change the address of a function at runtime (e.g. unload an unused function, then load it again later if needed again). I don't know about such behavior currently, but this doesn't mean that a future Go compiler will not take advantage of such thing.
If you store a function address (in whatever format), that value does not count as keeping the function value anymore. And if no one else would "own" the function value anymore, the generated code (and the Go runtime) would be "free" to modify / relocate the function (and thus changing its address) – without violating the spec and Go's type safety. So you could not be rightfully angry at and blame the compiler, but only yourself.
If you want to check against reusing, you could work with interface values.
Let's say you need functions with signature:
func(p ParamType) RetType
Create an interface:
type EventResponse interface {
Do(p ParamType) RetType
}
For example, you could have an unexported struct type, and a pointer to it could implement your EventResponse interface. Make an exported function to return the single value, so no new values may be created.
E.g.:
type myEvtResp struct{}
func (m *myEvtResp) Do(p ParamType) RetType {
// Your logic comes here
}
var single = &myEvtResp{}
func Get() EventResponse { return single }
Is it really needed to hide the implementation in a package, and only create and "publish" a single instance? Unfortunately yes, because else you could create other value like &myEvtResp{} which may be different pointers still having the same Do() method, but the interface wrapper values might not be equal:
Interface values are comparable. Two interface values are equal if they have identical dynamic types and equal dynamic values or if both have value nil.
[...and...]
Pointer values are comparable. Two pointer values are equal if they point to the same variable or if both have value nil. Pointers to distinct zero-size variables may or may not be equal.
The type *myEvtResp implements EventResponse and so you can register a value of it (the only value, accessible via Get()). You can have a map of type map[EventResponse]bool in which you may store your registered handlers, the interface values as keys, and true as values. Indexing a map with a key that is not in the map yields the zero value of the value type of the map. So if the value type of the map is bool, indexing it with a non-existing key will result in false – telling it's not in the map. Indexing with an already registered EventResponse (an existing key) will result in the stored value – true – telling it's in the map, it's already registered.
You can simply check if one already been registered:
type EventResponseSet map[*EventResponse]bool
func (ers EventResponseSet) Add(r EventResponse) {
if ers[r] {
// warn here
return
}
ers[r] = true
}
Closing: This may seem a little too much hassle just to avoid duplicated use. I agree, and I wouldn't go for it. But if you want to...
Which functions you mean to be equal? Comparability is not defined for functions types in language specification. reflect.Value gives you the desired behaviour more or less
type EventResponseSet map[reflect.Value]struct{}
set := make(EventResponseSet)
if _, ok := set[reflect.ValueOf(item)]; ok {
// don't add item
} else {
// do add item
set[reflect.ValueOf(item)] = struct{}{}
}
this assertion will treat as equal items produced by assignments only
//for example
item1 := fmt.Println
item2 := fmt.Println
item3 := item1
//would have all same reflect.Value
but I don't think this behaviour guaranteed by any documentation.
I understand what recursive functions are, but consider the following example of a function meant to get the local version of data on an item, check if there is new data about it available online based on locally stored cache time, and if there is, updating the local data with the new version, returning up-to-date data about it either way.
function getItemData(id){
var local=getLocalItemData(id);
if(!local.cacheTime.upToDate()){
var newData=getOnlineItemData(id);
updateLocalItemData(id, newData);
return getItemData(id);
}
else{
return local.returnHumanReadable();
}
}
My argument against considering it a recursive function is the fact that it will only end up calling itself on rare occasions when the cache time indicates the data has expired, and that the function only calls itself for convenience.
Instead of using return getLocalItemData(id).returnHumanReadable(); I can use return getItemData(id); because it will return the same result, as the newly saved data won't need to be refreshed again in the several microseconds it will take the function to call itself. Also, it is much shorter: in the actual code, I would use lower level commands instead of those function calls, resulting in code duplication which would make the entire function harder to read and maintain.
So, do you think that my argument makes any sense, or do you consider this to be nothing more than a matter of code organization?
The short answer is: yes it is recursive
It becomes important if you consider a platform that does not support recursion
Since it can call itself, your code will not work on that platform because it is technically recursion
For a trivial case like this replacing the recursive call with getLocalItemData(id).returnHumanReadable(); will allow it to work on this platform. In fact, you can change your code to:
function getItemData(id){
var local=getLocalItemData(id);
if(!local.cacheTime.upToDate()){
var newData=getOnlineItemData(id);
updateLocalItemData(id, newData);
local=getLocalItemData(id);
}
return local.returnHumanReadable();
}
NOTE: If you cannot 100% guarantee that only one call is needed, change the if to while
Why do I see return() at the end of an XQuery query?
e.g.
let $updateIssues:=
for $issue in fn:collection("InProgress_Audit")/ProductIssue
return local:UpdateIssue($issue)
return ()
It's not entirely clear what your question is. Given the way you've formulated it, possible answers include:
You see it because it's there.
You see it because someone typed it when they wrote the query.
Perhaps you mean 'why is it there?' Possible answers include:
It's there because without a return clause the FLWOR expression begun by the let clause is not complete.
It's there because the author of this query has a quirky sense of humor, and thought a four-line query was an amusing way to write an expression denoting the empty sequence (which can be more concisely written ()).
It's there because the author of the query wants you as a reader to know he'd really rather be writing C or Java or, really, any other programming language.
It's there because the author of the query finds it amusing that the return keyword in XQuery can be written to look like a function call. (The author may enjoy hazing newbies and practical jokes, too; approach with caution.)
Perhaps you mean "what does this query mean and how does it mean it?" Possible answers include:
The query returns the empty sequence.
The query takes the form of a FLWOR expression which defines a binding for the variable updateIssues (whose value is given by a nested FLWOR expression), and then returns () (that is, the empty sequence). Since nothing in the return clause depends on the value of updateIssues, there is no need for an XQuery engine to evaluate the expression used to specify the value (but there is also no guarantee that it won't do so -- processors are allowed to be smart about optimization but not required to be).
In your example, the return () expression is the body of your let expression.
The assignment to $updateIssues is walking through a bunch of nodes, returning the value from a call to local:UpdateIssue(), and the sequence of those return values is being used as the variable value.
But, then, nothing is done with the variable and the function simply returns nothing to its caller.
I would be worried that an optimizing processor may choose to throw out the assignment because the variable being assigned isn't being used anywhere, but the processor you are using is likely not doing that if you are getting the update results you are expecting.
So, all that last line is doing is always returning an empty sequence as the value of the function when called.
If I get your question right you are asking about return ().
return () means that you are returning a blank so in short you just want to assign the global variable to something and do not want to return anything from the function.
Else if you want to know the details on Return expression. It is a Part of XQuery FLWOR Expressions.
Being a functional language XQuery works on Functions.
For Loop, Let Loop, Where, Order By (FLWO) are all internally (inside XQuery Engine) acting as functions. Thus they all require a return after call to specify what needs to be the output from them.
If you require more information on XQuery functions you may refer the offical documentation.
I have a variable in a package (rec in this case) that needs to be set when called from package 3, but it's private. Previously the function set_true only set rec to true, so it wasn't a big deal. But I have another package that does the same processing (I'm giving a simple example, but my literal case is more complex), so I thought, well I could pass in the variable I want modified, and let it get changed. Is the only way to set rec in the below layout, to create a second function in package one, that calls set_true with rec as the parameter? I would like to avoid having to keep creating additional functions to handle the local variables. I can't move the variable to public (spec) as I am trying to follow convention and this "type" of variable isn't public anywhere else, and I don't want anyone to be able to just set it on their own (I want functions to have to set). I don't want to have to create a second function named for example set_local_true, and creating an overloaded function set_true, with no parameters, that calls set_true(value => rec) just seems deceptive, does anyone have any better suggestions with the limitations I have?
My two requirements:
Can't make the local variable public.
Be able to use the function to calculate something both externally and internally.
package one is
procedure set_true(value : out Boolean);
end one;
package body one is
rec : Boolean;
begin
procedure set_true(value : out Boolean)
begin
value := true;
end set_true;
end one;
package body two is
local_rec : Boolean;
begin
procedure call_function is
begin
one.set_true(value => local_rec);
end call_function;
end two;
package body three is
begin
procedure call_function is
begin
one.set_true(value => <PACKAGE ONE'S REC))
end call_function;
end three;
EDIT: Or perhaps, what would be a better naming convention for the functions to specify that they are modifying the variable that is local to that package? Set_Local_True again is deceptive cause if you call it from package 3, you're not setting your local true, you're setting package one's local to true....
First off, this is very silly code. I'll assume it is shorthand for something else. But as presented, I can assure you that your clients can set their own booleans themselves without you writing a routine to do it for them. In fact, they can do it better. For the remainder of this answer, I'll assume you aren't acutally writing variables to set booleans for people, but rather doing something of actual use. If not, ignore the rest of this answer and just delete your silly routines.
Secondly, if you are creating a routine with a single out parameter, then unless the object happens to be very large, you should probably make it a function instead. That will allow your clients to use functional programming if they chose. The way you have it, the poor coder has to stop and create a special variable just to call your routine, even if they only want to do it once.
Thirdly, rather than using a unique set routine for each state, I generally prefer to pass in the requested state.
function Set_Frobnost (New_State : boolean := true) return boolean;
If the state is really and truly boolean (no possible third state in the future), then it is debateable. However, it can be a big advantage to your client if they might already have to store the state in a variable (or loop through it).
Your edit about naming shows me you are on the right track.
You should do one of two things here.
Find the higher-level concept controlled by that variable, and name the "setter" routine after that.
Get the hell out of the way and put the flag variable in the pacakge spec.
If you have to access private variables, you might to do it in a child package.
package One is
procedure Foo (X : Boolean);
private
One_Private : Boolean;
end One;
and then
package body One.Two is
procedure Bar is
One.Foo (One.One_Private);
end Bar;
end One.Two;
Elements in the "private" part of a package are like "protected" entities in C++/Java. Truly private variables (only in package body) are not accessible from anywhere else.