In the natural number game, the use keyword resolves goals which contain existential quantifiers by assigning a concrete value to the quantified variable. Using Lean by itself it looks like use isn't available; what do you do instead?
You can use existsi, but in general the recommendation is to avoid using Lean by itself; mathlib should always be used as well. Set up your project as documented here then write import tactic at the top of your .lean file to get access to the use tactic.
Let's say I have class A with associations to classes X, Y, and Z, respectively. I need to indicate that only one of these associations may be instantiated for any given instance of class A (so, an xor constraint). I know how to do this if the constraint is just across two associations. Obviously I can just make three seperate xor constraints (X-Y, X-Z, Y-Z) but I'm wondering if there is a better/cleaner/proper way to do it?
edit: The multiplicity constraints on the respective associations are not the same. Using an abstract class or interface will not work. Furthermore, a note is insufficient. I need to use some sort of formalized structure, preferably something standardized (e.g. by OMG) to express this because I am programmatically processing the model elements (i.e. it isn't just a picture). I understand how the underlying model for UML provides for this facility. It also specifies (though slightly vaguely) how it should be notated. I guess my main issue is, in fact, with finding a tool that allows me to make that notation. I don't think MagicDraw does so. I should have stated these things earlier.
FWIW, I'm using MagicDraw. It would be a nice bonus if the I could do this in a way that MagicDraw actually understood. I can live with it if that isn't possible.
The xor constraint is just a stylized and rather under-specified constraint for the 2-way case.
You can define an explicit constraint (in Complete OCL) as:
context A
inv OnlyAorBorC: A->size() + B->Size() + C->size() <= 1
MagicDraw may allow you to specify a similar contextual Constraint on A.
If "X", "Y" and/or "Z" can be somehow generalized (I mean, if you not doing this puraly for a conditional flow control), you can make an interface (or and abstract class) "I" for example, and make "X", "Y" and "Z" implement this interface. Then, you put an association with multiplicity 1 between A and the interface I.
See the diagram below:
Edit: The example above doesn't work in the case of A having different cardinalities between X, Y and Z. For this case, the only way that I can see is use an UML Constraint to restrict those relationships. You can define a Constraint in UML putting some OCL expression between curly braces. E. g.
Here, account owner is either Person or Corporation and this {xor} is predefined UML constraint.
I'm not sure about the details of your cardinalities requirements but, a combination between this {xor} and the interface example that I gave might be enough. At least it gives you a little bit more of options, like:
If you need to know more about the UML constraints subject, I got this example from uml-diagrams.org: http://www.uml-diagrams.org/constraint.html
If you have ever worked with the metamodel of UML, you propably know the concepts of unions and subsets - As far as I understand it:
Attributes and associations of an element/class marked as "derived union" cannot be used directly. In more specific sub-classes, you can possibly find subsets of them that can be used, as long as they are not marked as derived unions themselves.
"derived" (without union) attributes and associations have also subsets in more specific classes, but unlike above you can use them directly without having to look for subsets in more specific classes
My questions:
Does this make sense or am I on the wrong track here?
What is the meaning of the "/" (slash) you can find in front of some
attributes/associations, that they have subsets in child-classes?
E.g. /general : Classifier[*]
An union property is a property that consists of multiple other properties. You can only understand the union, when you combine all subsets. A list is almost by definition an union.
Almost, because it might be uninitialized.
A derived union is a property requiring a specific collection of subsets. I would not talk about accessing them directly, but about how direct you can understand them. You need all information before you can make an interpretation.
The difference between the two that a derived union requires a specific subset and an union might have a subset and might have different subsets in different contexts. A very simple example being the fields on a form. All required fields show the definition of a derived union. All other fields are part of the complete union.
Derived unions can contain derived unions in their subsets. It directs the creation of classes and their instances, it does not make them impossible.
All derived features require other features to be known. Temperature can be read directly, but to know if someone has fever requires more knowledge, like the time of the day, the place of collecting information etc..
The slash implies that it is being derived.
First-class value can be
passed as an argument
returned from a subroutine
assigned into a variable.
Second-class value just can be passed as an argument.
Third-class value even can't be passed as an argument.
Why should these things defined like that? As I understand, "can be passed as an argument" means it can be pushed into the runtime stack;"can be assigned into a variable" means it can be moved into a different location of the memory; "can be returned from a subroutine" almost has the same meaning of "can be assigned into a variable" since the returned value always be put into a known address, so first class value is totally "movable" or "dynamic",second class value is half "movable" , and third class value is just "static", such as labels in C/C++ which just can be addressed by goto statement, and you can't do nothing with that address except "goto" .Does My understanding make any sense? or what do these three kinds of values mean exactly?
Oh no, I may have to go edit Wikipedia again.
There are really only two distinctions worth making: first-class and not first-class. If Michael Scott talks about a third-class anything, I'll be very depressed.
Ok, so what is "first-class," anyway? Well, it is a term that barely has a technical meaning. The meaning, when present, is usually comparative, and it applies to a thing in a language (I'm being deliberately vague here) that has more privileges than a comparable thing. That's all people mean by it.
Let's look at some examples:
Function pointers in C are first-class values because they can be passed to functions, returned from functions, and stored in heap-allocated data structures just like any other value. Functions in Pascal and Ada are not first-class values because although they can be passed as arguments, they cannot be returned as results or stored in heap-allocated data structures.
Struct types are second-class types in C, because there are no literal expressions of struct type. (Since C99 there are literal initializers with named fields, but this is still not as general as having a literal anywhere you can use an expression.)
Polymorphic values are second-class values in ML because although they can be let-bound to names, they cannot be lambda-bound. Therefore they cannot be passed as arguments. But in Haskell, because Haskell supports higher-rank polymorphism, polymorphic values are first-class. (They can even be stored in data structures!)
In Java, the type int is second class because you can't inherit from it. Type Integer is first class.
In C, labels are second class, because they don't have values and you can't compute with them. In FORTRAN, line numbers have values and so are first class. There is a GNU extension to C that allows you to define first-class labels, and it is jolly useful. What does first-class mean in this case? It means the labels have values, can be stored in data structures, and can be used in goto. But those values are second class in another sense, because a label from one procedure can't meaningfully be used in a goto that belongs to another procedure.
Are we getting an idea how useless this terminology is?
I hope these examples convince you that the idea of "first-class" is not a very useful idea in thinking about programming languages overall. When you're talking about a particular feature of a particular language or language family, it can be a useful shorthand ("a language isn't functional unless it has first-class, nested functions") but by and large you're better off saying just what you mean instead of talking about "first-class" or "not first-class" things.
As for "third class", just say no.
Something is first-class if it is explicitly manipulable in the code. In other words, something is first-class if it can be programmatically manipulated at run-time.
This closely relates to meta-programming in the sense that what you describe in the code (at development time) is one meta-level, and what exists at run-time is another meta-level. But the barrier between these two meta-levels can be blurred, for instance with reflection. When something is reified at run-time, it becomes explicitly manipulable.
We speak of first-class object, because objects can be manipulated programmatically at run-time (that's the very purpose).
In java, you have classes, but they are not first-class, because the code can normally not manipulate a class unless you use reflection. But in Smalltalk, classes are first-class: the code can manipulate a class like an regular object.
In java, you have packages (modules), but they are not first-class, because the code does not manipulate package at run-time. But in NewSpeak, packages (modules) are first-class, you can instantiate a module and pass it to another module to specify the modularity at run-time.
In C#, you have closures which are first-class functions. They exist and can be manipulated at run-time programmatically. Such things does not exists (yet) in java.
To me, the boundary first-class/not first-class is not exactly strict. It is sometimes hard to pronounce for some language constructs, e.g. java primitive types. We could say it's not first-class because it's not an object and is not manipulable through a reference that can be passed along, but the primitive value does still exists and can be manipulated at run-time.
PS: I agree with Norman Ramsey and 2nd-class and 3rd-class value make no sense to me.
First-class: A first-class construct is one which is an intrinsic element of a language. The following properties must hold.
It must form part of the lexical syntax of the language
It may have operators applied to it
It must be referenceable (for example stored in a variable)
Second-class: A second-class construct is one which is an intrinsic element of the language with the following properties.
It must form part of the lexical syntax of the language
It may have operators applied to it
Third-class: A third-class construct is one which forms part of the syntax of a language.
in
Roger Keays and Andry Rakotonirainy. Context-oriented programming. In Pro- ceedings of the 3rd ACM International Workshop on Data Engineering for Wire- less and Mobile Access, MobiDe ’03, pages 9–16, New York, NY, USA, 2003. ACM.
Those terms are very broad and not really globally well defined, but here are the most logical definitions for them:
First-class values are the ones that have actual, tangible values, and so can be operated on and go around, as variables, arguments, return values or whatever.
This doesn't really need a thorough example, does it? In C, an int is first-class.
Second-class values are more limited. They have values, but they can't be used directly, so the compiler deliberately limits what you can do with it. You can reference them, so you can still have a first-class value representing them.
For example, in C, a function is a second-class value. It can't be altered, but it can be called and referenced.
Third-class values are even more limited. They not only don't have values, but interaction is completely absent, and often it only exists to be used as compile-time attributes.
For example, in Rust, a lifetime is a third-class value. You can't use the lifetime at all. You can only receive it as a template parameter, you can only use it as a template parameter (only when creating a new variable), and that's all you can do with it.
Another example, in C++, a struct or a class is a third-class value. This doesn't need much explanation.
If I design a new language with type inference, no explicit types and no class inheritance support and then want to add inheritance, what are the minimum extra hints to the compiler needed to resolve type ambiguity when adding the feature?
Are class names needed?
EDIT
The type-tainting is traced through assignments throughout the program including between functions.
OK in the starting language, you have class names like MyTypeName1 from stuff like:
myVariable1 = New(MyTypeName1)
myVariable2 = New(MyTypeName2)
And types MyTypeName1 and MyTypeName2 are inferred for myVariable1 and myVariable2 respectively. But then if we want to enhance the language to support:
MyVariable3 = myVariable1
MyVariable3 = myVariable2
which can be traced through the code (myVariable3 now can contain two types which presumably are in a hierarchy).
EDIT
The members of MyTypeName1 and MyTypeName2 are inferred from statements like:
myVariable1.name="Fred"
myVariable2.name="JX3009"
What if the name member in MyTypeName1 and in MyTypeName2 are not to be in a common base class? What if we want a different name property in MyTypeName1 and MyTypeName2 and none in a base class? Is there an elegant way to tell the compiler what to do / how to handle? (The idea with type inference is to reduce typing not increase it...?)
Or do we need to specify the hierarchy explicitly?
This field is loaded with undecidability results, but I've forgotten them all. If you're willing to conflate inheritance with subtyping, then you have no problems. If you want something more ambitious (and it sounds as if you do), I'd have a look at
Benjamin Pierce's textbook Types and Programming Languages, which will cover the basic results for width and depth subtyping and how they do or do not play nicely with type inference. (I'd look myself but my copy is at work.)
François Pottier's PhD dissertation.
Another name to check out is Joe Wells, who's been responsible for a lot of undecidability results in type systems and programming languages.
What are the minimum extra hints to the compiler needed to resolve type ambiguity?
If there is a unique answer to this question, I will be very surprised. I think it far more likely that this is one of those language-design problems where there are a bunch of solutions which are strictly incomparable as far as minimality and annotations go.