propose with my free mind and as a person of integrity and from
a family with high moral respect . My name is Dickson Mubane, the first
son of Mapele Mubane, of the most popular black farmer from Zimbabwe,
murdered in the land dispute in my country. As led by my instict, My
motherand Idecided
Doug Ransom wrote:
I think you are mistakening ignorance for stupidity. It
is true that C/C++ programmers like to write OO and few
have any idea about functional programming, but very few
will miss the ability to constantly shoot themselves in
the foot with uninitalized random pointers,
I see that the discussion has progressed considerably during the (for me, in
California) night, so I'll just make a couple of comments...
Ketil Z. Malde wrote:
: functions, while pretty first class objects, reside in
their own namespace, and need special operators.
: iteration and side
Jacques Lemire wrote:
On the contrary, languages like C++ (and Java) and
C# are full of concepts and ideas coming from FP
languages. For example, the catch/try/throw construct
is coming directly from Common Lisp (Lisp is a
(although impure) FP language).
This is, needless to say,
Benjamin Leon Russell wrote:
Tyson Dowd [EMAIL PROTECTED] wrote:
On 11-Aug-2000, Craig Dickson [EMAIL PROTECTED] wrote:
stuff deleted/stuff deleted
will be coming from C and C++ where it is perfectly
normal to do all sorts of things that the compiler
cannot guarantee
Antony Courtney wrote:
But Java also has a way to do "rampant pointer-level
optimization": You declare a method as "native" and
then implement it in C.
That's hardly the same thing, though. Of course an FFI allows you do to all
sorts of things, but at least it's very clear, from the fact
Sylvan Ravinet wrote:
Do, or do not. There's no try. -Yoda
Pedantic not to be, but in contractions speak, does Yoda not. Is quote, "Do,
or do not. There is no 'try'."
Craig
Brent Fulgham wrote:
Thanks for the link! Unfortunately, its click-through
license forbids disassembly, reverse engineering, and a
raft of other endeavors that one should be allowed if
they were truly interested in global acceptance.
Well, this _is_ Microsoft, after all.
Of course, a few
Benjamin Leon Russell wrote:
However, according to the C# Language Reference,
"For developers who are generally content with
automatic memory management but sometimes need
fine-grained control or that extra iota of
performance, C# provides the ability to write
unsafe code. Such code can
Nigel Perry wrote:
NGWS
An older temporary name for .NET. NGWS? Never Goes Wonderfully Sucks?
I think somebody shot the marketing guy and replaced him, she then
came up with ".NET" :-)
Next Generation Windows Services (I think), as opposed to older generations
such as the Win32 APIs and
Fergus wrote:
I guess one could argue that the costs of most other things pale
in comparison to the costs of having lazy evaluation as the default ;-)
Of course, if you're the sort of person who likes to write "head (sort lst)"
to get the least member of a list, then lazy evaluation is
S.D.Mechveliani [EMAIL PROTECTED] wrote:
Today, there came the letter by Joe English on space leak etc.,
dated of February 06.
And today is February 22.
I wonder, what is the matter with the mail lists.
The delay, in this case, appears to have been on the sending server's side,
so I
Brian Boutel [EMAIL PROTECTED] wrote:
We have seen various proposals about what laws should hold wrt
take and drop. I think there is a reasonable presumption that the
following very simple laws should hold first:
length (take n xs) === n
length (drop n xs) === length xs -n
Does that not
Tom Pledger [EMAIL PROTECTED] wrote:
Craig Dickson writes:
[...]
I don't want a pattern like "(x:xs)" to match the empty list, which
it presumably would if "head []" and "tail []" did not fail (x and
xs would both be bound to []).
I don't think it
Brian Boutel wrote:
take -2 [1,2,3,4] ++ drop -2 [1,2,3,4] - [3,4,1,2]
But [1,2,3,4] is NOT the same as [3,4,1,2]. So the equality doesn't hold.
Personally, for reasons I'm not sure I can articulate, I've always strongly
disliked the notion that negative arguments should produce "backwards"
definitions for take and drop didn't work. Nevertheless, I stand by my
argument against allowing negative arguments to take/drop to produce
"backwards" behavior.
Craig
- Original Message -
From: "Craig Dickson" [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, 24 J
Colin Runciman [EMAIL PROTECTED] wrote:
I also agree with Simon that simply making this a moderated list is
not the solution. Perhaps splitting is best. How about
haskell-info
haskell-talk
where info carries *brief* announcements, requests for information
and responses to such
Kevin Atkinson [EMAIL PROTECTED] wrote:
God NO, I like C++ because it is powerful but adding more features on an
already ugly (but powerful languge) will make matters worse my making it
more powerful but so ugly with so many pitfalls that no one will want to
use it.
Some would say this has
Paul Moore [EMAIL PROTECTED] wrote:
Now, I tried this in Hugs98 and found inconclusive results. Both fact1
1
and fact2 1 failed with a control stack overflow. However, when I was
experimenting earlier today (I didn't save the results :-() I got a
variation on fact2 which went well
xander [EMAIL PROTECTED] wrote:
is there an opposite (:) available in haskell?
like, i can toss an element at the back of a list without
O(n) fuss recursing bla??
You can cons an element onto the front of a list without modifying it, but
adding an item at the end of the list will modify the
Now that you're an (ahem) Microsoft employee, is there any intention of
allowing ghc to use Visual C++ instead of gcc, or supporting the Win32
platform without cygwin?
Thanks,
Craig
- Original Message -
From: Simon Marlow [EMAIL PROTECTED]
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent:
Jeff Dalton [EMAIL PROTECTED] wrote:
Sure, cat in itself isn't very interesting. But cat is just a simple
case of a more interesting problem, that of writing what Unix calls
"filters": programs that take some input from a file or pipe or other
similar source and transform it into some
Jan Skibinski [EMAIL PROTECTED] wrote:
But there are some stylistic camps, such as Eiffel's, that
prefer names with underscores rather than Hungarian notation
- claiming exactly the same reason: better readability. :-)
I don't see that underscores serve readability in the same way as
Jerzy Karczmarczuk [EMAIL PROTECTED] wrote:
More seriously, I jumped into this FP paradise from a good, Fortran
loving milieu, when I found that there were problems very awkward to
solve using imperative programming. I wouldn't have started to use FP
just to test that it is possible to
Steve Frampton wrote:
Okay, I'm [damn] confused regarding type-casting in Haskell.
Because there isn't any?
I'm trying
to write a function that accepts an integer and then returns a set (in
this case, a set of characters).
I'm having a lot of problems with "Declared type too general", "Type
Brian Boutel wrote:
n+k patterns make sense for a type of Natural Numbers (including 0),
but not for general Integral types.
They are also dangerous because they are defined in terms of and -,
which,
in a user-defined type, need not obey the usual laws, e.g. you cannot
assume
that 0 1 holds.
Johannes Waldmann wrote:
i'd like to support Ralf's opinion: n+k patterns have advantages
(when used in a certain manner) so it would be good to keep them.
personal reason: right now i'm busy giving tutorials on recursive functions
and it's really nice if you can write f(...,y+1) = ... (... y)
27 matches
Mail list logo
