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.
Related
Although you can actually itemize any kind of data structure to fit it into a scalar variable, sigilless variables might have some intrinsic value, since they are actually shapeless, to be used as class attributes. However, there seems to be no way to do so, has \.a does not work, has .\a either. A has $!a can probably cover most of what we could achieve with sigilless variables, but would there be an actual way to use them as attributes?
There's currently no way to have a sigilless attribute. It's also not, so far as I'm aware, currently under active consideration for inclusion in a future Raku version. The most obvious design considerations, were it to be proposed, would be:
The semantics of my \foo = ... are single static assignment. It's quite clear what that means on a lexically scoped symbol. It's less clear what it would mean in a class declaration, and how it would interact with the instantiation workflow. For example, there'd be no equivalent of the :$!foo signature syntax that can be convenient in BUILD/TWEAK.
The use of a twigil implies that it follows a sigil. The twigils without that are potentially ambiguous, depending on context. Further, it'd be odd to allow the . case only for the purpose of declaring that we want a sigilless attribute to get an accessor.
It would break the rule that you can always find access to the instance state by looking for a ! twigil, which would be a pity.
For background, I'm working on a CSG (Constructive Solid Geometry) library.
Given polygon meshes that enclose regions of space, this library will allow those meshes to be treated as sets of the points that they enclose. And also allow the calculation of the binary operations, union, intersection and difference, on pairs of meshes.
The library will also support set negation.
If required I could also define an elem like function, with type Point -> Mesh -> Bool, it would not be possible to define an add function, as there exists no meaningful way to add a single point to a mesh.
Does a typeclass exist for types that support these operations?
And if not, what would a good implementation of a suitable typeclass look like?
Many people have tried making unifying typeclasses for container types, and none of them has ever caught on, each for its own reasons. I recommend not bothering; the current standard idiom is to just define the operations for your new type with some standardish names, not worrying about name clashes, with whatever type makes the most sense for your new container. Expect users to import your module qualified and aliased to avoid name clashes (and aid readers as a nice side effect).
I have an algebraic data type that's being used all thoughout my program. I've realized that there's a point when I need to annotate all my structures of that type with a simple string.
I would like to not go through tons of code to account for adding a field to my commonly used type. Especially since there's no meaningful value for this annotation until quite far in my program, it seems excessive to refactor a thousand lines of code for a trivial change.
Also, as the type is pretty complex, it seems silly to just duplicate the type and make a slightly different version.
Is this just a weakness of Haskell, or am I missing the right way to handle this? I assume it's the latter, but I can't find anything akin to optional parameters to a type constructor.
I wouldn't go as far as declaring "a weakness of Haskell" - more like something that's needed to take into account when dealing with ADTs (and not specifically in Haskell).
Each program consists of "entities" and "actions". Your problem is that you need to modify an entity (an ADT in Haskell).
In an OOP language the solution will be straightforward - subclass you type. But if you'll decide to change the signature of a method in an existing class - you'll have no choice but to go through your entire codebase and deal with the damage.
In a functional language, functions are "cheap" - each function is independent from the ADT and refactoring it is often simple. Is that a weakness of OOP languages? No - it's just a tradeoff between ease of modifying existing "actions" (which is easy in functional languages) and ease of modifying "entities" (which is easy in OOP languages).
And in a practical note:
Designing an ADT is very important since changing can be very expensive.
#bheklilr's advice is priceless - follow it!
Is there a list of items on the web that you should not use when creating a model or variable?
For example, if I wanted to create apartment listings, naming a model something like Property would be problematic in the future and also confusing since property is a built-in Python function.
I did try Googling this, but couldn't come up with anything.
Thanks!
Rules and constraints about naming depend on the programming language. How an identifier/name is bound depends on the language semantics and its scoping rules: an identifer/name will be bound to different element depending on the scope. Scoping is usally lexical (i.e. static) but some language have dynamic scoping (some variant of lisp).
If names are different, there is no confusion in scoping. If identifiers/names are reused accrossed scopes, an identifier/name might mask another one. This is referred as Shadowing. This is a source of confusion.
Certain reserved names (i.e. keywords) have special meaning. Such keyword can simply be forbidden as names of other elements, or not.
For instance, in Smallatalk self is a keyword. It is still possible to declare a temporary variable self, though. In the scope where the temporary variable is visible, self resolves to the temporary variable, not the usual self that is receiver of the message.
Of course, shadowing can happen between regular names.
Scoping rules take types into consideration as well, and inheritance might introduce shadows.
Another source of confusion related to binding is Method Overloading. In statically typed languages, which method is executed depends on the static types at the call site. In certain cases, overloading makes it confusing to know which method is selected. Both Shadowing and Overloading should avoided to avoid confusions.
If your goal is to translate Python to Javascript, and vice versa, I guess you need to check the scoping rules and keywords of both languages to make sure your translation is not only syntactically correct, but also semantically correct.
Generally, programming languages have 'reserved words' or 'keywords' that you're either not able to use or in some cases are but should stay away from. For Python, you can find that list here.
Most words in most natural languages can have different meanings, according to the context. That's why we use specifiers to make the meaning of a word clear. If in any case you think that some particular identifier may be confusing, you can just add a specifier to make it clear. For example ObjectProperty has probably nothing to do with real estate, even in an application that deals with real estate.
The case you present is no different than using generic identifiers with no attached context. For example a variable named limit or length may have completely different meanings in different programs. Just use identifiers that make sense and document their meaning extensively. Being consistent within your own code base would also be preferable. Do not complicate your life with banned term lists that will never be complete and will only make programming more difficult.
The obvious exceptions are words reserved by your programming language of choice - but then again no decent compiler would allow you to use them anyway...
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.