Tag Info

New answers tagged

4

Break and Continue: In a talk about Scala, Martin Odersky gave 3 reasons not to include break or continue on slide 22: They are a bit imperative; better use many smaller functions. Issues how to interact with closures. They are not needed! And he then says, "We can support them purely in the libraries." On slide 23, he gives code that implements break. ...


2

Your friends comment First of all, it is definitely not correct what your friend is stating. Okasaki's book has had a major influence on data structures in several languages. Influence First of all, I think that we can categorize "influence" as one of either: Direct influence: Some programming language is implementing some of the data structures that ...


1

There are different mechanisms of polymorphism. Except for parametric polymorphism, these dispatch control flow depending on the type of function arguments. In other words: they are some kind of function overloading. The arguments can either be considered for their static type or for their dynamic type. If we dispatch a call on a static type, we call this ...


0

Your example already shows why it's not possible. Consider one. If you encountered one at runtime, should it evaluate to Int or Rational? There is no way how to decide. A related reading resource is OOP vs type classes at Haskell Wiki.


2

Functional programming is not about not having state. It about keeping the functions referential transparency and without side effects. Usually this mean having no state, but that not has to be the case. Referential transparency mean that for a given input parameters the function will always return the same output. No having side effect mean that the ...


0

Functional programming is not about having no state. Instead, all that immutability stuff is about making state explicit. A simple example is adding a list of numbers. In Python, we would do something like this: xs = [1, 2, 3, 4, 5] sum = 0 for x in xs: sum += x (Actually, we'd use the sum builtin, but this is just an example). This loop is stateful, ...


0

Consider the sentence I understand that my methods should not have side affects, and that I should favour immutability. Favour immutability means you should not use mutability when you don't need it, and that you should deal with it in a special way when you do need it. There are many cases in which you can use mutation to compute something, whereas ...


1

For some languages functions are not values. In such a language to say that val f = << i : int ... >> ; is a function definition, whereas val a = 1 ; declares a constant, is confusing because you are using one syntax to mean two things. Other languages, such as ML, Haskell, and Scheme treat functions as 1st class values, but provide the ...


2

Well, the reason might be, that those languages are not functional enough, so to say. In other words, you rather seldomly define functions. Thus, the use of an extra key word is acceptable. In languages of the ML or Miranda heritage, OTOH, you define functions most of the time. Look at some Haskell code, for instance. It's literally mostly a sequence of ...


10

You might be interested to learn that, way back in prehistoric times, a language called ALGOL 68 used a syntax close to what you propose. Recognising that function identifiers are bound to values just like other identifiers are, you could in that language declare a function (constant) using the syntax function-type name = (parameter-list) result-type : ...


8

You mentioned Java and Scala as examples. However, you overlooked an important fact: those aren't functions, those are methods. Methods and functions are fundamentally different. Functions are objects, methods belong to objects. In Scala, which has both functions and methods, there are the following differences between methods and functions: methods can ...


0

Functions are declared differently from literals, objects, etc. in most languages because they are used differently, debugged differently, and pose different potential sources of error. If a dynamic object reference or a mutable object is passed to a function, the function can change the value of the object as it runs. This kind of side effect can make it ...


3

Turning the question around, if one isn't interested in trying to edit source code on a machine which is extremely RAM-constrained, or minimize the time to read it off a floppy disk, what's wrong with using keywords? Certainly it's nicer to read x=y+z than store the value of y plus z into x, but that doesn't mean that punctuation characters are inherently ...


1

Personally, I see no fatal flaw in your idea; you may find that it's trickier than you expected to express certain things using your new syntax, and/or you may find that you need to revise it (adding various special cases and other features, etc), but I doubt you'll find yourself needing to abandon the idea entirely. The syntax you've proposed looks more or ...


44

I think the reason is that most popular languages either come from or were influenced by the C family of languages as opposed to functional languages and their root, the lambda calculus. And in these languages, functions are not just another value: In C++, C# and Java, you can overload functions: you can have two functions with the same name, but ...


0

There is a very simple reason to have such a distinction in most languages: there is a need to distinguish evaluation and declaration. Your example is good: why not like variables? Well, variables expressions are immediately evaluated. Haskell has a special model where there is no distinction between evaluation and declaration, which is why there is no need ...


3

The reasons that I can think of are: It is easier for the compiler to know what we declaring. It's important for us to know (in a trivial way) whether this is a function or a variable. Functions are usually black boxes and we don't care about their internal implementation. I dislike type inference on return types in Scala, because I believe that it's ...


0

This might be useful on dynamic languages where the type is not that important, but it's not that readable in static typed languages where always you want to know the type of your variable. Also, in object-oriented languages it's pretty important to know the type of your variable, in order to know what operations it supports. In your case, a function with 4 ...


56

It's because it's important for humans to recognize that functions are not just "another named entity". Sometimes it makes sense to manipulate them as such, but they are still able to be recognized at a glance. It doesn't really matter what the computer thinks about the syntax, as an incomprehensible blob of characters is fine for a machine to interpret, ...



Top 50 recent answers are included