On 5 Oct, Manuel M. T. Chakravarty wrote:
I currently use (# and #) [...]
Any opinions?
Definitely use the pragma syntax suggested by Simon PJ
--
Jón Fairbairn [EMAIL PROTECTED]
[My apologies: some day - I promise - I'll learn to choose the right mailing
list... 8-]
On Mon, Oct 04, 1999 at 13:45:43 +0200, Sven Panne wrote:
[micro-marshalling]
I know Manuel's code already and the one H/Direct produces. Has anybody
else some FFI-related code and/or suggestions? This
I currently use (# and #) to identify the binding hooks in
annotated Haskell modules for the interface generator
C-Haskell. These lexemes unfortunately collide with GHC's
syntax for unboxed tuples. So, I was wondering whether to
maybe use [# ... #] or {# ... #}. C-Haskell removes all of
these
Simon Marlow wrote:
Hmm, good points. The delay before running the signal
handler shouldn't be
too long, unless you have *lots* of running threads.
Actually it is long in the case of the program I'm trying (1
minute and counting).
I think that's because input is done via a
This is a very nice function but unfortunately it still
doesn't quite work, because
of the delay in executing the interrupt action. (I write
having applied the
patch and tried the function out with a little program of my
own.) I suppose it is
not so bad that
allowInterupts action
On 04-Oct-1999, George Russell [EMAIL PROTECTED] wrote:
(b) a type of compile-time if statement which will branch on simple
arithmetic and boolean expressions in constant values and constants,
which doesn't typecheck the branch which isn't taken. For example,
this is what Java provides and I
Jan Skibinski [EMAIL PROTECTED] wrote,
If a good pre-processor is still a valid option, would not
something similar to Camlp4 be better than the plain CPP?
Camlp4 === http://pauillac.inria.fr/camlp4/
"Camlp4 is a Pre-Processor-Pretty-Printer for Objective Caml.
The latter, using the comprehension, is a bit better in GHC,
because if c' gets inlined the list comprehension might get
deforested with its consumer. WIth an explicitly recursive c, that
won't happen.
Simon
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent:
Alex Ferguson wrote:
That C++ has a very poor type system.
and Kevin Atkinson wrote in response:
You are going to have to justify it as I thing C++ and Java has a VERY
good type system minus the implicit typing system. In fact I *like* the
C++ typeing system better than I do Haskell's in
This pretends to be the "fair" improved Cryptarithm solver test for
the performance comparison between Haskell and C++.
I thank Fergus Henderson [EMAIL PROTECTED]
for the improvements in the C++ program and for suggesting to use the
list comprehensions in `permutations'
(this saved
Matthias Kilian wrote:
It doesn't. There's no special treatment of constant conditionals, except
that clever (or rather a not totally braindamaged) compiler may be
expected to optimize the unreachable branch away. At least this is what
several Java books say.
Yes, you seem to be right.
Kevin Atkinson wrote:
Do you not like OO at all?
what good is OO for ? ;) OO gives me a framework/language to talk
about objects (read entities) and claims that with objects programmers
have the right tool to model real-world entities.
But the main thing in the real-world are *not* entities,
Levent,
thanks for your explanation. I liked it.
There are a few things I would like to comment.
1) My previous message was mistaken. Sorry. Forget it. I will try
again.
So suppose again the simpler map:: (a - b) - [a] - [b].
Then (in fact) system CT infers that the only possible
Clifford Beshers wrote:
All right, I'll take the bait.
The most important thing is to realize that we are discussing
computations that need to be done at compile time. The results affect
the body of the source code. Right now, the source code is
effectively required to be constant. If
To: [EMAIL PROTECTED]
CC: [EMAIL PROTECTED]
In-reply-to: 7CD674FF54FBD21181D800805F57CD5407956709@RED-MSG-44
(message
from Simon Peyton-Jones on Mon, 4 Oct 1999 03:17:12 -0700)
Subject: Re: CPP is not part of Haskell
References:
Erik Meijer, in his paper "Server Side Scripting in Haskell", FFP, Jan 98
(www.cs.uu.nl/~erik/) claims that his Haskell/CGI library is a part of the
standard Hugs distribution. He also thanks the teams from Yale and
Nottingham for including it as one of the demos in the standard
distribution
On Tue, 5 Oct 1999, George Russell wrote:
Perhaps I'm being stupid. (It certainly wouldn't be the first time!)
But what does OO give me that I can't get with existential types (in
datatype definitions) and multiparameter type classes? The latter seem
to me much more powerful, since I can
Kevin Atkinson:
2) More specific types, you can't _easilly_ call the more general type.
For example in OO this is very commen:
class Base
virtual foo()
do stuff
class Derived, extends Base
foo()
call Base::foo()
doo stuff
You can certainly do this in Haskell;
On Tue, 5 Oct 1999, Theo Norvell wrote:
On Tue, 5 Oct 1999, Kevin Atkinson wrote:
If there is enough interest I could repost this code as well as an
explanation of the many "hacks" I had to due to get around ambiguity
arising fro the use of multiple parameter classes and other
Theo Norvell writes:
On Tue, 5 Oct 1999, Kevin Atkinson wrote:
In case you have not figured out a couple of months ago I posted the
beginnings of a generic container and algorithm collection for
Haskell.
This is exactly the sort of thing that OOP tends to be rather bad at.
How many times
"Hamilton Richards Jr." wrote:
One of the more clear-eyed (IMHO) and successful authors of C++ texts is
Cay Horstmann. A feature of his text, "Mastering C++" (Wiley, 1991), which
I like is the section, appearing at the end of each chapter, entitled
"Pitfalls" (the idea comes from Andrew
Alex Ferguson wrote:
4) Cleaner more natural syntax.
More like C++, you mean?
Or Java. Although many OO things can be done in Haskell C++ and Java
syntax is more natural more doing OO.
If I sound a tad skeptical about some of your suggestions, it may be
because you do seem
Alex Ferguson wrote:
Kevin Atkinson and I argue about C++'s 'Cleaner more natural syntax':
I would like to be able to do the things in Haskell that I can do in C++
but currently Haskell's type system is too simple to allow me to do
them. There are also some things I can't do in C++ but
The source code for the current version of `Typing Haskell in Haskell'
is now available from: http://www.cse.ogi.edu/~mpj/thih/ It is, of
course, written in Haskell 98, and has been tested and developed using
Hugs 98.
For those who don't know, `Typing Haskell in Haskell' is an attempt to
Kevin Atkinson:
3) Encapsulation. You can't have private and protected members. Some
of this can be done using modules. However it is more work.
What exactly can't be done with classes, and how, substantively, is
it more work?
class Foo
private: -- only members of the Foo
Alex Ferguson wrote:
Kevin Atkinson:
I never, ever, said that I would like Haskell to be able to do
everything C++ can.
No, that was my inference from the general drift of your comments.
I also never said that I want Haskell to become a
more type unsafe language. If it was
Alex Ferguson wrote:
Kevin Atkinson, replying to me...
- True ad-doc polymorphism
- Built in dynamic typing system
- State Encapsulation
- A solution to the abilities arising from multi parameter type classes.
- Syntactic sugar for supporting OO programming styles
...
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
Happy 1.6
The LALR(1) Parser Generator for Haskell
This is the nth public release of our parser generator system for
Haskell, called Happy (a dyslexic acronym for 'A Yacc-like Haskell
Parser generator').
What's new in Happy 1.6 (vs. Happy 1.5)
*
29 matches
Mail list logo
