One such tool is coming up. GHC is producing cost-centre stack logs, which
we feed into Stephen Jarvis's call-graph profile browser. It highlights the
'hot' path for you. It's fantastic!
Our goal is to release it with the next GHC release, but it depends a bit
on Stephen's time.
If this is
Sven Panne <[EMAIL PROTECTED]> wrote,
> 1. Mapping Haskell types to C types
> ===
> Writing C code which gets called via Haskell's FFI is complicated by the
> fact that one needs to know the C types corresponding to Haskell's
Tue, 28 Mar 2000 12:26:34 +1000, Fergus Henderson <[EMAIL PROTECTED]> pisze:
> It would be fine to have a `typedef void *HsStablePtr'. But it is important
> that you do not lose static type information when exporting Haskell functions
> to C. So a parameter of type `StablePtr Int' on the Haskel
On 27-Mar-2000, Sven Panne <[EMAIL PROTECTED]> wrote:
> Yes, C programmers are not that lazy. :-)
>
> > What if you want to pass an unevaluated closure (e.g. so that you
> > can later pass it back to Haskell and then evaluate it)?
>
> This is what stable pointers are for and they are covered by
Good web developers do log analysis to figure out what users like and what
they don't and to figure out which paths to shorten.
It would be nice if haskell programs could generate similar "access
logs" or traces that would feedback to the programmer or maintainer
information about which functions
Sven Panne <[EMAIL PROTECTED]> writes:
> itself and that compound values are a case for a (un-)marshaling
> library. We already have some ideas what this lib should look like
> and some slightly differing modules for this exist, see e.g. C->HS,
> the MPI binding or HOpenGL. Before a design for th
Sven Panne <[EMAIL PROTECTED]> writes:
> 1) Although the Haskell 98 report states that Char should be a Unicode
>character, a plain char is used here. No implementation uses Unicode so
>far, and char is what one wants most of the time, anyway.
HBC uses unicode for source. I'm not sure if
> > 2. I would first like to come back to the type signature
> >
> >f :: a -> b
> >
> > I can say the type of f is a -> b , isn't it?
>
> Well, people often do say that, but it is a little sloppy; if you want
> to be precise, it is more correc
Fergus Henderson wrote:
> On 28-Mar-2000, Fergus Henderson <[EMAIL PROTECTED]> wrote:
> > For prior art, see the `Interfaces.C' package in normative
> > Annex E of the Ada 95 standard (available via www.ada.org).
>
> Sorry, that URL is not correct. In fact that is the American
> Dentists Associa
Fergus Henderson wrote:
> > [...] 1. Mapping Haskell types to C types [...]
> This mapping assumes that you want the unboxed types in C.
Yes, C programmers are not that lazy. :-)
> What if you want to pass an unevaluated closure (e.g. so that you
> can later pass it back to Haskell and then eval
Tue, 28 Mar 2000 02:22:46 +1000, Fergus Henderson <[EMAIL PROTECTED]> pisze:
> This mapping assumes that you want the unboxed types in C. What if
> you want to pass an unevaluated closure (e.g. so that you can later
> pass it back to Haskell and then evaluate it)?
StablePtr is already there.
>
Mon, 27 Mar 2000 16:15:45 +0200, Sven Panne <[EMAIL PROTECTED]>
pisze:
> The time has come for another "final" :-} word on the low-level API for
> Haskell's foreign function interface.
What about the high-level API (apart from C2HS)?
> To solve this problem, every Haskell implementation should
On 27-Mar-2000, Jan Brosius <[EMAIL PROTECTED]> wrote:
> 1. In Haskell there are 2 sorts of variables : variables that range over values of
>a specific type and "type variables".
>
> e.g.in fact n = n * fact (n - 1) (the factorial function n ranges over the values
>of type Int.
>
> and in
"Ronald J. Legere" wrote:
>I dont know how I feel about the specific instances mentioned by
> george, but as a minimalist (or reductionalist, I dont know which) I
> like the idea of at least not adding too much stuff!
> But I do agree about this damn tab business. I have SO MANY TIMES
>
Many thanks for answering my questions.
Actually, I am studiyng the paper
lazy functional state threads
in order to understand the runST function. That's where the type "State" comes from.
I have given a course in logic at the university of Burundi with mathematical set
theory as
On Mon, 27 Mar 2000, George Russell wrote:
> To make indentation less dangerous, any leading blank characters apart from
> plain old simple " " (that means you, TAB) should cause the program to be
> rejected.
I dont know how I feel about the specific instances mentioned by
geo
On 28-Mar-2000, Fergus Henderson <[EMAIL PROTECTED]> wrote:
> For prior art, see the `Interfaces.C' package in normative Annex E of
> the Ada 95 standard (available via www.ada.org).
Sorry, that URL is not correct. In fact that is the American Dentists Association
(ADA) home page, not the Ada pr
On 27-Mar-2000, Sven Panne <[EMAIL PROTECTED]> wrote:
>1) Mapping Haskell types to C types
>2) Mapping C types to Haskell types
These two are a good idea.
For prior art, see the `Interfaces.C' package in normative Annex E of
the Ada 95 standard (available via www.ada.org).
>3) Byte o
On 27-Mar-2000, Jan Brosius <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Suppose a denotes a type variable.
>
> 1.Can I then say: Bool is of type a ?
No. That would be a category error. `Bool' _is a_ type, but it doesn't
_have a_ type.
Only _values_ have types, but `Bool' is a type, not a v
On Mon, 27 Mar 2000, Sven Panne wrote:
[snip]
> Haskell type |C type| ... is probably | Range
> -+--+-+---
> Char | HsChar | char (1)| HsCharMin .. HsCharMax
[snip]
> Remarks:
> ===
The time has come for another "final" :-} word on the low-level API for
Haskell's foreign function interface. It is nothing very deep and most of
it already exists in one form or the other, but I'd like to have some
feedback before I start hacking this into GHC. Additions are proposed in 3
areas:
> (1) The Prelude. If you want a program to print out "2+2",
> you should have
> to import "IO" and a numeric library, say "Integers".
Agreed in principle, but I don't think we should go so far as eliminating
the entire prelude. I'd be in favour of removing (to libraries) everything
that
We attach the second call for contributions for the 2nd Scottish
Functional Programming Workshop, to take place from July 26th to 28th in
St Andrews.
*IMPORTANT NOTE* Participants will be selected on the basis of a 2-page
abstract, to be submitted to us by *April 14th* as noted on the
On Mon, 27 Mar 2000, George Russell wrote:
> We've had numerous suggestions to add things to Haskell. However in
> my opinion many more computer languages (and programs) are ruined by
> too many features, than by too few.
I agree with the principle. My conservatism could be seen several times o
Hi,
Suppose a denotes a type variable.
1.Can I then say: Bool is of type a ?
2. I suppose I can say that True is of type Bool. However True is not
itself a type, isn't it?
I suppose that I cannot say that True is of type a, isn't it ? So True is a
We've had numerous suggestions to add things to Haskell. However in my opinion
many more computer languages (and programs) are ruined by too many features, than
by too few. So here is my own list of things to remove. I realise there is
no chance whatever of it making it into the Haskell stand
On Sat, 25 Mar 2000, T. D. Stones wrote:
> Hello there
>
> I am A 3rd year student at Leicester Uni, and I am doing my project
> using Hugs 1.4. I've noticed that things like EOF
What is it you want to do with EOF?
> (I need to read a file
aha, so why dont you use readFile :: FilePath -> IO
27 matches
Mail list logo
