Jerzy Karczmarczuk:
>Dan Piponi adds to a short exchange:
>
>> jerzy.karczmarczuk:
>>> [iso-8859-1] Bj�rn Wikstr�m writes:
>>>
>>> > Hi! I have lots and lots of images (jpegs) that I would like to manipulate
>>> > and shrink (in size). They are around 5 Mb big, so I thought this would
>>> > b
Chris Kuklewicz:
>Stefan Karrmann wrote:
>> Dear all,
>>
>> can ghc compile huge tables into efficient code if they are constant at
>> compile time?
>>
>> Two examples may clearify the question:
>>
>> big1 :: UArray Int Char
>> big1 = array (0,1000) $! map (\i -> (i,toEnum i)) [0..1000]
>>
>>
Hi,
Annotated type systems have been around for some time in static program
analysis. I think this is what you want. For instance, you can design such a
system to record possible side effects from a function call, as annotations
on the type of the function.
See the book "Principles of Program Ana
John Meacham:
>On Wed, Oct 12, 2005 at 12:05:39AM -0400, David Menendez wrote:
>> In principle, you could use seperate types to distinguish floats with
>> different rounding modes, but I imagine this would be difficult or
>> annoying to implement.
>
>I think it would make more sense to have differe
Ben Rudiak-Gould:
>Frederik Eaton wrote:
>> I want the type system to be able to do "automatic lifting" of monads,
>> i.e., since [] is a monad, I should be able to write the following:
>>
>> [1,2]+[3,4]
>>
>> and have it interpreted as "do {a<-[1,2]; b<-[3,4]; return (a+b)}".
>
>The main problem
Jacques Carette:
>Yes, I am aware that this untypeable in Haskell, because polymorphism is
>straight-jacketed by structural rules. But
>in mathematics, it is convenient and extremely common to:
>1) look at the type a -> b as being a *subtype* of b (though I have never seen
>it phrased that
Keean Schupke:
>>A guess is that the first generation will support a shared memory model much
>>like SMP:s of today (shared main memory with on-chip cache(s), or some other
>>kind of local memory (-ies)). Here, I think implicit parallelism in
>>functional languages can be a win in some situations.
I'd like to add my two cents worth in this debate...
I think the original poster considered the standard multicore processors
soon to come, and which can be expected to eventually overtake the processor
market. The answer relies a lot on what shape these processors will have:
A guess is that the
Jerzy Karczmarczuk:
>Jacques Carette wrote:
>
>> John Meacham <[EMAIL PROTECTED]> wrote:
>>
>>> What would be cooler (IMHO) would be brining all of matlabs
>>> functionality into haskell via haskell libraries so one may use 'ghci'
>>> sort of as one uses matlab, but with the advantages haskell brin
( A really interesting post on static elimination of array bounds checking
by Oleg...)
Some questions and suggestions:
What is the relation to the sized types by Lars Pareto and John Hughes?
What is the relation to classical range analyses for (e.g.) array index
expressions, which have been know
Andrew Bromage:
>Pattern matching on the LHS of a function definitions looks, for all the
>world, like a set of rewrite rules. That's because, in some sense, they
>are.
>
>In this definition:
>
>f (x:xs) = 1 + f xs
>f [] = []
>
>Intuitively, the first rule should only "fire" if the express
>From: John Hughes <[EMAIL PROTECTED]>
>Actually the cache behaviour of code generated by GHC isn't at all bad.
>I know because I ran a student project a couple of years ago to
>implement cache-friendly optimisations. The first thing they did was
>cache profiling of some benchmarks, and to our s
> Hi, I would like to know how can I make a spreadsheet using Haskell
> (something like Excel, a very-reduced version, of course)
> Do I need any kind of special library? How can I make the interface so the
> user can introduce data, select data and so on?
> Thanks for your help.
> Miren Cob Isa
>Just a side remark.
>I wonder whether the byte-code approach is the best possible solution
>taking into account the overload of the decoder. Why not threaded code?
>The FORTH (and similar) experience, PostScript implementations, etc.
>show that this paradigm may be more interesting. Anyway, when y
M. Parker:
>What about a port to Windows CE (i.e., for Pocket PC's). Or even better yet,
>hugs for Pocket PC!
>
>-Matt
There is an interesting research question in here: how to design "lean"
implementations of lazy functional languages so they can run on small
handheld and embedded systems with r
Matthew Donadio:
>| Many spectral estimation routines are defined in terms of special
>| matrices (ie, Toeplitz, etc). Arrays defined recursively by list
>| comprehensions make it easy to implement algorithms like
>Levinson-Durbin
>| recursion, and they look very similar to the mathematical defini
Jerzy:
>Me:
>> ...sometimes the length of a list being returned from a
>> function can be a simple function of the function arguments (or the sizes of
>> the arguments), think of map for instance. In such cases, a static program
>> analysis can sometimes find the length function. If we know thee f
Karl-Filip:
>But what I really meant is, if I may rephrase it, that imperative
>programs might often be both faster and harder to write because they
>embed more information about the abblication domain. That is, if you
>code in C and want an array, you must specify its size, so you have to
>thi
Hal Daume III:
>Here's the basic idea. Suppose we have the function:
>
>> sum [] acc = acc
>> sum (x:xs) acc = sum xs (acc+x)
>
>This is tail recursive, but not strict in the accumulator argument.
...
Just a nitpick here. sum is indeed strict in its second argument (given that
(+) is strict in i
Simon:
>Lots of people have observed that Haskell might be a good "scripting
>language" for numerical computation. In complicated numerical
>applications, the program may spend most of its time in (say) matrix
>multiply, which constitutes a tiny fraction of the code for the
>application. So write
Hi again,
My question about my student's problem surely stirred an interesting and
clarifying discussion. Still, I have a question.
Reconsider the example. There's a data type
data LispList t = Atom t | LispList [LispList t] | Str [Char]
and an instance declaration
instance Show t => Show (L
Hi,
For a change, a teacher asking for help on behalf of a student
I have a student who wants to emulate S-expressions of Lisp in Haskell. He
came up with the following data type:
data LispList t = Atom t | LispList [LispList t] | Str [Char]
This works just fine. He then wanted to make it
Marcin 'Qrczak' Kowalczyk:
>Me:
>> Functions themselves are never lifted. They just appear to be lifted
>> when applied to arguments of certain types, and then the function
>> application is always statically resolved into an expression where
>> the function has its original type.
>This does not
Marcin Kowalczyk:
>>Me:
>> No, the transformation is a single step procedure where a term
>> is transformed into a typeable term (if possible) with a minimal
>> amount of lifting. You don't compose transformations.
>So functions implicitly lifted can't be used in the same ways as
>functions origi
>I recently had an idea to allow one to create types from values. This
>would have many uses in Haskell; e.g., it would be very nice to have a
>type of nxn matrices for n that are not necessarily statically
>determined. (It is easy to create a type of matrices and check that
>the sizes are compa
>> >I see. So you can transform arbitrary function of type a->b->c
>> >to a function of type [a]->b->[c], by applying
>> >\f x y -> map (\z -> f z y) x
>> >and similarly a->b->c to a->[b]->[c]. But then there are two ways of
>> >transforming a->b->c to [a]->[b]->[[c]
>
>> There should be no tr
>I see. So you can transform arbitrary function of type a->b->c
>to a function of type [a]->b->[c], by applying
>\f x y -> map (\z -> f z y) x
>and similarly a->b->c to a->[b]->[c]. But then there are two ways of
>transforming a->b->c to [a]->[b]->[[c]] and the order of applying the
>former tr
>> It is quite similar in spirit to the concept of principal type in
>> Hindley-Milner type systems. An expression can have many types but
>> only one "best" (most general) type in that system.
>Now, I'm not any kind of expert on this, but isn't the most general
>HM type one that encompasses the
>> >Also, what is the inferred type of, for example
>> >f x y = x + length y
>> >? It can be
>> >Int -> [a] -> Int
>> >[Int] -> [a] -> [Int]
>> >and neither is more general than the other. And this is a simple
>> >function.
>>
>> Int -> [a] -> Int, since this is the type it will get i
Marcin Kowalczyk:
>Me:
>> A natural principle to adopt is that an already typeable expression should
>> not be transformed. This will for instance resolve the ambiguity in the list
>> of list example: if l :: [[a]] then length l is already well-typed and
>> should not be transformed into map lengt
Marcin 'Qrczak' Kowalczyk:
>>Me:
>> I'd like to point out the connection between the use of +, - on vector
>> spaces and * for scaling with features in some data parallel languages. In
>> these languages, writing a + b where a and b are arrays of numerics is
>> interpreted as elementwise addition
Dylan Thurston:
>Andreas Gruenbacher:
>> It may be the case that using (*) for scaling too is a generally bad
>> idea...
>It may not be type sound to have the same operation, but there should
>be some standard operation for scaling. (Probably you need
>multi-parameter type classes for this.)
I'
>Pardon?
>map is data parallel. foldr not so obviously...
Sorry, a slip on my behalf: foldr in general is not data parallel, but if
the function being folded with is associative then foldr can be implemented
by a parallel (balanced binary-tree) reduction in time O(log n), where n is
the length of
Koen:
>The definitions in the Haskell report are a *specification*,
>not an implementation. It probably depends on the compiler
>which particular implementation runs faster.
>Therefore, the Haskell report provides a clear (yes, this is
>debatable) *possible* implementation, and the compiler
>writ
Tim Sweeney:
>Is this "higher order function application" a useful notion, and does any
>research exist on the topic?
The answer to the first question is "yes, when it matches the intuition of
the programmer". Your two first examples:
>cos+sin-- intent: \x->((cos x)+(sin x))
>cos
> 1) are anyone pursuing this line of work, and
>Sadly, Urban left us for industry (Carlstedt Research and Technology), where
>Thomas Johnsson is also on sabbatical at the moment. So nobody here is
>pursuing this at the moment.
> 2) is the software available?
>Ask Urban: [EMAIL
Me:
>> I think the cleanest solution is to add a method "hseq" to the Eval
>> class, which is similar to seq but evaluates its first argument
>> hyperstrictly before returning its second.
Marcin 'Qrczak' Kowalczyk:
>You mean "implicit Eval"? Then I would certainly not call this solution
>"clean".
>Suppose Sven implements his `len' function as above, and furthermore
>implements a library which depends on this function being hyperstrict.
>Suppose next that I implement an instance of `==' that returns `True' without
>evaluating the arguments, and then finally suppose a third programmer called
Sergey:
>To separate a sublanguage of Haskell given by the corresponding
>compilation key (say, -domExt ) or, maybe, by the compiler pragma.
>This sublanguage allows the compiler to replace any function f with
>the function f' being the extension for f.
This was discussed on the list a w
> Take and drop
> [..]
> I can see three alternatives:
>
> (A) Make them defined for any n. If n < 0, do something reasonable:
> take: give empty list
> drop: give whole list
>
> (B) Make them defined for n > length xs, but fail for n < 0.
>
> (C) Status quo
>
> PROPOSAL: Use al
Me:
>> Yes, it makes a lot of sense. The parallel or above is a classical example
>> of a function for which there exists no semantically correct sequential
>> evaluation order of its arguments (i.e., an evaluation order where an
>> argument is evaluated in full before the evaluation of the next a
>On Mon 27 Sep, Bjorn Lisper (i.e., me) wrote:
>> For instance, a logical or which is strict in both arguments will
>> be commutative and associative, while a nonstrict or with a left-to-right
>> evaluation order of its arguments will be non-commutative but still
>>
Adrian Hey <[EMAIL PROTECTED]>:
>The issue I'm thinking about is equational reasoning and program
>transformation. For a lazy (non-strict) language, transformations
>are constrained so that a function definition which is non-strict
>in an argument is never transformed into one which is strict in t
>Joe Fasel wrote:
>> Actually, I think we were originally thinking of laziness, rather
>> than nonstrictness, and weren't considering languages like Id as
>> part of our domain, but Arvind and Nikhil (quite correctly) convinced
>> us that the semantic distinction of strictness versus nonstrictness
"Manuel M. T. Chakravarty" <[EMAIL PROTECTED]>:
>* While Sisal is arguably nice than Fortran, it doesn't
> really provide a new killer feature - rewriting all this
> Fortran code, just for getting nice programs is maybe not
> enough of an incentive.
As I remember it, a main argument for Sisal
"D. Tweed" <[EMAIL PROTECTED]>:
>I'm quite open to arguments that maybe you can't
>make a functional language that's as nice as Haskell (features like lazy
>evaluation, nice type classes, etc) that's also able to `really hammer
>until it's totally flat' functional code that implements heavily nume
gid as the one that actually is implemented by the code. The problem we
had here earlier, about reordering reductions where the operations are only
"almost AC" (e.g., floating-point arithmetic), is similar. Often one
wouldn't care about the numerical variations resulting from different
reduction orders, but sometimes they could matter.
Bjorn Lisper
may
be nonconfluent.
So Haskell's pattern matching is not precisely the same as term rewriting,
but anyway.
Bjorn Lisper
rings fall within the requirements?
Yes (use lexicographic order), but we don't have them for now.
Bjorn Lisper
enumerable set. It would not be very
sensible to, for instance, try to impose a total order on a set of
functions. A total order of the objects representing the functions would of
course be possible and could be used to have the balanced trees, but it
would not be possible to, say, have a well-defined fold over that kind of
set (or any indexed structure using this set as index set).
Bjorn Lisper
50 matches
Mail list logo
