I was wondering if you thought it was efficient to only be able to return a new array for each modification of an array.
It seems like it would be a great hindrance to efficiency in comparison with a procedural approach to a programming problem.
I was staring at Scala as it crossed freshmeat and it reminded me strongly of Haskell:
By and large it does to me... anyone else?
This hardly has anything to do with functional programming in general, or Haskell in particular, but I'm a bit upset by the move to Intel processors. It seems to me that going with AMD might've been a more viable choice, at least from a ISA pov. Furthermore, while AMD chips still dissipate more power than Intel processors, the CPU's seem to be much nicer, better designed, and yield real 64-bit power.
Guess I won't be able to upgrade my powerbook status to a shiny G5 in a few years.
I am wondering if there exists any interest in doing some research into the low-level performance of ghc-cmpiled Haskell (duh) applications. It seems to me that getting an idea on cache-miss rates, branch prediction, etc. could be of interest to the Haskell community.
The main problem atm lies in the benchmarks that would be needed (of course!). People at #haskell have suggested using the ghc regression suite, but I am not sure if these qualify as real-world apps, i.e. the real stuff people use Haskell for.
All input is appreciated.
In figure 6.3 we see 4 figures. The starting figure is to the "West" and shows two horses superimposed.
My question is, what are the coordinates of the reference point of the two images?
All phenomena, including computational acts, are acts of creation, maintenance, or destruction. Haskell contains a number of well designed creative acts:
c1 :: Contract c1 = zcb (date "1 Jan 2001") 100 Pounds zcb :: Date -> Float -> Currency -> Contract -- Zero coupon bond
Pounds is a type constructor in the above... and zcb creates values of a certain type.
- lazy evaluation:
nothing is created until it is needed
- list comprehensions
concise ways to stating how a list is created.
Destruction is handled via automatic garbage control. There is little support for loading up and Maintaining data in-memory.
A question on #C++ caught my eye:
im waiting for user input .. using getch() .. if a user hasnt entered another key within 1 second i want to perform some action, rather than waiting for a newline or something else .. using a while doesnt work because getch() hangs until u enter a char .. any ideas?
how easy would something like this be in Haskell?
Haskell is very good at describing the structure or pattern involved in something. It excels at compiler design for this very reason.
It is also the reason that 5-line Perl programs take much longer in Haskell. For instance, look at this program to find the file with the longest length in Haskell:
I have been a professional Perl programmer for 5 years. Perl5 is a wonderfully agile language. It was very odd that I would discover Haskell independantly right around the same time as Autrijus did.
Having stared at Perl6 and given 3 talks on it, I am convinced that it is a big confused mess. A BIG confused mess. I don't think it will be eagerly accepted and many people are going to stay with perl5 or find another language.
I want to go to the heart of computing. I am very impressed with Haskell for every reason that you could be. I worry that it is only 1/2 as fast as OCaml, but I demand to work in a pure functional language. While most people are very open-minded about languages, I am not. I am passionate and religious about whatever I involve myself in and I only get involved with what I think is right, not what is popular.
I have to get out of Perl while the getting is good. C++ holds some attraction for me. Much larger libraries than Haskell. Class-based programming with typing. Many apps are delivered in C++. This web browser I am using is probably written in it. My IRC client is C++-based. My chess database is as well... hmm wait a minute. I think I will look at C++ closer.
But anyway, I had been studying Haskell every day after work and then I got stressed and tensed and started avoiding. I need some way to sit down in front of my computer and study Haskell whether I like it or not. But until I get C++ out of my head, I am still a case of a divided mind.
Haskell: type checking. Instead of debugging your code, trying to figure out the return types of return data, the strong type checker within the language itself does it.
Perl: type conversion. Instead of having to deal with taking a string of input and turning strings into numbers before doing math on them, Perl does all this behind the scenes for you.
Prolog: inferencing (depth-first tree search). Instead of you having to write an algorithm to explore a tree of assertions to determine the closed-world validity of a statement, you let the built-in inferencing engine do this.
PHP: web readiness. Instead of having to come up with a protocol for embedding Perl into HTML, PHP ships ready for web programming right out of the box. No need to download Perl's HTML::Mason or PLP. No need for HaXML or whatever. Load, lock and rock.
Visual Basic: .NET integration. Instead of having to write win32 libraries and then .NET libraries, Visual Basic comes ready for .NET and win32 programming from the get-go.
Emacs Lisp: IDE integration. Instead of having to use a separate tool for the edit/test part of the programming cycle, Emacs Lisp _is_ the edit/test as well a development program. Thus, you can use one tool for all aspects of development. Additionally, the base GUI for user interaction is the editor, which saves you have from having to write the basic UI widgets.
Shell: shell access. No need for foreign syntax to access shell commands (true of Tcl also). Very easy access to directory listings, etc.