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 e
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, som
Benjamin Leon Russell wrote:
> Tyson Dowd <[EMAIL PROTECTED]> wrote:
> > On 11-Aug-2000, Craig Dickson <[EMAIL PROTECTED]> wrote:
> >
> >
> >
> > > will be coming from C and C++ where it is perfectly
> > > normal to do all sorts of t
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
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
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
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
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
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 incre
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,
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
> >
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 th
that Jacobsen's
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: <
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"
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
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 we
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
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]>
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
Christian Sievers <[EMAIL PROTECTED]> wrote:
> I'm in trouble when it comes to @-patterns: is xs@(x:_) acceptable?
I'm sure I've used that, or something quite like it. xs is the whole list,
and x is its head.
> I've seen the (x:xs) (or whatever letter you want, BTW I'd use (f:fs)
> for a list o
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 Hun
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
Tim Bishop wrote:
>I am relatively new to Haskell, and I'm using Hugs 1.4.
>
>My my source of programming is Java, with the odd bit of basic thrown in
>for good measure.
>
>Now one of the first things I notice about Haskell is that there don't seem
>to be variables in the same sense that there ar
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", "T
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
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) = ... (...
28 matches
Mail list logo
