![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
If your answer is "it's not", you can probably stop reading now.
I've been thinking about the things that make Haskell interesting. Of
course, the main one is that it's a 100% functional language (as opposed
to an OOP/FP hybrid like Objective Camal), so if you want to see what
functional programming is like, Haskell is the place to go. But on
reflection, Haskell has several interesting and/or useful attributes
which actually have little or nothing to do with functional programming.
Haskell has automatic type inference, for example. You don't *need* a
functional language for that; you could totally do it in a normal
language. It's just that, historically, nobody has. (I guess the sort of
people who think about computer programs mathematically also tend to be
the sort of people who realise that things like type signatures can be
derived algorithmically.)
Everybody thinks that a programming language has to either have explicit
types (Pascal, C, C++, Java, Eiffel...) or no static typing at all
(Smalltalk, Tcl, JavaScript, every scripting language known to
mankind...) Haskell demonstrates that there is a Third Way: static
typing, but with the types implicit rather than explicit.
Obviously, there are times when either you NEED to be explicit - because
the correct answer is ambiguous, because you want improved performance,
whatever. There are also times when it's just "good style" to be
explicit; top-level functions should usually have type signatures. But
you don't have to write a signature for every single damned expression
and variable you use in the entire program; the compiler will figure it out.
Another thing Haskell has is parametric polymorphism. If you write some
code that makes data around, it shouldn't *matter* what the hell the
type of the data is. I mean, if you don't "do" anything with it other
than move it, what does it matter? So, for example, it should be
possible to write a function that joins two containers together,
regardless of what kind of element data they contain. (Obviously the
type of the containers themselves matters, but not the type of whatever
they contain.)
This pre-supposes that you have type-safe containers in the first place.
In most OO languages, you just create a container of "Object", which can
then contain anything. If you particularly want a container to contain,
say, only Customer objects, you usually have to implement this yourself,
by hand.
More recently, a couple of OO languages have introduced this feature
they call "generics". Eiffel is the first language I'm aware of that did
it, although I gather Java has it too now. What it allows you to do is
write a class parameterised by another class; the typical case being a
container class parameterised by the class of element it contains. (In
Eiffel, integers and floats are classes, unlike the Java brokenness.)
The difference is that Eiffel makes this seem like some highly complex
uber-feature that only a few people will ever need to use, in special
circumstances. Haskell makes it trivial. Defining a parametric type
requires barely a few keystrokes more than defining the same thing with
no parameters.
C++ has templates, and people often compare this to generics. I'm not
sure why. As far as I can tell, templates not even remotely similar to
generics.
- Generics are an extension to the type system which allow the type
checker to handle more sophisticated type signatures.
- Templates are, as best as I can tell, preprocessor macros on steriods.
They automate the process of creating a new, seperate, class for each
combination of parameter values. It's like copy & pasting each time you
want a new container class, except the template preprocessor automates
it for you. This is clearly very much more maintainable, but not the
same as extending the type checker.
It seems that templates can also be used to do things which are
impossible with generics (e.g., making the implementation *different*
for certain special cases). So I'm not sure why people compare them at
all, because they're so totally different.
Another thing Haskell has is algebraic data types. Other languages could
have this. It probably doesn't play well with the OO method though. In
fact, let me expand on that.
The OOP notion of classes, inheritance, substitution and so forth
basically assumes a model where you can always extend the current class
hierachy. For example, you initially decide what (conceptual) properties
every widget must have and write that in an abstract class. Thereafter,
you can always add new kinds of widget. (Or even specific kinds of
widget, of course.) It's a system that works fairly well.
Haskell with its algebraic data types assumes that the data you're
trying to model has a fixed, finite set of possibilities, which you can
describe once and for all. If that sounds stupid and limiting, consider
a binary tree. Every node in a binary tree is either a leaf node or a
branch node. You will never, ever, need to add a new kind of node. (If
you did, it wouldn't be a *binary tree*. It would be something else.)
So the data structure of a binary tree can be described once and for
all. However, the operations you can perform on it is extensible; you
can always add new operations.
Now consider the OOP case. You write an abstract "tree" class with
concrete "leaf" and "branch" subclasses. Each time you want to do
something new with the tree, you write an abstract method in the tree
class and add half of the implementation to each of the two concrete
subclasses.
In Haskell, you write one line of code which says "a tree is either a
leaf containing an item, or a branch containing two subtrees". You then
write as many functions as you like, which handle the leaf and branch
cases together, in one place (not split between three places).
For a binary tree, or an abstract syntax tree, or any number of other
simple, ridigly-defined data structures you could envisage, this
approach is actually much better. If you're writing a compiler or
interpretter, you don't *need* the abstract syntax tree to be
extensible. But you probably *do* need to be able to add new program
passes and code manipulation functions all the time. (And letting the
data structure be parameterised is probably Very Freaking Useful. Part
of the compiler might use strings for names, while another part might
use some more sophisticated structure representing fully-qualified
names, for example.)
Now let's flip this and look at widgets again. Using the ADT approach,
you'd need a giant "widget" type capable of representing any possible
widget. And functions that all know how to handle any possible widget.
And the code for handling a specific widget type is scattered between
all the widget-handling functions.
You're never ever going to need to add new functions for handling "any
possible widget" (although you might want one for handling a *specific*
kind of widget). But you very likely *will* want to add new types of
widget. But, uh, you can't.
In summary:
- If you have a limited number of structures which you want to process
in an unlimited number of ways, ADTs work best.
- If you have an unlimited number of structures which you want to
process in a limited number of ways, a class hierachy works best.
Haskell, of course, has to go one better: Haskell has what it calls
"classes", but really they're "interfaces". And you can add them after
the fact. Which means you can grab a bunch of unrelated data types
(possibly that you didn't even write) and create a single interface for
processing them all.
The one small glitch is that Haskell demands that all types are known at
compile-time. Which means that doing OO-style stuff where types are
changed dynamically at run-time is a little tricky. Haskell 98 (and the
newly-released Haskell 2010) can't do it, but there are
widely-implemented extensions that can. It gets kinda hairy though.
Married side by side with ADTs are case expressions. Now other languages
have case statements, but they tend to be quite feeble. In most
languages they only work on integers; I *think* Pascal lets you use 'em
on enumerations [but I'm not really sure]. And in C-like languages, you
can execute multiple alternatives at once. While this is no doubt
occasionally useful, most of the time it's just a source of
infuriatingly hard to find bugs (i.e., you left off the "break"
statement, so a whole bunch of code gets executed when you didn't want
it to).
In Haskell, case expressions work on *everything*. (Everything who's
internal structural details are in scope, anyway. These internal details
can be hidden from client code.) What is more, they use "pattern
matching". This powerful feature allows you to do things like determine
whether a tree has a particular shape and pluck several deeply-burried
substructures out of it, all in a single transparent 1-liner. For example,
case list of
[[x], [y,_], [z,_,_]] -> foo x y z
This checks whether "list" contains a list with exactly 3 elements, each
of which is a sublist of length 1, 2, 3 (respectively) - and, if all
this is the case, it fishes out the first element of each sublist and
feeds all the data to the "foo" function. All in one easily-readble line
of code. The alternative in Java would be something like
if (list.length == 3)
{
if (list.At(0).length == 1)
{
int x = list.At(0).At(0);
if (list.At(1).length == 2)
{
int y = list.At(1).At(0);
if (list.At(2).length == 3)
{
int z = list.At(2).At(0);
foo(x, y, z);
which is obviously a hell of a lot longer. What is more, if your Haskell
case expression has multiple cases in it (which it usually does),
because of the declarative form of the patterns, the compiler can
rearrange the code so that each test need only be performed once, and
the compiled code can proceed with the minimum number of branch
instructions. Such things are far, far harder to do with the
deeply-nested forest of if-statements above. (Not to mention that the
expressions in the if-statements might actually alter the program's
state, so changing their order may alter the program!)
Again, this probably doesn't gel too well with OOP, which states that
each data structure ("object") should be responsible for its own
internal substructure. In other words, you shouldn't *need* to fish out
deeply-burried data, the intervening objects in the chain should be
doing this for you. According to "the OO way", the only thing you should
ever do to objects is call methods on them, not inspect them for type
information or substructure.
But something like, say, JavaScript (which isn't really OO in the first
place) could certainly make use of ADTs and/or pattern matching, I think.
Another big deal about Haskell is how functions are first-class. The
fact that functions are pure makes this a really big win, but even
without pure functions, it's still useful. (Smalltalk implements it, for
example.) It doesn't immediately sound very interesting, but what it
enables you to do is write a loop once, in a library somwhere, and pass
in the "loop body" as a function.
A trivial example is a "fold". A fold takes some container (e.g., a
list) and repeatedly applies a binary function to it. The canonical
example is
sum = fold (+) 0
This says that to calculate the sum of a list, you fold it using the "+"
function, and with a starting value of 0. (This also means that the sum
of a completely empty list is 0.) It is obvious that
product = fold (*) 1
but there are plenty of other uses too. For example, the (++) function
joins to lists together, and
concat = fold (++) []
turns a list-of-lists into a single giant list. Other examples include
minimum = fold1 min
maximum = fold1 max
which find the minimum or maximum of a list using the binary "min" and
"max" functions. (The "fold1" function demands that the list be
non-empty, and doesn't require a start value.) I could go on all day,
but it turns out almost all uniform list operations can be implemented
as a fold of some kind.
Other languages have done this. Smalltalk is the obvious example. It has
#do: and #collect: which are approximately equivilent to Haskell's
"map", #select: and #reject: which are Haskell's "filter", and many
more. Of corse, being an object-oriented language, Smalltalk makes all
these methods work nicely for all container types, not just lists.
(Haskell hasn't copied this trick yet. At least, not in the *standard*
libraries. It's not difficult to change container, but it's tricky to
write code that works generically for any container.)
The other thing about first-class function is that in both Haskell and
Smalltalk, it is utterly trivial to spawn a new thread:
forkIO foo [foo] fork
What Smalltalk doesn't do, and Haskell does, is make combining small
functions into larger functions trivial as well. Haskell has anonymous
"lambda functions", it has the function composition operator, it has
curried functions, it has the dollar operator, and so on and so forth.
All of this *could* be put into Smalltalk, or any other OO language for
that matter. (Whether it would be efficient is a whole other matter...)
The final thing that's interesting about Haskell is the rate at which it
changes. Haskell (or rather, GHC) implemented Software Transactional
Memory 5 years ago. I'm not aware of any mainstream languages that have
this yet. GHC added Data Parallel Haskell 2 years ago, and the busy PhD
researchers are still hard at work getting it into a usable state.
(There's even an experimental GPU backend already.) Around the same
time, Type Families were added. (How long did it take Java to do
Generics?) The pace of change is staggering. Lots of new and very cool
stuff happens in Haskell first. (No doubt it will eventually all be
stolen by lesser languages so that people still don't use Haskell itself.)
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Invisible <voi### [at] dev null> wrote:
> Of course, the main one is that it's a 100% functional language
I thought that a 100% functional language has no mutable data structures
nor functions with side-effects.
> C++ has templates, and people often compare this to generics. I'm not
> sure why. As far as I can tell, templates not even remotely similar to
> generics.
Yeah, templates are a lot more powerful and versatile.
> - Templates are, as best as I can tell, preprocessor macros on steriods.
> They automate the process of creating a new, seperate, class for each
> combination of parameter values. It's like copy & pasting each time you
> want a new container class, except the template preprocessor automates
> it for you. This is clearly very much more maintainable, but not the
> same as extending the type checker.
Templates are not used only to generate classes, but also functions and
basic types. Template parameters can also be of almost any type (classes,
basic types, other templates, etc.) Also, templates can be recursive, which
is rather huge.
In short, templates allow compile-time polymorphism (as opposed to runtime
polymorphism in most OO and functional languages).
--
- Warp
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
>> Of course, the main one is that it's a 100% functional language
>
> I thought that a 100% functional language has no mutable data structures
> nor functions with side-effects.
Technically, Haskell is such a language. Technically, a Haskell program
itself doesn't produce any side-effects, it just constructs a data
structure and passes it to the Haskell Runtime System. The Haskell
Runtime System is what performs these side-effects.
That may sound like splitting hairs, since any compiled, runnable
Haskell program consists of your source code AND the Runtime System,
running as a single OS entity. In practical terms, you can "in effect"
mutate things in Haskell, and cause other side-effects. (This is of
course quite deliberate.)
Most "functional" languages allow you to perform side-effect anywhere,
any time you like. It is up to you to not screw this up. Haskell is
genuinely different. All side-effects are tightly constrained and
controlled, and the system provides strong guarantees about them. This
is why I feel it is justified to describe Haskell as "purely functional".
(That and the fact that it clearly has no OO features, no relational
features, no logical features, etc. It's definitely not mixed with any
other paradigm.)
>> C++ has templates, and people often compare this to generics. I'm not
>> sure why. As far as I can tell, templates not even remotely similar to
>> generics.
>
> Yeah, templates are a lot more powerful and versatile.
This was my conclusion also.
> Templates are not used only to generate classes, but also functions and
> basic types.
Yes, I was simplifying. (The paragraph was already bigger than I would
have liked, given the simplicity of the basic point I was attempting to
express.)
> In short, templates allow compile-time polymorphism (as opposed to runtime
> polymorphism in most OO and functional languages).
Seems like a nice way to sum it up.
I also forgot to mention Template Haskell. This GHC extension allows you
to run arbitrary Haskell code inside the compiler. It can [in principle]
do anything normal Haskell code does - read files, open network sockets,
etc. But it can also do things to the compiler - most obviously, it can
generate source code and feed it into the compiler.
You could use this to (for example) read a text file containing a BNF
grammer and generate the source code for a parser for it. But then, you
could do that without TH; just save the source code as a text file and
then compile it as a seperate step. The interesting part is that TH can
query the compiler. For example, it can read the description of a
datatype and write some boilerplate code for it. (But hey, if you need
to write boilerplate, doesn't that just mean that your language sucks?)
C has cpp, which (as far as I know) is very primitive and not
Turing-complete. C++ has templates, which are quite sophisticated.
Haskell has TH, which is obviously Turing-complete. I have no idea how
Lisp macros work, so I can't compare. (I believe Lisp macros can
generate code at runtime, however, which TH definitely cannot do.)
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Invisible wrote:
> Haskell has automatic type inference, for example.
Lots of languages have this a little. In C# you can say
var x = new Vector2(0,3);
and x gets the type Vector2. Automatic casting in languages is a similar
thing, methinks.
Certainly not to the large scale that Haskell does it.
> This pre-supposes that you have type-safe containers in the first place.
> In most OO languages, you just create a container of "Object", which can
> then contain anything.
This hasn't been true for a decade or more. :-) Just because Java sucks,
don't think every statically typed language sucks the same way.
> More recently, a couple of OO languages have introduced this feature
> they call "generics". Eiffel is the first language I'm aware of that did
> it, although I gather Java has it too now.
Java kinda sorta has it. It's *really* a container full of Objects, with
syntactic sugar to wrap and unwrap them. (Similarly, "inner classes" are
just regular classes with munged up names.)
> The difference is that Eiffel makes this seem like some highly complex
> uber-feature that only a few people will ever need to use, in special
> circumstances.
No, Eiffel's complexity is due to inheritance. If you have an array of
Animals, can you put a Dog in it? If you have an array of Dogs, can you pass
it to a routine that expects an array of Animals? Can you return an array of
Dogs from a routine declared to return an array of Animals or vice versa? If
X multiply inherits from Y and Z, can you assign an array of X to an array of Y?
It's not the complexity of the feature as much as its interactions with
other features of the type system.
> It seems that templates can also be used to do things which are
> impossible with generics (e.g., making the implementation *different*
> for certain special cases). So I'm not sure why people compare them at
> all, because they're so totally different.
They get compared because it's as close as C++ has to having real generics,
and C++ aficionados don't want to admit they don't have generics. ;-)
> Another thing Haskell has is algebraic data types. Other languages could
> have this. It probably doesn't play well with the OO method though. In
> fact, let me expand on that.
It's interesting that Eiffel is explicitly an attempt to make algebraic data
systems on top of OOP, in a sense. Hence the invariants, preconditions, etc.
> Haskell with its algebraic data types assumes that the data you're
> trying to model has a fixed, finite set of possibilities, which you can
> describe once and for all.
Integers are finite?
> Now consider the OOP case. You write an abstract "tree" class with
> concrete "leaf" and "branch" subclasses. Each time you want to do
> something new with the tree, you write an abstract method in the tree
> class and add half of the implementation to each of the two concrete
> subclasses.
I've never seen it done that way. :-)
> For a binary tree, or an abstract syntax tree, or any number of other
> simple, ridigly-defined data structures you could envisage, this
> approach is actually much better.
It depends how complex your tree is vs how complex your operations. If your
data is simple and your operations are complex, you're going to get
different trade-offs than if your data is complex and your operations are
simple. If a tree could have 300 different types of nodes, but you'll only
have 3 operations, which is better? Then invert that.
As you say, it depends what kind of extensibility you want. Add 50 new kinds
of nodes. Add 50 new operations. OOP was envisioned as adding new kinds of
things. New kinds of cars to a traffic simulation, new kinds of bank
accounts to a financial analysis program, etc.
Other than that, I'm not sure I really understood what you're talking about
in terms of "using the ADT approach" bit.
> - If you have a limited number of structures which you want to process
> in an unlimited number of ways, ADTs work best.
>
> - If you have an unlimited number of structures which you want to
> process in a limited number of ways, a class hierachy works best.
Yes, that. Well, not even a "limited number of ways." The point of OOP is
that you can add new structures *without* changing existing structures *at
all*.
> The one small glitch is that Haskell demands that all types are known at
> compile-time. Which means that doing OO-style stuff where types are
> changed dynamically at run-time is a little tricky. Haskell 98 (and the
> newly-released Haskell 2010) can't do it, but there are
> widely-implemented extensions that can. It gets kinda hairy though.
It also means you have to recompile everything whenever you change a type.
Which kind of sucks when it takes several days to compile the system.
> (i.e., you left off the "break"
> statement, so a whole bunch of code gets executed when you didn't want
> it to).
This is one that C# finally fixed right. Every branch of a switch has to end
with "break" or "goto". You're allowed to "goto" another case label, so you
can emulate "falling through." But even then, you can rearrange cases or
insert another case anywhere in the list without breaking any existing
cases. With a fallthrough, if you add a case without realizing the previous
case falls through, you just broke the previous case.
> In Haskell, case expressions work on *everything*.
Pattern matching is indeed cool in some set of circumstances.
> which is obviously a hell of a lot longer.
Yet, oddly enough, will work on things that *aren't lists*. That's the
point. :-)
> According to "the OO way", the only thing you should
> ever do to objects is call methods on them, not inspect them for type
> information or substructure.
Yep. And that's because you can substitute a new object and still use the
same code. Your pattern match wouldn't work at all if you said "Hmmm, I'd
like to use that same function, only with a set instead."
> But something like, say, JavaScript (which isn't really OO in the first
> place) could certainly make use of ADTs and/or pattern matching, I think.
Huh? Javascript is about as OO as Smalltalk is. There's nothing in
Javascript that is *not* an object.
> Another big deal about Haskell is how functions are first-class. The
> fact that functions are pure makes this a really big win, but even
> without pure functions, it's still useful. (Smalltalk implements it, for
> example.) It doesn't immediately sound very interesting, but what it
> enables you to do is write a loop once, in a library somwhere, and pass
> in the "loop body" as a function.
Lots of languages have this, just so ya know. :-)
> Other languages have done this. Smalltalk is the obvious example.
Smalltalk doesn't have first-class functions. It has first class blocks,
which are closures (or continuations, more precisely). You're not passing a
function to #do:. You're passing a stack frame.
> What Smalltalk doesn't do, and Haskell does, is make combining small
> functions into larger functions trivial as well.
That's because Smalltalk doesn't have functions. It has methods. And blocks.
And continuations.
> All of this *could* be put into Smalltalk, or any other OO language for
> that matter. (Whether it would be efficient is a whole other matter...)
Not... really. The difference is that Haskell functions work on data, while
Smalltalk only has objects. In other words, you can't invoke a function
without knowing what object that "function" is a method of. (This is also
the case for Javascript, btw.)
C# has lambdas and anonymous expressions and stuff like that. It also has
"delegates", which is a list of pointers to object/method pairs (or just
methods, if it's a static/class method that doesn't need an instance).
> I'm not aware of any mainstream languages that have this yet.
Several languages have implemented this as libraries. Generally not for
threading but for database stuff.
> (How long did it take Java to do Generics?)
It wasn't that generics took a long time. It's that the owners of the
language didn't want them, for whatever reason. Then, once Java was popular,
it was impossible to change the JVM classfile format without killing what
little momentum Java still had, so they had to be shoehorned in. See above.
I.e., it took Java a long time to do Generics *because* people cared about
Java. ;-)
I mean, Python has explicitly said "We're going to not change anything in
the language spec for 2 to 3 years until everyone else writing Python
compilers/interpreters catch up."
It's easy to innovate when you have the only compiler.
> The pace of change is staggering. Lots of new and very cool
> stuff happens in Haskell first. (No doubt it will eventually all be
> stolen by lesser languages so that people still don't use Haskell itself.)
That's not hard to do when you have no user base you have to support.
--
Darren New, San Diego CA, USA (PST)
The question in today's corporate environment is not
so much "what color is your parachute?" as it is
"what color is your nose?"
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Invisible wrote:
> (I believe Lisp macros can
> generate code at runtime, however, which TH definitely cannot do.)
I don't think macros are still around at runtime. What they *can* do is read
user input at compile time, so you can (for example) make up new kinds of
literals.
Assume Haskell doesn't have the "0xABC" kind of syntax for hex literals.
Could you add that with Haskell, or TH?
--
Darren New, San Diego CA, USA (PST)
The question in today's corporate environment is not
so much "what color is your parachute?" as it is
"what color is your nose?"
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Darren New <dne### [at] san rr com> wrote:
> Invisible wrote:
> > Haskell has automatic type inference, for example.
> Lots of languages have this a little. In C# you can say
> var x = new Vector2(0,3);
> and x gets the type Vector2. Automatic casting in languages is a similar
> thing, methinks.
The next C++ standard will instroduce something similar: The 'auto' type.
The idea is that since the compiler can deduce the type of the variable in
most situations, then why should the programmer have to specify it explicitly?
Thus you will be able to write things like:
for(auto iter = v.begin(); iter != v.end(); ++iter) ...
The compiler can see what is the return type of v.begin(), so there's no
need for the programmer to know it. Hence he can just specify 'auto' as the
variable type.
This will be more than just a convencience shortcut, though. For example,
it allows doing something like this:
template<typename Container>
void foo(const Container& container)
{
auto element = container[0];
....
}
The type of the element may differ from container to container, and if
you need a variable of that type, previously there was no fool-proof way
of doing that. (The usual way around this to define a typedef inside the
container named "value_type" which defines the type of the elements, but
the 'auto' keyword will eliminate the need for that.)
--
- Warp
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
"Invisible" <voi### [at] dev null> wrote in message
news:4b87d781@news.povray.org...
>
> If your answer is "it's not", you can probably stop reading now.
I know it's interesting to *me* because I'd never heard of it before I
started reading this newsgroup. Always like learning something new... :-)
--
Jack
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Warp wrote:
> Thus you will be able to write things like:
>
> for(auto iter = v.begin(); iter != v.end(); ++iter) ...
>
> The compiler can see what is the return type of v.begin(), so there's no
> need for the programmer to know it. Hence he can just specify 'auto' as the
> variable type.
That's a nice touch. Presumably this also means that if the type of "v"
changes, you don't have to manually change the type of "iter" to match
any more...?
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Orchid XP v8 <voi### [at] dev null> wrote:
> Warp wrote:
> > Thus you will be able to write things like:
> >
> > for(auto iter = v.begin(); iter != v.end(); ++iter) ...
> >
> > The compiler can see what is the return type of v.begin(), so there's no
> > need for the programmer to know it. Hence he can just specify 'auto' as the
> > variable type.
> That's a nice touch. Presumably this also means that if the type of "v"
> changes, you don't have to manually change the type of "iter" to match
> any more...?
Right.
--
- Warp
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
>> Haskell has automatic type inference, for example.
>
> Lots of languages have this a little. In C#
Just out of curiosity, just how new *is* C#?
> This hasn't been true for a decade or more. :-) Just because Java sucks,
> don't think every statically typed language sucks the same way.
...there are statically-typed OO languages which aren't Java? [Or
Eiffel, which nobody ever uses.]
C++ is statically-typed, but even Warp will agree it's not a
specifically OO language; it's more of a pragmatic hybrid of styles.
>> More recently, a couple of OO languages have introduced this feature
>> they call "generics". Eiffel is the first language I'm aware of that
>> did it, although I gather Java has it too now.
>
> Java kinda sorta has it. It's *really* a container full of Objects, with
> syntactic sugar to wrap and unwrap them.
Oh dears.
> (Similarly, "inner classes" are just regular classes with munged up names.)
Yeah, that's what I would have expected.
>> The difference is that Eiffel makes this seem like some highly complex
>> uber-feature that only a few people will ever need to use, in special
>> circumstances.
>
> No, Eiffel's complexity is due to inheritance.
>
> It's not the complexity of the feature as much as its interactions with
> other features of the type system.
All I know is that Eiffel makes it seem like this really exotic feature
that you "shouldn't need to use" under normal circumstances, and if you
find yourself using it, you've probably designed your program wrong.
Even C++ templates make it seem like a pretty big deal.
Haskell, on the other hand, makes it trivial.
> It's interesting that Eiffel is explicitly an attempt to make algebraic
> data systems on top of OOP, in a sense. Hence the invariants,
> preconditions, etc.
Uh... what?
>> Haskell with its algebraic data types assumes that the data you're
>> trying to model has a fixed, finite set of possibilities, which you
>> can describe once and for all.
>
> Integers are finite?
They are if there fixed-precision. ;-)
In fact, if you want to be really anal, if they're stored on a computer
that exists in the physical world, they're finite, since the amount of
matter [and energy] in the observable universe is finite. But I'm sure
that's not what you meant.
>> Now consider the OOP case. You write an abstract "tree" class with
>> concrete "leaf" and "branch" subclasses. Each time you want to do
>> something new with the tree, you write an abstract method in the tree
>> class and add half of the implementation to each of the two concrete
>> subclasses.
>
> I've never seen it done that way. :-)
Oh really? So how would you do it then?
> It depends how complex your tree is vs how complex your operations.
I could have sworn I just said that. ;-)
> As you say, it depends what kind of extensibility you want. Add 50 new
> kinds of nodes. Add 50 new operations. OOP was envisioned as adding new
> kinds of things. New kinds of cars to a traffic simulation, new kinds of
> bank accounts to a financial analysis program, etc.
Indeed. You do NOT want to design one giant ADT that represents every
possible kind of bank account, and write huge monolithic functions that
understand how to process every possible kind of bank account. It's
non-extensible, and all the code relating to one particular type of
account is scattered across the different account processing functions,
so it's the wrong way to factor the problem.
My point is that there are major classes of problems which *are* the
other way around, and for that ADTs win. For example, the parse tree of
an expression. You are almost never going to add new types of node to
that, but you *are* going to be adding new processing passes all the
time. For this, Haskell's ADT + functional approach factors the problem
"the other way", and that works out better for this kind of problem.
And when it doesn't work out right, you use interfaces and get the
essence of the OO solution.
>> - If you have a limited number of structures which you want to process
>> in an unlimited number of ways, ADTs work best.
>>
>> - If you have an unlimited number of structures which you want to
>> process in a limited number of ways, a class hierachy works best.
>
> Yes, that.
LOL!
> Well, not even a "limited number of ways." The point of OOP
> is that you can add new structures *without* changing existing
> structures *at all*.
And I was pointing out that for each thing you want to do to a
structure, you have to add new methods up and down the inheritance hierachy.
Ultimately, if you have a kind of structure that you need to perform a
bazillion operations on, what you'll hopefully do is define a set of
"fundamental" operations as methods of the structure itself, and define
all the complex processing somewhere else, in terms of these more
fundamental operations. (If you take this to the extreme, you obviously
end up with dumb data objects, which usually isn't good OO style.)
>> The one small glitch is that Haskell demands that all types are known
>> at compile-time. Which means that doing OO-style stuff where types are
>> changed dynamically at run-time is a little tricky. Haskell 98 (and
>> the newly-released Haskell 2010) can't do it, but there are
>> widely-implemented extensions that can. It gets kinda hairy though.
>
> It also means you have to recompile everything whenever you change a
> type. Which kind of sucks when it takes several days to compile the system.
Are there systems in existence which actually take that long to compile?
Anyway, Haskell extensions allow you to do runtime dynamic dispatch.
That means you don't have to recompile your code. [Although you will
have to relink to add in the new types you want to handle, etc.] It's
just that it pisses the type checker off, which means you can't do
things you'd normally expect to be able to do.
(In particular, the basic ExistentialQuantification extension allows
typesafe upcasts, but utterly prohibits *downcasts*, which could be a
problem...)
>> (i.e., you left off the "break" statement, so a whole bunch of code
>> gets executed when you didn't want it to).
>
> This is one that C# finally fixed right.
Oh thank God...
> Pattern matching is indeed cool in some set of circumstances.
Aye.
(Jay. Kay. El...)
>> which is obviously a hell of a lot longer.
>
> Yet, oddly enough, will work on things that *aren't lists*. That's the
> point. :-)
Well, you can pattern match on the size of the container (presuming you
have a polymorphic "size" function to get this). It won't be quite as
neat though, obviously.
Secondly, there's actually an experimental extension to Haskell called
"view patterns" which allow you to create sort-of "user defined pattern
matching". This fixes this exact problem. (And a couple of others.)
> Yep. And that's because you can substitute a new object and still use
> the same code. Your pattern match wouldn't work at all if you said
> "Hmmm, I'd like to use that same function, only with a set instead."
Yes, in general pattern matching is used for implementing the "methods"
for operating on one specific type. (Although of course in Haskell they
aren't methods, they're just normal functions.) Your polymorphic stuff
is then implemented with function calls, not pattern matching. But see
my previous comments.
> Huh? Javascript is about as OO as Smalltalk is. There's nothing in
> Javascript that is *not* an object.
1. Smalltalk has classes. JavaScript does not.
2. Smalltalk has encapsulation. JavaScript does not.
>> Another big deal about Haskell is how functions are first-class.
>
> Lots of languages have this, just so ya know. :-)
Yeah. Smalltalk, JavaScript, Tcl after a fashion. C and C++ have
function pointers, and you can sort-of cludge the same kind of
techniques as found in Haskell. (But you wouldn't. It would be
horrifyingly inefficient.)
>> Other languages have done this. Smalltalk is the obvious example.
>
> Smalltalk doesn't have first-class functions. It has first class blocks,
> which are closures.
I won't pretend to comprehend what the difference is, but sure.
>> What Smalltalk doesn't do, and Haskell does, is make combining small
>> functions into larger functions trivial as well.
>
> That's because Smalltalk doesn't have functions. It has methods. And
> blocks. And continuations.
Plausibly.
>> All of this *could* be put into Smalltalk, or any other OO language
>> for that matter. (Whether it would be efficient is a whole other
>> matter...)
>
> Not... really. The difference is that Haskell functions work on data,
> while Smalltalk only has objects. In other words, you can't invoke a
> function without knowing what object that "function" is a method of.
> (This is also the case for Javascript, btw.)
Erm... no, not really.
function foo(x) {...}
var bar = foo;
var x = bar(5);
No objects here, no methods, just assigning a function to a variable and
using it later. You *can* make a function an object method, but you do
not *have* to. JavaScript is like "meh, whatever, dude. I'm green."
> C# has lambdas and anonymous expressions and stuff like that. It also
> has "delegates", which is a list of pointers to object/method pairs (or
> just methods, if it's a static/class method that doesn't need an instance).
Eiffel has... uh... "agents"? Which are basically GUI callback
functions, but we wouldn't want to have actual functions, would we?
>> I'm not aware of any mainstream languages that have this yet.
>
> Several languages have implemented this as libraries. Generally not for
> threading but for database stuff.
Yeah. Databases have been transactional for decades, and many languages
can access a database. But STM is all internal to the program, and
implements multi-way blocking and conditional branching and all kinds of
craziness.
I'd point you to the paper I just wrote about implementing it using
locks... but then you'd have my real name. The long and short of it is,
it boils down to running the transaction *as if* there are no other
transactions, but not actually performing any real writes. Then, when
we've discovered exactly what the transaction wants to do to the central
store, we take all the locks in sorted order. So the essence of the
whole thing is that by simulating the transaction from beginning to end,
we solve the old "I don't know what I need to lock until I've already
locked stuff" problem. (And make all the locking stuff the library
author's problem, not yours.)
>> (How long did it take Java to do Generics?)
>
> It wasn't that generics took a long time. It's that the owners of the
> language didn't want them, for whatever reason.
Heh, nice.
> I mean, Python has explicitly said "We're going to not change anything
> in the language spec for 2 to 3 years until everyone else writing Python
> compilers/interpreters catch up."
>
> It's easy to innovate when you have the only compiler.
Haskell has a motto: "Avoid success at all costs." The meaning of this,
of course, is that if Haskell suddenly became crazy-popular, we wouldn't
be able to arbitrarily change it from time to time. (In reality, this
point has already long ago been reached.)
And just FYI, there *is* more than one Haskell compiler. Actually, there
are several - it's just that only one has a big enough team working on
it that they produce a production-ready product. [There are people who
*get paid money* to write GHC.] All the others are PhD projects, or
hobbiests. At one time there were several viable production compilers,
but most of them have gone dormant due to the dominance of GHC.
>> The pace of change is staggering. Lots of new and very cool stuff
>> happens in Haskell first.
>
> That's not hard to do when you have no user base you have to support.
Heh. Better not tell that to Galois.com, Well-Typed.com, the authors of
the 1,000+ packages in the Hackage DB, or the likes of Facebook, AT&T,
Barclays Analytics or Linspire who all apparently use Haskell internally.
Sure, Haskell is no Java, C# or PHP. But that's not to say that *nobody*
is using it...
See below for some outdated blurb:
http://www.haskell.org/haskellwiki/Haskell_in_industry
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |