At first glance I thought they were decorators/annotations, but I'm not sure that's exactly what they are.
They are called attributes. Most of them have no inherent meaning, though a handful (__Override, __ConsistentConstruct, __Memoize, __Deprecated) have runtime and type checker meanings.
Related
I'm trying to learn Haskell in guidance of Learn You a Haskell, but the following puzzles me.
lucky :: (Integral a) => a -> String
lucky 7 = "LUCKY NUMBER SEVEN!"
lucky x = "Sorry, you're out of luck, pal!"
As you can see, there's one line up there stating the exact types of the function. But is this necessary? Can't the types of parameters and return values be deduced from the patterns below that line?
You are right, they are absolutely not necessary. However, it's a very common practice to state the type of the function nevertheless, for at least two reasons :
To tell the compiler what you actually mean. In case you make a mistake writing the function, the compiler will not infer a bad type, but warn you of your mistake
To tell the people who read your code. They'll have to find out the type of the function anyway while understanding the code, so you might as well make it easier for them. Having the type explicitly makes the code more readable.
This is why, although they are optional, the types of top level functions are almost always spelled out in Haskell code.
To complete with what Zeta said, it is not necessary in this case. However, in some situations, it is necessary to specify the type of the function when the code is too ambiguous to infer.
For documentation purpose, and because for some type extensions the automatic inference fails. Read here.
On slide 30/78 of this presentation, Simon suggests that implementation of type classes was a "despair" at the beginning. Is anybody aware why that was?
I guess I'm one of the few people who have first hand experience of why it was hard, since I implemented it in hbc when there was no prior art.
So what was clear from the Wadler&Blott paper was that type checking was an extension of Hindley-Milner type checking and that at runtime you should be passing dictionaries around. From that to an actual implementation is a rather big step. A good way to understand the difficulty is to actually implement it starting from just the Wadler-Blott paper.
First, you need to come up with the idea of a type checker that not only checks types but also transforms the program; inserting evidence (dictionaries) while type checking. You also need to figure out how to construct new dictionaries from old ones using the instance declarations as an inference system.
It might all seem obvious in retrospect, but remember that since that time a lot of papers with explanations have been written. Understanding how to do something from a paper is very different from coming up with it in the first place.
Furthermore, you want type classes to be reasonably efficient which leads to its own set of problems.
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...
Is it possible to disable or work around the type system in Haskell? There are situations where it is convenient to have everything untyped as in Forth and BCPL or monotyped as in Mathematica. I'm thinking along the lines of declaring everything as the same type or of disabling type checking altogether.
Edit: In conformance with SO principles, this is a narrow technical question, not a request for discussion of the relative merits of different programming approaches. To rephrase the question, "Can Haskell be used in a way such that avoidance of type conflicts is entirely the responsibility of the programmer?"
Also look at Data.Dynamic which allows you to have dynamically typed values in parts of your code without disabling type-checking throughout.
GHC 7.6 (not released yet) has a similar feature, -fdefer-type-errors:
http://hackage.haskell.org/trac/ghc/wiki/DeferErrorsToRuntime
It will defer all type errors until runtime. It's not really untyped but it allows almost as much freedom.
Even with fdefer-type-errors one wouldn't be avoiding the type system. Nor does it really allow type independence. The point of the flag is to allow code with type errors to compile, so long as the errors are not called by the Main function. In particular, any code with a type error, when actually called by a Haskell interpreter, will still fail.
While the prospect of untyped functions in Haskell might be tempting, it's worth noting that the type system is really at the heart of the language. The code proves its own functionality in compilation, and the rigidity of the type system prevents a large number of errors.
Perhaps if you gave a specific example of the problem you're having, the community could address it. Interconverting between number types is something that I've asked about before, and there are a number of good tricks.
Perhaps fdefer-type-errors combined with https://hackage.haskell.org/package/base-4.14.1.0/docs/Unsafe-Coerce.html offers what you need.
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.