Re: [Haskell-cafe] FLTK GUI Binding in progress. Call for participation.
On 9/09/2013 7:09 AM, aditya siram wrote: Hi all, I'm working on a FLTK [1] GUI binding [2]. The attraction of FLTK is that there is an existing binding on hackage: hs-fltk library: Binding to GUI library FLTK which I understand is quite serviceable. Perhaps effort could be directed on making improvements (should they be required) to this rather than duplicating existing functionality. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] searching the attic for lambada
I'm interested in resurrecting the idl generator from lambada: http://www.dcs.gla.ac.uk/mail-www/haskell/msg02391.html is the code out there in anyone's attic? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Predictive parser combinators need four values to report errors
I am unable to find a copy of the following paper: Andrew Partridge, David Wright: Predictive parser combinators need four values to report errors. Journal of Functional Programming 6(2): 355-364, 1996 does any one have a copy of, that they could send me ? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Call to arms: lambda-case is stuck and needs your help
On 13/07/2012 3:08 AM, Cale Gibbard wrote:
Personally I don't see why everyone appears to prefer the syntax with
\ in it over just the obvious case section syntax which was originally
proposed.
case of { ... }
looks much better to me than
\case of { ... }
and the former makes sense to me as a simple extension of operator
sections to another part of the syntax.
Does anyone else agree?
yes.
I prefer case of rather than \case of for aesthetic reasons.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] FreeSect -- generalised sections syntax extension
On Wed, Feb 29, 2012 at 9:27 PM, Ras Farras...@gmail.com wrote: Hello, I bit premature perhaps but I wanted to post it on a leap day... http://fremissant.net/freesect Thanks for eyebloom on #haskell for motivating me to finally implement an old idea. Thanks to the rest on #haskell for doing their best to talk me out of it. ;) I make no claims regarding the usefulness of the extension, but some folks might find it interesting, or may just appreciate additional examples of using HSE and SYB. I regret that I am not a better Haskell coder, but it is what it is! Kind Reg'ds, Andrew Seniuk (rasfar) why couldn't you use standard brackets ( to delimit the extent ? I suppose that would have added complexity to the syntax analysis, however I think it would have been (in my mind) neater. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Records in Haskell - namespacing for fields
On 1/02/2012 12:26 AM, AntC wrote:
Simon Peyton-Jonessimonpjat microsoft.com writes:
Beyond that, it would really help namespacing in general to appropriately
extend the module system to allow multiple modules to be declared within a
single file -- or, better yet, submodules. [snip] the added expressive power
should make namespacing issues
much more tractable. [snip] this isn't about implementing records as such --
rather, it's about generally extending the expressive power of the language
so that record systems--among other things--are easier to write.
I’m agnostic about nested modules. In principle they would be a good
thing. However, for the application to records in particular, ...
No! no! no! For records _don't_ put records in nested/sub-modules, and _don't_
require them in separate modules (as currently). Here's how ...
namespace management and record systems are intimately related, but as
you assert distinct issues.
taking your example of Customer_id, I expressly want to be able to
define in the same syntactic module (file). Two records with a field
with exactly the same name at two different types, say Customer_id ::
Int and Customer_id :: String. As I understand it, your proposal
would not enable this.
In reality these two different uses of the name Customer_id are
unrelated and distinct. Some would argue that therefore they should
rightly have distinct names, however that is moot, for the purpose of
this discussion lets take this as the objective.
There are two roads to travel: Customer_id is one semantic entity (in
the sense of an overloaded field, disambiguated by the type system) or
Customer_id represents two distinct semantic entities disambiguated
syntactically. I for one favor the second approach as it matches my
intent, can I say, more faithfully.
[There may be other reasons for nested/sub-modules, but records ain't it.]
as above, however, I believe the best approach is to explore both paths
and perhaps extend Haskell in both directions.
As in your example the particular construction of which suits, the
approach offered in your email better because it matches your intent
more faithfully. It is this ability to match construction with intent
that is critical, which alludes to the notion of the expressivity of a
language.
The reason was hinted at way back in Chris Done's attachment to the original
Records wiki http://hackage.haskell.org/trac/ghc/wiki/Records types in a non-
trivial project.
Let's say I have a database application with a field (meaning type)
customer_id. Then it appears in records for name and address, pricing, order
entry, etc. This is not a name 'clash', it's 'intended sharing'. (It really
galls me to even put it that way for explanatory purposes. Really it's the
**same** customer_id.)
In data model design you'd typically go about identifying all the fields
(types aka attributes) and putting them in a data dictionary. Then you'd
construct your records from them.
You might (possibly) put the data dictionary in a distinct module, for easy
maintenance. But you'd certainly want all the customer-related records in the
same module.
So a data decl:
data Customer_NameAddress = Cust_NA { customer_id :: Int, ... }
is _not_ declaring customer_id, it's _using_ an already-declared field.
(Actually, if you've got any sense, you'll declare:
newtype Customer_id = Customer_id Int
data ... = { customer_id :: Customer_id, ... }
and that takes us to Type-indexed records and then a short hop to anonymous
tuples and polymorphic records and tuple extension/concat/merge and ... one
day!)
The other purpose of the data dictionary is to declare what DBMS's call
the 'domain' of the field (Int in the case of customer_id). The terminology's
going to get a bit confusing here: Haskell's field name (selector functions)
apply to the record as the function's domain, and Int as the result (range).
For Haskell's field selectors we might also want to constrain the records they
can be used in. (For example they must be 'Persist'able so that we can write
them to an external database.)
So, to the proposal (I'm assuming http://www.haskell.org/pipermail/glasgow-
haskell-users/2011-December/021298.html can be made workable. SPJ has been
kind enough to give it a once-over http://www.haskell.org/pipermail/glasgow-
haskell-users/2012-January/021744.html, but of course all faults are the
author's alone.) Specifically, there's to be a class Has with methods get and
set. This is grossly simplified, see the posts):
0.class Has r fld t where-- record r has field fld at type t
get :: r - fld - t
set :: fld - t - r - r' -- update t into r
-- the r' is to cater for type-changing updates
-- it's actually a type function over r fld t
And then:
1. We need -XDisambiguateRecordFields,
so that we can talk about specific record types
Re: [Haskell-cafe] Idris
On 21/01/2012 5:45 AM, Ryan Ingram wrote: Has anyone played with Idris (http://idris-lang.org/) at all? It looks interesting, and I'd love to play with it, but unfortunately I only have windows machines up and running at the moment and the documentation seems to imply it only builds on unixy systems. I'm curious how difficult it would be to get a win32 implementation up and running. -- ryan Idris itself will compile straightforwardly (although there are some shell dependencies that needs to be bypassed), the os dependent stuff is contained in the library epic upon which idris depends, which wraps some c code which is os dependent (#defines and other cruft). The long and short of it is, I have hacked it (both epic idris) to compile on windows. However, I have not debugged it, so that it works properly (I have taken some liberties/shortcuts to get it to compile). I have not had any time to progress this further and probably won't for the foreseeable future. I can make my hacked code available to you, together with my notes. I imagine it would require a couple of days effort to correct and ensure that it works properly, testing it etc (depending on how far you want to go). Contact me off the email list if interested. jvl ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] black Wikipedia
This bill cannot be fixed; it must be killed. - The EFF yes the act is pernicious, and may cause the wholesale relocation of content out of the US, to friendlier places like China, perhaps! ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Generating Code
It occurs to me that c2hs (or more appropriately the gtk2hsc2hs fork) is intended to solve this problem; have you looked into it? hdirect falls into this category as well ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: behaviour change in getDirectoryContents in GHC 7.2?
My primary concerns are (in order of priority - and I only speak for myself) (a) consistency across platforms (b) minimize (unrequired) performance overhead I would prefer an api which is consistent for both win32, posix or other os which only did as much as what the user (us) wanted for example ... module System.Directory.ByteString ... FilePath = ByteString getDirectoryContents :: FilePath - IO [FilePath] which is the same for both win32 and posix and represents raw uninterpreted bytestrings in whatever encoding/(non-encoding) the os providesimplicitly it is for the user to know and understand what their getting (utf-16 in the case of windows, bytes in case of posix platforms) then this api can be re-exported with the decoding/encoding by System.Directory/System.IO which would export FilePath=String ie a two level api... ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: behaviour change in getDirectoryContents in GHC 7.2?
for what it is worth, I would like to see both System.IO and Directory export internal functions where the filepath is a Raw Byte representation. I have utilities that regularly scan 100,000 of files and hash the path the details of which are irrelevant to this discussion, the point being that the locale encoding/decoding is not relevant in this situation and adds unnecessary overhead that would affect the speed of the file-system scans. A denotation of a filepath as an uninterpreted sequence of bytes is the lowest common denominator for all systems that I know of and would be worthwhile to export from the system libraries upon which other abstractions can be built. I agree that for the general user the current behavior is sufficient, however exporting the raw interface would be beneficial for some users, for instance those that have responded to this thread. On 7/11/2011 2:42 AM, Max Bolingbroke wrote: On 6 November 2011 04:14, John Millikinjmilli...@gmail.com wrote: For what it's worth, on my Ubuntu system, Nautilus ignores the locale and just treats all paths as either UTF8 or invalid. To me, this seems like the most reasonable option; the concept of locale encoding is entirely vestigal, and should only be used in certain specialized cases. Unfortunately non-UTF8 locale encodings are seen in practice quite often. I'm not sure about Linux, but certainly lots of Windows systems are configured with a locale encoding like GBK or Big5. Paths as text is what *Windows* programmers expect. Paths as bytes is what's expected by programmers on non-Windows OSes, including Linux and OS X. IIRC paths on OS X are guaranteed to be valid UTF-8. The only platform that uses bytes for paths (that we care about) is Linux. I'm not saying one is inherently better than the other, but considering that various UNIX and UNIX-like operating systems have been using byte-based paths for near on forty years now, trying to abolish them by redefining the type is not a useful action. We have to: 1. Provide an API that makes sense on all our supported OSes 2. Have getArgs :: IO [String] 3. Have it such that if you go to your console and write (./MyHaskellProgram 你好) then getArgs tells you [你好] Given these constraints I don't see any alternative to PEP-383 behaviour. If you're going to make all the System.IO stuff use text, at least give us an escape hatch. The unix package is ideally suited, as it's already inherently OS-specific. Something like this would be perfect: You can already do this with the implemented design. We have: openFile :: FilePath - IO Handle The FilePath will be encoded in the fileSystemEncoding. On Unix this will have PEP383 roundtripping behaviour. So if you want openFile' :: [Byte] - IO Handle you can write something like this: escape = map (\b - if b 128 then chr b else chr (0xEF00 + b)) openFile = openFile' . escape The bytes that reach the API call will be exactly the ones you supply. (You can also implement escape by just encoding the [Byte] with the fileSystemEncoding). Likewise, if you have a String and want to get the [Byte] we decoded it from, you just need to encode the String again with the fileSystemEncoding. If this is not enough for you please let me know, but it seems to me that it covers all your use cases, without any need to reimplement the FFI bindings. Max ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] How to implement digital filters using Arrows
I can't comment on using ghci debugger to observe evaluation. I have in the past used hood (http://hackage.haskell.org/package/hood) and found it both convenient and useful when trying to observe evaluation order. On 2/11/2011 7:00 AM, Captain Freako wrote: Hi John, I'm trying to use the GHCI debugger on this code: 20 instance ArrowLoop SF where 21 loop (SF f) = SF $ \as - 22 let (bs, cs) = unzip (f (zip as (stream cs))) in bs 23 where stream ~(x:xs) = x : stream xs 24 25 swap :: (a,b) - (b,a) 26 swap (x,y) = (y,x) in order to watch the recursion of the `loop' function unfold. However, when I single step through the code, I never stop on line 22 (where I could, presumably, peek in at `bs' and `cs', in order to see them develop): ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to implement digital filters using Arrows
On 1/11/2011 1:35 AM, Captain Freako wrote: you need to study ArrowLoop and understand that. In the code rec (y,s')- arr f - (x,s) s- delay s0 - s' the state is 'captured' in the recursive binding. i.e. just like in real circuits the output state s is threaded back as an input. The recursive binding is just sugar for the application of the loop combinator. The signature of the loop combinator is loop :: arrow (input, feedback) (output, feedback) - arrow input output with the loop combinator (with which recursive arrow bindings are defined) the function could have been defined as... liftAu f s0 = loop (second (delay s0) arr f ) the delay is neccessary to break the recursion. i.e. to calculate the next output and state the previous state is used. liftAu :: ((x,FilterState s)-(y,FilterState s)) - FilterState s - FilterAu x y liftAu f s0 = proc x - do rec (y,s')- arr f - (x,s) s- delay s0 - s' returnA - y I think I understand how the `returnA' in the last line of your `liftAu' function is getting translated by those instance definitions into: c where c = Automaton ( arr id arr (const c) ) and, furthermore, how that is passing the supplied `y' into the first element of the resulting couple. However, I don't understand how the recursively defined `c' is capturing the modified filter state and preserving it for the next call. It seems like the Automaton being referred to by `c' is a newly constructed entity, which knows nothing about the current state of the running Automaton. Any help in understanding this would be greatly appreciated. Thanks! -db ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to implement a digital filter, using Arrows?
On 21/10/2011 3:00 AM, David Barbour wrote: the f in (Automaton f) is a pure funtion runAuto is deconstructing the arrow by pattern matching then applying the function to the input to obtain the result and the continuation. i.e. runAuto takes an arrow and applies it to a value. On Thu, Oct 20, 2011 at 5:19 AM, Captain Freakocapn.fre...@gmail.comwrote: Hi David, I was referring to the `f' in the `runAuto' function, not the `liftAu' function. -db Ah, I see. You quoted one thing and spoke of another, and I got all confused. Keep in mind that functions are arrows (instance Arrow (-)). type FilterAu b c = Automaton (-) b c runAuto :: FilterAu b c - [b] - [c] runAuto a [] = [] runAuto (Automaton f) (x:xs) = let (y,a) = f x in y:runAuto a xs ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to implement a digital filter, using Arrows?
On 20/10/2011 5:11 AM, Captain Freako wrote: for your use case then, the StateArrow seems more appropriate as it provides you with the final state. Ofcourse the Automaton arrow could also be used: liftAu' f s0 = proc x - do rec (y,s') - arr f - (x,s) s - delay s0 - s' returnA - (y,s) this explicitly returns the state with evry value. However, you then need to manually thread the state through. note: the arrow plumbing is only used when you start composing filters, with arrow combinators. If your not doing any composition as such then lifting your functions into the arrows is not buying you much. John Lask wrote: This is literate code. It expounds on your initial question and provides two solutions based either on the StateArrow or Automaton (Remainder omitted.) John, Thanks so much for your help! I'm going to study your example code and try to understand how the Automaton implicit plumbing is being used. (I'm determined to get my head around this arrow concept, damn it! ;-) ) I wonder if I might pester you for the final piece of the puzzle here: When the processing of the input stream through the filter is complete, I need to pass the final filter state, along with the output stream, back to the calling program. (This is because the calling program is going to split the input signal into conveniently sized chunks, calling my filter routine several times, in order to process the entire input stream. It expects to be able to pass an initial filter state into my routine, which is just the final state of the filter that I passed back to it after the previous call. In this way, we avoid inserting any edge artifacts at the input stream segmentation boundaries.) So, is it possible to `fetch' the final state out of that Automaton, when it's finished processing the input list? Thanks! -db ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to implement a digital filter, using Arrows?
{-# LANGUAGE Arrows #-}
This is literate code. It expounds on your initial question and provides
two solutions based either on the StateArrow or Automaton
module Test where
import Data.List ( mapAccumL )
import Control.Arrow
import Control.Arrow.Operations
import Control.Arrow.Transformer
import Control.Arrow.Transformer.State
import Control.Arrow.Transformer.Automaton
this later formulation corresponds to Control.Arrow.Transformer.State
data FilterState a = FilterState {
as :: [a] -- transfer function denominator coefficients
, bs :: [a] -- transfer function numerator coefficients
, taps :: [a] -- current delay tap stored values
}
-- Time domain convolution filter (FIR or IIR),
-- expressed in direct form 2
convT = \(x, s) -
let wk = (x - sum [a * t | (a, t)- zip (tail $ as s) (taps s)])
newTaps = wk : ((reverse . tail . reverse) $ taps s)
s' = s {taps = newTaps}
y = sum [b * w | (b, w)- zip (bs s) (wk : (taps s))]
in (y, s')
we can construct the type of a Filter as a state arrow with state
(FilterState s) and base arrow type of (-)
type FilterSt s b c = StateArrow (FilterState s) (-) b c
to lift the function convT to a state arrow it would be very
easy if the constructor were exported (ie. ST convT), however it is not. So
we define a custom lift to lift functions of the above type into the arrow
liftSt :: ((x,FilterState s)-(y,FilterState s)) - FilterSt s x y
liftSt f = proc x - do
s - fetch - ()
(y,s') - arr f - (x,s)
store - s'
returnA - y
then to fold the arrow over a list of inputs
runFilterSt :: FilterSt s b c - (FilterState s) - [b] -
(FilterState s , [c])
runFilterSt f = mapAccumL (curry (swap . runState f . swap))
where
swap (a,b) = (b,a)
t1 = let
s = FilterState [1,0,0] [0.7, 0.2, 0.1] [0, 0, 0]
in snd $ runFilterSt (liftSt convT) s [1,0,0,0,0]
*Test t1
[0.7,0.2,0.1,0.0,0.0]
except I am not sure you want a state arrow as that propogates the state
through all arrows. eg in a b, the state modified by a passes to b
and so on.
This would only be any good if all your filters shared/modified the same
state.
the initial suggestion was to use an automaton arrow which isolates the
state
in each arrow.
type FilterAu b c = Automaton (-) b c
liftAu :: ((x,FilterState s)-(y,FilterState s)) - FilterState s -
FilterAu x y
liftAu f s0 = proc x - do
rec (y,s') - arr f - (x,s)
s - delay s0 - s'
returnA - y
runAutomaton is a bit cumbersome, so define a custom run function that
takes a list
runAuto a [] = []
runAuto (Automaton f) (x:xs) = let
(y,a) = f x
in y:runAuto a xs
t2 = let
s = FilterState [1,0,0] [0.7, 0.2, 0.1] [0, 0, 0]
in runAuto (liftAu convT s) [1,0,0,0,0]
*Test t2
[0.7,0.2,0.1,0.0,0.0]
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to implement a digital filter, using Arrows?
your function corresponds with Control.Arrow.Transformer.Automaton. If you frame your function is such most of your plumbing is taken care of. http://hackage.haskell.org/packages/archive/arrows/0.4.1.2/doc/html/Control-Arrow-Transformer-Automaton.html On 18/10/2011 1:46 PM, Captain Freako wrote: Hi all, If I have a pure function, which maps `(input, initialState)' to `(output, nextState)', what's the most succinct way of constructing a digital filter from this function, using Arrows? Thanks, -db ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: GHCJS
What is really required is a pluggable back-end infrastructure - whereby various back-ends could be maintained (or not) at the discretion of their originators and separate to the official ghc back-ends. Ideally pluggable back-ends would be installable as packages. such infrastructure, I would hazard a guess, would require considerable thought to design properly. On 3/08/2011 11:19 AM, Brandon Allbery wrote: On Tue, Aug 2, 2011 at 21:09, Edward Z. Yangezy...@mit.edu wrote: Excerpts from Victor Nazarov's message of Tue Aug 02 19:12:55 -0400 2011: But GHC always emit parse error on javascript keyword. For now I'm using (abusing) ccall calling convention and simple imports works pretty well, but I would like to support exports and static/dynamic wrappers. GHC generates C-code to support them, and GHCJS should generate Javascript-code, but I have no idea how to use GHC API to generate custom (Javascript) stubs. Is it possible at all? That is certainly not; you'll need to patch GHC's lexer to do that. But it's all a bit dodgy since this FFI doesn't make sense unless you are generating Javascript code (which GHC is not.) Maybe someone else can comment on that. (Perhaps we need fully extensible calling convention syntax? Hmmm!) If making it a backend isn't acceptable then it's a bit of a lost cause; I'd expect it to be a backend, with backend hooks to support various -f* options (probably already exists) and the foreign syntax changed from expecting a keyword to expecting an identifier and optional parenthesized identifier list (the same syntactic category as import and export lists, deriving clauses, etc.), and that would be passed to the backend. I'd like to create ghcjs and ghcjs-pkg tools that will use their own directories and package index and will not interfere with ghc. Is it possible with GHC API? How can I do it? Check out the approach that cabal-dev uses, which is about what you are looking for here. (Though, handling base packages might be tricky.) And I'd point out that this sounds similar to another recently reported shortcoming of ghc-pkg (mentioned in the context of cabal's dependency calculations but I miscall the details at the moment). I would expect JS packages to register a dependency on a version of base specific to the JS backend, and that dependency would prevent libraries using the standard base package from being considered. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHCJS
On 3/08/2011 2:10 PM, Brandon Allbery wrote: On Wed, Aug 3, 2011 at 00:31, John Laskjvl...@hotmail.com wrote: What is really required is a pluggable back-end infrastructure - whereby various back-ends could be maintained (or not) at the discretion of their originators and separate to the official ghc back-ends. I guess I'm confused; I thought the current back-end system *was* that kind of pluggable architecture. I recall a JVM backend being proposed based on it some time back. my thoughts of pluggable infrastructure include consideration of ffi bindings and library integration as well as command line options i.e. as discussed in this thread with respect of GHC-JS, rather than just backend code generation - i.e. considerations of broader scope than those currently handled. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] ANN: mecha-0.0.5
On 6/06/2011 3:58 AM, Tom Hawkins wrote: Another goal of the project is to generate 2D prints from 3D models. Any idea how hard is this going to be? Basically it needs to identify features (holes, edges, etc), then project these features to an orthographic plane, alone with associated dimensions. are you familiar with Jan Sabinski's solid modelling in Haskell http://web.archive.org/web/20010605003250/http://www.numeric-quest.com/haskell/ he implements 3D projects onto 2D plane (although no feature selection etc) and is more a proof of principle. if you are interested in industrial strength solutions, I can recommend the openCascade (http://www.opencascade.org/) library. A Haskell binding would be very useful and something that I have thought about doing for some time, but alas had no time for. jvl ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Status of Haskell + Mac + GUIs graphics
On 19/05/2011 10:31 PM, Heinrich Apfelmus wrote: my comments for what their worth: (1) wx and ghci: I successfully run wx in ghci (albeit) on windows. I take an alternative path to that proscribed by the current build process - I think principally so that I am able to run it in ghci, although I can not now recall the exact reason why I took the different route. The current build process links the haskell wxcore library against the wxwdigets libraries directly. Once upon a time, the wxlibraries were wrapped as a C (dll) library, and the haskell libraries linked against this. I choose this route, and have no problems loading wxwdigets applications in ghci (on windows) ... and using OpenGL with them. (2) on the question of GUI libraries in general. I remind readers that the discussion of a GUI for haskell is no new thing, (cf. GUI API Taskforce) http://www.haskell.org/pipermail/haskell/2001-September/007960.html http://comments.gmane.org/gmane.comp.lang.haskell.gui/7 ... and many more ... a lot of which has been said recently, has been said before (it does not make it less relevant, though) ... there are two very different responses, the tactical and the strategic, they generally have very different time frames and cost (effort) required. A tactical response might be to ensure that one of the (many) currently existing libraries (wxHaskell, qtHaskell, hs-fltk...) built and operated problem free on all platforms. Whereas, a strategic response might be to have a cross platform gui library binding to low level platform libraries (Win32, X11, Cocoa) Of course there are all sorts of variants in between. A general problem with strategic response is they underestimate the effort required due to the long range horizon and the uncertainties involved. if the question is what will provide me with the tools that I need today or tomorrow, which is the more efficacious response? Conal Elliott wrote: Last I heard, wx still had the problem of crashing its host the second time one opens a window (which is typical in ghci). And last I heard, Jeremy O'Donoghue (cc'd) was exploring solutions but had very little time to pursue them. - Conal Last I remember, the latest problem is that ghci is unable to link libstdc++. But the crash problem is probably still there. Best regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Open CV or alternate image processing library for Haskell on windows?
On 18/05/2011 2:02 PM, Ville Tirronen wrote: Hello, I have successfully* built HOpenCV on windows with openCV 2.0 on windows (XP). * by successfully, I mean compiled and linked, library and test.hs. The test did give me an error: test-hopencv.exe: user error (Failed to create camera) which, I have not bothered to follow up any further. The build process was as follows (your paths will differ): 1) I installed openCV to C:\apps\OpenCV2.0 2) I unzipped HOpenCV-0.1.2.2 to some directory 3) edited cabal file edited the following entries to include-dirs: c:\apps\OpenCV2.0\include\opencv extra-lib-dirs: c:\apps\OpenCV2.0\lib and also edited the extra-libraries to ... extra-libraries: highgui200, cv200, cxcore200 4) then set Path=%PATH%;c:\apps\OpenCV2.0\bin unless when installing OpenCV you added the install path to your path.. 5) then ghc Setup build --hsc2hs-options=-L -Wl,-( the --hsc2hs-options=-L -Wl,-( option is neccessary in order to ovoid errors like dist\ghc\6.12.3\build\AI\CV\OpenCV\CV_hsc_make.o:CV_hsc_make.c:(.text+0x85a): un defined reference to `cvFree_' for some reason (and I really can't understand why) gcc requires the highgui200, cv200, cxcore200 libraries after the object (normally dosn't) and the -L -Wl,-( instructs hsc2hs to pass -Wl,-C to gcc, which in turn instructs gcc to pas -( to the linker which in turn tells the linker to re-read the libraries to resolve the references. (somewhere something is going wrong) 6) run the test ... Hi, Yes, I understand that - but if there is some install or usage dependency, or install procedure, I would hope to see it documented somewhere; perhaps I missed that? The only installation procedure I can document is how to do this in linux. My guess is that it must be similar with windows. 1. Get the opencv library from opencv.willowgarage.com 2. Install it and make a note where it installs 3. cabal install CV. If this fails with missing C libraries, then, (4). cabal install CV --with-extra-lib-dirs=where_the_opencv_libs_are --with-extra-include-dirs=where_the_opencv_includes_are However, wait few hours so I can push a new version to hackage. There are few things I've already discovered that fail to work with other people and I think I can fix them. Disclaimer: The CV package is something I threw together, originally in pre-cabal times. Back then I arguably wasn't a very good haskell-programmer and the whole thing was under an nda. Since then I've casually evolved the library to suit my needs. After I saw CV-combinators library released I made a petition to publish my codes in hopes that it would help other people doing similar things. In short, although CV package is very very useful for me, it is not a perfect binding, and the implementation isn't really smart at places. I would like to make it great, however. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
ghc trac login and email verification
relating to the ghc trac discussion ... for some time I have had a ghc trac login, but every time I login it asks for an email verification token (http://hackage.haskell.org/trac/ghc/verify_email) but no token has ever been sent to me, nor when I change my email or request a resend is one sent. I am convinced that there is something wrong with the ghc trac config. http://hackage.haskell.org/trac/ghc/trac/ghc/register is broken as well. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] GPL License of H-Matrix and prelude numeric
On 26/01/2011 1:52 PM, Ivan Lazar Miljenovic wrote: In which case, why not ask the author(s) directly rather than blindly asking the mailing list? others, such as I, may be interested in the answer. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] getDirectoryContents and sort order
I have noticed that on my windows box and ghc 6.12.3 I get the return list for System.Direcotry.getDirectoryContents in reverse sorted order. This is a change from previous observed behavior and I would consider it a bug. I would like to verify that it is not just me. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Zipper with two focii for concurrent fun
see http://okmij.org/ftp/continuations/Continuations.html, Zipper-based file server/OS, aka ZFS where Oleg addresses concurrent operations on a shared data structure with multiple mutable cursors implemented via delimited continuations with varying isolation levels ... your issues are specifically addressed. jvl On 17/01/2011 5:20 PM, Yaakov M. Nemoy wrote: Hey List, So i've been pondering zippers in a concurrent situation, where more than one thread has access to the same data structure, but with different focal points. I've gotten a bit stuck though trying to figure out how to do this using a zipper. The use case i'm thinking of is slightly more complex, but using a basic example below should suffice for an explanation. Say we have a list of characters in a text file which we're using in the form of a zipper to show the current user's cursor position in the text file. This means a data type such as: data ZipperList a = ZL [a] a [a] where the second element is the current position of the cursor. Now as long as one user is editing the text file, we're fine. Now let's say we're working on a newfangled multipointer desktop where two users have a keyboard and mouse each and want to work on the same open file. We could have a list like this: data ZipperList a = ZL [a] a [a] a [a] which leaves us with a number of limitations. We're now limited to two cursors rather than one, but once we start assuming multipointer, two seems like a bigger limitation than just one cursor. Also, we can't tell which user is at which focal point of the zipper easily. We could replace the user with: data User a = User String a data ZipperList a = ZL [a] (User a) [a] (User a) [a] but that gets into some ugly pattern matching. It still leaves us stuck with a two user limit. Say we create a zipper that can contain other zippers. Such as: data ZipperList a = ZL (ZipperList a) a (ZipperList a) | L [a] which lets us include as many users as we want. Now this creates a very different problem. Each cursor in our fictional text editor has a totally different data structure. This is how any calculation at any cursor knows where in the text file it is. If one user edits the character at the cursor, every other zipper-like data structure has to be updated for each other users. Thus a huge concurrency issue. This is where i hit a block. Am i totally crazy in thinking i can solve this problem using a zipper? Or has someone thought about this problem already and perhaps there's even a paper on it? Please advise. -Yaakov ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Type Directed Name Resolution
On 11/11/2010 5:21 PM, Ketil Malde wrote:
Richard O'Keefeo...@cs.otago.ac.nz writes:
it is often desirable to have the same field names
for many records in the same module.
very much so, this is currently possible, with the restriction that
the field names must have the same type modulo the record it is
selecting on.
what is disirable is that this restriction be lifted.
I'm not sure that it is desirable to have many records in the
same module in the first place.
this should really be a choice of the programmer.
One possibility might be to allow mulitple module definitions in the
same file, making it easier to wrap each record in its own module
without running into a Java-like forest of files.
a module represents a compilation unit which happens to be a file, in
haskell it also represents a name space and a means for control of that
namespace. Compilation units and name space management are orthoganal
issues although obviously connected. SML for example manages the name
space with Functors and does not explicitly name the compilation units,
haskell names the compilation units i.e. modules, but I have had some
thoughts along the same lines, myself, more on this later ..
discussion of the haskell record system and syntax has a long history,
just a quick search ...
http://www.mail-archive.com/hask...@haskell.org/msg17725.html
http://www.haskell.org/pipermail/haskell-prime/2006-March/000836.html
http://www.mail-archive.com/hask...@haskell.org/msg13394.html
http://www.mail-archive.com/hask...@haskell.org/msg20516.html
in 2003
http://research.microsoft.com/en-us/um/people/simonpj/Haskell/records.html
I quote
Haskell lacks a serious record system. (The existing mechanism for
named fields in data types was always seen as a stop-gap measure.) At
the 1999 Haskell Workshop, Mark Jones and Simon Peyton Jones proposed a
more fully-fledged record system, closely modelled on the TRex system
implemented in Hugs. But Simon never got around to implementing it in
GHC. Why not? Mainly because the implementation cost turned out to be
relatively high.
.. in the intervening years we have GADTS, type families, associated
types tec ... but with respect to records what has changed ?
In my mind, the feature that I most wish for, and what haskell lacks is
the ability to manage the module name space with respect to record label
names. Yes, I often want to define a record with the same label name at
a different type.
many languages have a construct with record which unqualifies the
names introduced by the record definition, those names being implicitly
qualified when defined. Haskell label names are implicitly unqualified.
I have often thought that a minimal extension to Haskell compatible with
the current record system that could ameliorate the situation would be
data Foo = Foo { label1 :: Int, label2 :: String } qualified
where such a qualified data declaration would hide labels label1 and
label2, making the available only as Foo.label1, Foo.label2., etc
where we have a qualified record we should be able to unqualify it as
import data Foo
or rename it
import data Foo qualified as Bar
which would introduces Bar.label1, Bar.label2
etc.
None of the above is incompatible with the current record system and
introduces no new keywords. This proposal solely addresses the issue of
name space management.
(I've proposed this before, and although I don't remember the specifics,
ISTR the response being mostly negative.)
-k
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Better Records was Re: [Haskell-cafe] Type Directed Name Resolution
If the outcome of this discussion is a clamour for better records instead of TDNR, then that would certainly make me happy. Regards, Malcolm well I certainly am clamouring for better records. This motivated my original reply this post. The trouble is, what constitutes better records? There are as many views as users of Haskell, I bet. My main motivation is: As mentioned in my original post: better name space management. Surprisingly enough, I find the current record system is quite usable, bar one feature. My particular use case: commercial applications make heavy use of records (in connection with relational databases) and name clashes are inevitable. As I tried to point out in my original post, issues of name space management are orthogonal to the type system, but obviously related as the type system in Haskell is used to distinguish names. The thrust of discussion and work on the record system, in so far as Haskell has been concerned, has been at the type system level, an necessarily so: work on representing the has a relation, extensibility etc at the type level. Some relatively usable libraries have been developed that provide this support (eg HList). none of this can address my particular issue: name space management, that is, managing the scope of record labels. The type system is not the solution to all problems. Hence my proposal. I don't envisage that my issue will be addressed anytime soon, if at all. But by raising it I hope to broaden the focus of the discussion. The trouble with any rework of the current record system: which way to take it ... the design space is large what would users want ... - light weight records (c.f. ML) - first class labels (accessors and setters) - extensible records - sub-typing or in my case - better name space management perhaps given the many avenues for exploration of type system support for record systems, we could make use of existing libraries with rebind-able syntax?? again quoting http://research.microsoft.com/en-us/um/people/simonpj/Haskell/records.html Haskell lacks a serious record system. (The existing mechanism for named fields in data types was always seen as a stop-gap measure.) isn't it about time this changed? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Type Directed Name Resolution
On 12/11/2010 9:22 AM, Richard O'Keefe wrote:
On 12/11/2010, at 2:17 AM, Michael Snoyman wrote:
So why would you ever need to reuse the same field name in the same
module?
data PetOwner
data FurnitureOwner
data Cat = Cat { owner :: PetOwner }
data Chair = Chair { owner :: FurnitureOwner }
Just the first thing that came to mind, this kind of thing comes up
often enough to be an irritant. I'm not sure whether or not TDNR is a
good solution to the problem, just pointing out a use case.
I'm afraid it's not a *convincing* use case.
It's not convincing because here owner *means different things*.
consider length ...
I have records with the attribute length, length can be given as an Int,
Double, Float or maybe as a constructed type Length, length's use as a
record selector would also clash with List.length. All these have the
same denotation.
should I then seporate into int_length, float_length, or use
rec1_length, rec2_length etc etc...
for proper name space management why should I have to define each record
that defines a length field with different representation in distinct
modules, or with different names for the field label when they denote
the same thing?
This is easily handled in C, Pascal, PL/1, Cobol why not in Haskell ?
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Fwd: Re: [Haskell-cafe] Type Directed Name Resolution
On 12/11/2010, at 2:16 PM, John Lask wrote: On 12/11/2010 9:22 AM, Richard O'Keefe wrote: I'm afraid it's not a *convincing* use case. It's not convincing because here owner *means different things*. consider length ... I have records with the attribute length, length can be given as an Int, Double, Float or maybe as a constructed type Length, length's use as a record selector would also clash with List.length. All these have the same denotation. All these have the same denotation? I am extremely confused here. AH! You mean you call them all by the same name. Well yes, that's the problem, right there. I remind readers once again that in SML record selectors *don't* clash with names of functions. I am not concerned here to argue either for or against SML-style records and their selectors, only to point out that wanting *record fields* whose significance depends on the record they select from is *NOT* the same thing as TDNR in principle, so that arguments for that don't even come close to being arguments for TDNR as such. should I then seporate into int_length, float_length, or use rec1_length, rec2_length etc etc... No, the differing result types are an epiphenomenon of their differing semantics. The length of a piece of string is a physical length. length of string measured in CM's, in MM, in Inches, as an Int, float ... they all denote the same thing modulo some theory. You could argue that a length in CM's measured as a float is semantically different to that of CM's as an Int, which it is, but somewhere along the line those semantic differences become irrelevant to the abstract domain of application, your model, and it is that model that you wish to represent as a program, although you need to deal with the concrete differences as an implementation detail. The length of a lecture is a time. The length of a queue is a natural number (counting people). The length of a book is a positive integer (counting say pages, or words) The length of a vowel is a relative time. These quantities are measured differently, combined differently, and assessed differently. Calling them all length is a METAPHOR. (There are at least three metaphors in the list above: time-is-space, codex-is-scroll, and a form of metonomy.) for proper name space management why should I have to define each record that defines a length field with different representation in distinct modules, or with different names for the field label when they denote the same thing? But you just explained that while they may have the same denotation (the identifier), what it DENOTES is NOT the same (otherwise they could not be different types). you are right As SML proves, having record-sensitive field names is a *different* question from Type Directed Name Resolution applied to plain function names. agreed This is easily handled in C, Pascal, PL/1, Cobol why not in Haskell ? But it *isn't* handled *AT ALL* in any of those languages, let alone handled easily. In C, Pascal, PL/I, and COBOL field names are *not* values. C, Pascal, and PL/I let you pass functions as parameters to functions. But you cannot pass field names that way. The only thing you can do with a field name is apply it *immediately* to a record. And those languages don't have type variables, so when you apply a selector to a record, you know then and there what the type is. If what you want is some sort of record facility at least as good as SML's, fine. What I am arguing against is anything resembling Type Directed Name Resolution (alias ad hoc overloading) being applied to plain ordinary functions. that's something like what I want. I am not argiung in favor of TDNR, only that haskell record system needs improvement, particularly the scoping of field labels. (By the way, if the field names of a record type are visible outside its module, I start wondering why.) depends on what your using them for .. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Fwd: Re: [Haskell-cafe] Type Directed Name Resolution
On Thu, Nov 11, 2010 at 8:16 PM, John Laskjvl...@hotmail.com wrote:
consider length ...
I have records with the attribute length, length can be given as an Int,
Double, Float or maybe as a constructed type Length, length's use as a
record selector would also clash with List.length. All these have the same
denotation.
should I then seporate into int_length, float_length, or use rec1_length,
rec2_length etc etc...
class Lengthy a where
type LengthType a
length :: a - LengthType a
This extends easily to lenses if you want setters.
to make use of the class Lengthy I still need to define record selectors
with different names, which is exactly the point I am making...
ie
data Record = RecLen { rec_length :: ... }
instance Lengthy Record where
length = rec_length
This is easily handled in C, Pascal, PL/1, Cobol why not in Haskell ?
By this argument, Haskell should provide global mutable state and
allow side-effects universally.
no, but these languages have their strengths as well, for example Cobol
PIC strings format currency values very nicely and it would be great if
there were a Haskell library that could do the same. Not to mention
currency values!
The point is that languages are often constructed with a purpose in
mind, at which they tend to be particularly good. Haskell has
traditionally been a test bed for type system innovation, which is why
we all like it so much.
As and if, the usage of Haskell broadens, then domains of application
stray into areas of application for which it is not ideally suited, in
those circumstances why not consider features of other languages which
handle those use cases well. (for some definition of well)
By the way I am not arguing for TDNR, merely that all is not well with
haskell records.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What is simplest extension language to implement?
On 2/11/2010 9:05 PM, Steffen Schuldenzucker wrote: On 11/02/2010 10:40 AM, Yves Parès wrote: Because he would have either to recompile the whole program or to use things like hint, both implying that GHC must be installed on the user side (600Mo+ for GHC 6.12.3) Isn't there a way to use some stripped-down version of ghc and the base libraries, providing only what the user really needs, in versions which are known to work, and supply that together with the application? there is hugs, which is a small, fast haskell interpreter. It is embeddable ( exposes a C api for embedding - it is written in C), supports many language extensions and can be stripped down (in terms of libraries) as far as you like, but is now often forgotten, overlooked in so far as haskell implementations go. I'd love to use haskell as a configuration language, provide some combinators and effectively get the rest for free. But it is not acceptable for a user to go through the mess of installing a ghc environment on, say, Windows, only to change some settings. 2010/11/2 Lennart Augustsson lenn...@augustsson.net mailto:lenn...@augustsson.net I don't understand. Why don't you use Haskell as the scripting language? On Tue, Nov 2, 2010 at 7:04 AM, Permjacov Evgeniy permea...@gmail.com mailto:permea...@gmail.com wrote: Let us think, that we need some scripting language for our pure haskell project and configure-compile-run is not a way. In such a case a reasonably simple, yet standartized and wide known language should be implemented. What such language may be? R(4/5/6)RS ? EcmaScript ? Some other ? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org mailto:Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org mailto:Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Will GHC 6.14 with LLVM use LLVM C compiler to compile external C Libraries
I am not that familiar with LLVM, if anything it complicates matters, rather than making things easier. The llvm-ld program has limited support for native code generation, when using the -native or -native-cbe options. Native code generation is performed by converting the linked bitcode into native assembly (.s) or C code and running the system compiler (typically gcc) on the result. so it seems that the gcc support infrastructure that is currently integrated into ghc will still be required. Then the question arises what library formats will ghc use under the circumstances ?(.bc, .a) and how will the two be integrated? On windows, most c/c++ public domain libraries are either compiled with ms-c or gcc which have their standard library formats. which in many cases come pre-compiled with the libraries. Becuase of this I would assume retention of the .a format, but perhaps compiling haskell to .bc would offer opportunities for link time optimisation? In fact I would like a lot more information on what is being proposed with respect of a LLVM backend and any changes to the compiler tool chain. Since GHC 6.14 will (hopefully) be use LLVM as a default backend, an idea has occured to me Should GHC also use the clang (C/C++-LLVM compiler) on external C library sources which are used with certain Haskell packages (such as gtk) when LLVM does become a default backend for GHC. The consensus is that since Clang will also produce LLVM 'assembler', it can be very easily linked with the LLVM 'assembler' produced by GHC's LLVM backend, making the process of using external C sources a lot easier. Parts of Clang required could even be integrated into GHC (although this may be tricky since its coded in C++). It should also hopefully make using Haskell packages on windows that use C sources less painful Clang could also make using FFI with C++ much easier (for reasons stated above) Thoughts? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] feasability of implementing an awk interpreter.
On 20/08/2010 1:35 PM, Jason Dagit wrote: fairly easy .. you might want to check out the following tutorial ... http://www.crsr.net/Programming_Languages/SoftwareTools/ch5.html he implements a basic grep tool, you might then want to check out one of the regex packages as a basis for your implementation of awk. On Thu, Aug 19, 2010 at 8:05 PM, Michael Litchard mich...@schmong.org mailto:mich...@schmong.org wrote: I'd like the community to give me feedback on the difficulty level of implementing an awk interpreter. What language features would be required? Specifically I'm hoping that TH is not necessary because I'm nowhere near that skill level. I'd love to have portable pure haskell implementations of the traditional unix tools. If it were done well, it would allow you to 'cabal install' yourself into a usable dev environment on windows :) I'd much rather do that than deal with cygwin/mingw. Someone (was it Stephen Hicks?) was writing (or finished writing?) an sh parser and I got really excited for the same reason. It would be a cool project, but I'm not sure I can justify to myself spending my spare cycles on it. An outline of a possible approach would be appreciated. I am using http://www.math.utah.edu/docs/info/gawk_toc.html as a guide to the language description. I think this is a good opportunity for you to learn about monad transformers. To that end, I think you will like this paper (quite easy for beginners to pick up): http://www.grabmueller.de/martin/www/pub/Transformers.en.html At least, that's how I first learned about them and I though it was easy to read at the time :) You might also want to read (and try) some of the tutorials that focus on creating interpreters just to sort of get some practice in that area. I haven't read it, but I've heard good things about this one: http://en.wikibooks.org/wiki/Write_Yourself_a_Scheme_in_48_Hours You might also focus on the 'core' of awk. Think about, what is the minimal language and start from there. Grow your implementation adding features bit by bit. It's also a good opportunity to do testing. You have a reference implementation and so you can write lots of tests for each feature as you add them. I hope that helps, Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Embedded scripting Language for haskell app
On 18/08/2010 12:20 PM, Stephen Sinclair wrote: you could script in haskell by embedding hugs. Hugs exe + base lib ~ 1MB. On Tue, Aug 17, 2010 at 6:05 AM, Hemanth Kapilasaihema...@gmail.com wrote: Hi, Can some one please give me a suggestion on the best choice for an embedded scripting Language for a haskell application? I mean, something like guile/lua for c/c++ and groovy/jruby for java. For quite some time, I've been using a lisp-like interpreter that I implemented myself. But this is not going too well - going by this road, I suspect I will end up with a mule. I am looking for a pony (a declarative programming language). I am okay with a donkey too. baskell[1] seems interesting. And there's hslua[2]. Can one use hint[3] like this ? How about a tiny lisp or scheme interpreter? Lots of those to choose from, (including some written in Haskell) and with a few clever macros you could easily provide a declarative DSL for users to work with. I see that you mentioned guile, but even tinyscheme would be pretty powerful and only add a few K to your project. This raises the question, what is the smallest (or most embeddable anyway) Haskell interpreter that can be built? Steve ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
exporting instances: was Using associated data types to create unpacked data structures
re ... As I understand it the generated code is not exported from the translation unit so there are no collisions at link time. We could do the same if we could force the generated type class instance to not be exported from the module. I have encountered several occasions when I wished control over what instances get imported or exported from a module. I have wondered and perhaps someone can explain: what are the issues in explicit control of instance export and import? (apart from defining an appropriate syntax) John ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
new recursive do notation (ghc 6.12.x) spoils layout
Whilst I have nothing against the change in syntax for recursive do aka
http://old.nabble.com/Update-on-GHC-6.12.1-td26103595.html
Instead of writing
mdo
a - getChar
b - f c
c - g b
putChar c
return b
you would write
do
a - getChar
rec { b - f c
; c - g b }
putChar c
return b
it does spoil the nice layout - it would be nice to just be able to
write (which does not parse)
do rec
a - getChar
b - f c
c - g b
putChar c
return b
I don't particularly care that the only recursive statements are #2,#3 -
I just want my nice neat layout back. I have just spent an inordinate
amount of time updating code when if the parser recognised do rec as a
recursive group it would have been a drop in replacement and taken me
one tenth of the time.
Why can't we have this?
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: new recursive do notation (ghc 6.12.x) spoils layout
I think this would just require the lex layout rules already in place for do/let in GHC; my guess is that your example would work if the body were indented past the r of rec. for the record ... t2 = do rec a - getChar b - f c c - g b putChar c return b f = return . (const 'a') g = return eg.lhs:23:6: The last statement in a 'do' construct must be an expression Failed, modules loaded: none. so I suppose it is not so far from recognising the construct and yet too far! ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
[Haskell-cafe] new recursive do notation (ghc 6.12.x) spoils layout
Whilst I have nothing against the change in syntax for recursive do aka
http://old.nabble.com/Update-on-GHC-6.12.1-td26103595.html
Instead of writing
mdo
a - getChar
b - f c
c - g b
putChar c
return b
you would write
do
a - getChar
rec { b - f c
; c - g b }
putChar c
return b
it does spoil the nice layout - it would be nice to just be able to
write (which does not parse)
do rec
a - getChar
b - f c
c - g b
putChar c
return b
I don't particularly care that the only recursive statements are #2,#3 -
I just want my nice neat layout back. I have just spent an inordinate
amount of time updating code when if the parser recognised do rec as a
recursive group it would have been a drop in replacement and taken me
one tenth of the time.
Why can't we have this?
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] new recursive do notation (ghc 6.12.x) spoils layout
On 20/06/2010 6:32 PM, Alexander Solla wrote: in your example c will not be in scope in the expression (let b = c = return . f) - that's the purpose of the recursive do construct (mdo, now do .. rec ..) jvl On Jun 20, 2010, at 6:24 PM, Alexander Solla wrote: do a - getChar let b = c = return . f let c = b = return . g c = putChar b Correction: by your construction, f and g are already in the Kliesli category, so you don't need the return compositions. I still don't know if the construction is admissible though. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Wire GUI
perhaps the inblobs editor may be of some interest http://haskell.di.uminho.pt/~jmvilaca/INblobs/ allows the editing of interaction nets (also available on hackage) Andrew Coppin schrieb: I'm looking at a project which involves a GUI where you can insert components and wire up connections between them. Obviously the details of what the components are and what code gets executed for them is domain-specific, however the general idea of graphically wiring things together is quite generic. Has anybody already put together a Haskell library for doing this kind of thing? There was some work of interfacing Haskell to PureData: http://claudiusmaximus.goto10.org/anglohaskell2007/AngloHaskell2007.xml ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] llvm on windows
on the topic of llvm, is anybody using llvm binding on windows ? The official llvm windows distro does not have a precompiled library which is required for the llvm bindings ? jvl ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] are forkIO threads event-driven?
Re event library and merge into haskell base: has any thought gone into the windows version of the library. Last I looked it was very unix centric - the windows api is very different. I believe it will require major rework to abstract the commonalities and deal efficiently with the differences. I suspect any talk of a merge is premature. On Sun, May 2, 2010 at 8:45 PM, Aran Donohue aran.dono...@gmail.com mailto:aran.dono...@gmail.com wrote: That's very interesting. I only brought it up because I'm thinking about the upcoming problems of real-time web application servers. I'm sure many people have seen this blog post and Dons's replies: http://www.codexon.com/posts/debunking-the-erlang-and-haskell-hype-for-servers http://www.codexon.com/posts/debunking-the-erlang-and-haskell-hype-for-serversThe Haskell code codexon used isn't the best Haskell can do. But I think it's the clearest, most obvious code---the most like what someone learning from the ground up would try first. Ideally, it should run fast by default, and it's too bad that you need to learn about bytestrings (and choose between lazy vs. strict), the various utf8 encoding options, and a new event library to make it perform. The Haskell Network.Socket module uses Strings to represent binary data. This is wrong as String is an abstract data type representing a sequence of Unicode code points, not bytes. Arguably the Network.Socket module should have used [Word8] instead of String. However, String and [Word8] are both represented as linked lists which is not a very efficient representation for large blocks of binary data. bytestring is simply a more efficient encoding of [Word8] and should be use anywhere you want to represent binary data. It's too late to change Network.Socket to use ByteStrings instead of Strings as it would break too much code. I wrote network-bytestring so that you can use ByteStrings instead of Strings when doing socket I/O. The network-bytestring package will most likely be merged into the network package at some point. While you can use the event library explicitly this is not how we intended the majority of users to use it. The goal is to integrate it into GHC 6.14 and as replace the current I/O manager. That means that you will be able to write standard forkIO based code (like in the linked article) and expect around 20,000 requests/second on one core (depending on your hardware). Since I'm basically a beginner to Haskell, if I were to set out to test out a WebSocket server in Haskell, my first pass code would probably look a lot like the codexon template. I certainly wouldn't want to go multi-process nor explicitly manage cores within a single process. I would want forkIO to just work. If we reach our GHC 6.14 goal you will. Cheers, Johan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] are forkIO threads event-driven?
As I said, it is very unix centric. The backend methods rely upon file descriptors which in the windows world are specific to the C rts. It is the backend that requires the abstraction from os specific structures/handling. The event library has a pluggable interface, with multiple backends, and is entirely portable as a result. You just swap in your 'select' mechanism: http://github.com/tibbe/event/blob/master/src/System/Event/EPoll.hsc http://github.com/tibbe/event/blob/master/src/System/Event/Poll.hsc http://github.com/tibbe/event/blob/master/src/System/Event/KQueue.hsc Now, if you can implement the Backend methods, http://github.com/tibbe/event/blob/master/src/System/Event/Internal.hs You'll be good to go -- and we already know GHC can do threads on Windows, so the same mechanism should work faily easily. jvlask: Re event library and merge into haskell base: has any thought gone into the windows version of the library. Last I looked it was very unix centric - the windows api is very different. I believe it will require major rework to abstract the commonalities and deal efficiently with the differences. I suspect any talk of a merge is premature. On Sun, May 2, 2010 at 8:45 PM, Aran Donohue aran.dono...@gmail.com mailto:aran.dono...@gmail.com wrote: That's very interesting. I only brought it up because I'm thinking about the upcoming problems of real-time web application servers. I'm sure many people have seen this blog post and Dons's replies: http://www.codexon.com/posts/debunking-the-erlang-and-haskell-hype-for-servers http://www.codexon.com/posts/debunking-the-erlang-and-haskell-hype-for-serversThe Haskell code codexon used isn't the best Haskell can do. But I think it's the clearest, most obvious code---the most like what someone learning from the ground up would try first. Ideally, it should run fast by default, and it's too bad that you need to learn about bytestrings (and choose between lazy vs. strict), the various utf8 encoding options, and a new event library to make it perform. The Haskell Network.Socket module uses Strings to represent binary data. This is wrong as String is an abstract data type representing a sequence of Unicode code points, not bytes. Arguably the Network.Socket module should have used [Word8] instead of String. However, String and [Word8] are both represented as linked lists which is not a very efficient representation for large blocks of binary data. bytestring is simply a more efficient encoding of [Word8] and should be use anywhere you want to represent binary data. It's too late to change Network.Socket to use ByteStrings instead of Strings as it would break too much code. I wrote network-bytestring so that you can use ByteStrings instead of Strings when doing socket I/O. The network-bytestring package will most likely be merged into the network package at some point. While you can use the event library explicitly this is not how we intended the majority of users to use it. The goal is to integrate it into GHC 6.14 and as replace the current I/O manager. That means that you will be able to write standard forkIO based code (like in the linked article) and expect around 20,000 requests/second on one core (depending on your hardware). Since I'm basically a beginner to Haskell, if I were to set out to test out a WebSocket server in Haskell, my first pass code would probably look a lot like the codexon template. I certainly wouldn't want to go multi-process nor explicitly manage cores within a single process. I would want forkIO to just work. If we reach our GHC 6.14 goal you will. Cheers, Johan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] installing Network on windows
it is easier if you use msys then in msys window, run ghc setup configure after that you can run ghc setup build etc in normal dos window without further recourse to msys Neil Mitchell wrote: Hi, I managed this with the following sequence of commands: http://www.haskell.org/pipermail/libraries/2010-February/013038.html Thanks, Neil On Wed, Mar 17, 2010 at 9:44 PM, Niklas Larsson nikl...@ymail.com wrote: Hi! It needs some shell, if you install MSYS from mingw and do the cabal install from there it will work just fine. Here is the download for MSYS: http://sourceforge.net/projects/mingw/files/MSYS%20Base%20System/msys-1.0.11/MSYS-1.0.11.exe/download // Niklas L. From: gladst...@gladstein.com gladst...@gladstein.com To: haskell-cafe@haskell.org Sent: Wed, March 17, 2010 9:11:00 PM Subject: [Haskell-cafe] installing Network on windows I need some advice on the most straightforward way to install the Network package on Windows. I can install Cywgin if that's what it takes. Thanks in advance. cabal install network Resolving dependencies... Configuring network-2.2.1.7... cabal: Error: some packages failed to install: network-2.2.1.7 failed during the configure step. The exception was: sh: runGenProcess: does not exist (No such file or directory) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Computer Graphics and Haskell - Radiosity Methods
you could have a look at these ... bjpop-ray - search on web hray - http://users.elis.ugent.be/~kehoste/Haskell/HRay/ Hello cafe, While I was studying for my computer graphics test I have tomorrow I realized that maybe some of the major problems I've read so far about Radiosity Rendering Algorithms may be reduced significantly if it was implemented in Haskell and taking advantage of the lazy evaluation so that only what can be seen from the viewer's perspective point of view is calculated, and the rest of the scene just remains as thunks waiting for them to be calculated in case they are needed. I guess that probably most of the people on this list doesn't really work on the computer graphics area, but if anybody out there actually does I'd really like if he or she could explain me more of why what I'm saying could be really useful and what has already been done (or why I'm so lost that I'm probably gonna fail my exam tomorrow hahaha)... One of the things I'm studying is the Monte Carlo Radiosity Methods which takes advantages of non-determinism to create stochastic algorithms, I guess this is more difficult to implement in Haskell, please if you know any of this Monte Carlo Methods for Radiosity Algorithms share that knowledge with me (and the list). Thank you, Hector Guilarte ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
asynchronous call-backs
Thanks for your response. I belabour the issue as I am not
entirely comfortable that there is no issue wrt to the unthreaded rts
on windows at least.
Included here is a test of executing a callback from c to haskell
asynchronously this test was run with both threaded rts and non threaded
rts.
It demonstrates (tentatively) that asynchronous call-backs
seem to be safe with threaded rts and unsafe otherwise.
I have run other tests with the unthreaded rts which confirms
the above (eg with console events) . Details of which I can provide.
It does beg the question what proof can be given that the threaded
rts is safe wrt asynchronous call-backs.
My thoughts go along the lines that the safety of essentially parallel
evaluation of thunks depends upon there being some level of atomicity in
those operations, that atomicity being under the control of the rts. My
concerns boil down to whether that atomicity is broken (by the
unscheduled attempt at an evaluation of a thunk) or there exists within
the evaluation model of the rts some guarantee wrt the underlying
architecture or by happenstance ad-hoc enforcement of
atomicity/synchronisation as an implementation detail. Has this question
been treated as an implementation detail or is there some literature
that you could refer me to?
TEST DETAILS
As a test the c routine, starts an alarm thread that runs the call-back
once a second On each iteration a counter is incremented
and passed to the call back.
the threaded rts works fine, the un-threaded rts raises an
error. The error changes depending upon when the rts is interupted.
In one case the error reported was:
test: internal error: resurrectThreads: thread blocked in a strange way
(GHC version 6.10.4 for i386_unknown_mingw32)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
This application has requested the Runtime to terminate it in an unusual
way.
Please contact the application's support team for more information.
module Main where
import Foreign
import Foreign.C
import System.IO
import Control.Concurrent
-- the callback to be executed assynchronous to the main loop
hsfoo :: Int - IO ()
hsfoo x = do
putStrLn (Input was: ++ show x)
return ()
foreign import ccall safe wrapper mkfoo :: (Int-IO ())-IO
(FunPtr (Int-IO ()))
foreign import ccall safe registerCallback registerCallback ::
(FunPtr (Int-IO ()))-IO ()
loop = do
threadDelay 1000
mapM_ (putStrLn . show) [(0::Int)..10]
loop
main = do
foo - mkfoo hsfoo
registerCallback foo
loop
-
the c code
/* starts an alarm thread that runs the call back
* once a second.
* on each iteration a counter is incremented
* and passed to the call back.
*/
#include stdio.h
#include signal.h
#include windows.h
typedef void (*callback_t)(int);
static callback_t g_callback;
void CALLBACK alarm_callback( unsigned long interval) {
int rc;
int i=0;
printf(alarm thread started\n);
i=0;
while (1) {
i++;
Sleep(1000);
printf(alarm\n);
g_callback(i);
};
}
void registerCallback(callback_t sighandler)
{
printf(installing callback);
g_callback = sighandler;
CreateThread(NULL,0, (LPTHREAD_START_ROUTINE)alarm_callback,
(void*)0,0,0);
}
On 01/02/10 13:36, John Lask wrote:
I understand these are internals of ghc and subject to change. The
reason for their use: to support asynchronous interrupts safe with
respect to the Haskell code that is being interrupted. To my knowledge
(please correct me if I am wrong) there is no way to do this other than
the following alternatives and the already mentioned functions.
As an example, suppose I want to provide a call back to a win32 OS hook
which takes a c-call-back routine. My understanding is that I cannot use
a wrapped Haskell call-back routine as there are no guarantees what
state the Haskell rts will be in when the routine is called.
It's not clear to me that this wouldn't work.
I believe it would be perfectly safe for the Win32 console handler
callback to invoke Haskell functions, because the handler is executed in
a separate thread, unlike Unix signals which happen in the context of
one of the existing threads (which is why you can't use any inter-thread
communication or synchronisation in a Unix signal handler).
At least initially I have used the above mentioned functions to support
win32 signal handling, as the ghc rts just catches (and dispatches)
console events, which do not encompass all the (rather limited) c-rts
signals.
The obvious solution is to provide a c call-back routine, use an WIN32
event object, use a Haskell bound thread to wait on that event.
another alternative would be to poll.
The first alternative requires threaded rts which for various reasons I
don't wish
ghc rts selection and third party libraries
Hello I hope someone can provide some guidance on how I can solve a certain problem. I have a library that taps into the ghc c rts: specifically when the rts is single threaded I am pumping events in via: stg_pending_events, when the threaded rts is used I use sendIOManagerEvent. i.e. I have two versions of the library with the same api. The problem with this is that either library is only good for one context: either threaded rts or not, and the user needs to select the appropriate library to use depending on the use context. What I want to be able to do is to have ghc automatically select the compiled library version to link in depending on the which rts option is selected: -thread or not does any one have any ideas? ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: pexports Was: Re: [Haskell-cafe] binding to C libraries on Windows was Low Level Audio - Writing bytes to the sound card?
I think it would be a usefull addition to the haskell windows tool chain, and help facilitate the creation of bindings to libraries on windows where no appropriate import library exists. I am sure if you put it out there in whatever form, someone will find a use for it and perhaps build upon it. jvl Stephen Tetley wrote: Hi All, Would a pure Haskell version of pexports be useful to the Haskell community? For a Sunday afternoon hack that turned out to take a bit more effort (its now Wednesday), I thought I'd code up a tool that extracts function symbols from .dll's (also when I first looked at the C pexports it seemed somewhat unadopted, though checking today it appears to in MinGW, so my local MinGW must be out-of-date). If there are compelling uses that aren't covered by pexports and would ease Haskell C binding problems on Windows, I don't mind polishing up my tool, but otherwise I've exhausted my natural interest. Best wishes Stephen ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Natural Language Processing
maybe this helps ... see http://www.cs.chalmers.se/~aarne/GF/ I quote from the web site: GF is a categorial grammar formalism, like ACG, CCG, but different and equipped with different tools it compiles with at least GHC 6.8.2 Is Parsec capable of parsing a mildly context sensitive language? In particular does it parse a combinatory categorial grammar? Does Haskell have such tools in its shed? What sort of facilities does Haskell have for natural language processing? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] binding to C libraries on Windows was Low Level Audio - Writing bytes to the sound card?
I think there are some misapprehensions here:- many haskell packages binding to c libraries will compile with ghc without problems on windows - without cygwin, without mingw/msys system. Some such packages build out of the box on windows, like the zlib package which contains the c source for the c zlib library. GHC is able to compile and build this packages without any other c compiler/libraries/unix emulators etc because ghc itself contains part of the gcc c compiler tool chain and comes with all c standard headers, c++ headers and c/c++ runtime libraries. Other packages such as SDL package are relatively straightforward to build on windows - all that is required is to have an import library corresponding to your dll (or static lib) and the headers. You then update the library path field in the cabal file and include path. There is only one gotch-ya - you need to have a import library for the gcc tool chain (thats what ghc uses) i.e. a .a library and not the native windows .LIB import library. If you don't have .a import library but have the dll then the '.a' import library be built for any dll relativley easily. The correct '.a' import libraries and the libraries themselves for many standard unix/gnu packages can be found under the gnuwin32 project. Many unix libraries provide a windows build based on the mingw port of the gcc tool chain which will contain the correct import library. the bigest problem hamperring cleaner builds of haskell packages on windows is the lack of any standardised scheme for the installation of c-libraries and header files (and of course the availability of a suitable build of the library) Another problem hampering the install of haskell packages on windows is the use of the unix autoconf build system (./configure) , for which there is no substitute on windows other than cygwin and to lesser extent msys/mingw, this problem could be obviated by the provision of a standard win32 conf (forgetting about win64 for the moment) - package writters note! Date: Sat, 5 Dec 2009 20:58:14 + Subject: Re: [Haskell-cafe] Low Level Audio - Writing bytes to the sound card? From: stephen.tet...@gmail.com To: Haskell-Cafe@haskell.org CC: Hi Andrew 2009/12/5 Andrew Coppin andrewcop...@btinternet.com: I don't think it should be necessary to install a Unix emulator just so that I can write Windows programs. Maybe others disagree. ... I'm by no means an expert here, but isn't it usual for C libraries on Windows to be supplied as a compiled DLL and a header file for using it? I don't quite understand why you need a C compiler. The thing is, all the bindings on Hackage (or at least something most likely above 95%) are to Unix C libraries so you need a C compiler and a Unix emulator to use them. I do have have some sympathy with your point though - it is possible to get things to compile once you have Cygwin, but deployment on any other machine Windows thereafter is 'challenging' to say the least. Apparently there is some talk of removing OpenGL from the Haskell Platform. And if this happens, it'll be one more thing I can't use on Windows. :-( I didn't realise until I looked today that OpenGL was in the Haskell Platform. If the proposal to remove it is from Sven Panne then fair enough, otherwise it would be a bit disappointing - it always just worked when it was part of GHCs extralibs... Best wishes Stephen ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe _ If It Exists, You'll Find it on SEEK Australia's #1 job site http://clk.atdmt.com/NMN/go/157639755/direct/01/___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Machine Learning Library (SVM)
look at: http://www.cs.utah.edu/~hal/SVMseq/ this works but is a little slow and would benefit by being updated to use the bytestring library. and generic data clustering ... http://www.cs.utah.edu/~hal/GDC/ From: ke...@malde.org To: hector...@gmail.com Subject: Re: [Haskell-cafe] Machine Learning Library (SVM) Date: Wed, 25 Nov 2009 07:56:08 +0100 CC: haskell-cafe@haskell.org Hector Guilarte hector...@gmail.com writes: Ketil, has any progress been made on that library? Specially in the SVM part which is what I'm really looking for... No, the SoC ticket was not funded, and I am not aware of any other Haskell implementation of SVMs (and if there is one, I'm sure it will be pointed out on this list). -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe _ For more of what happens online Head to the Daily Blob on Windows Live http://windowslive.ninemsn.com.au/blog.aspx___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: ghc 6.10.4 infix declarations and '\' bug or not ?
indeed it was the cpp, and the behaviour is consistent beetween versions, I must have introduced some changes that affected the eol marker. Thanks for your tip. jvl - Original Message - From: Duncan Coutts duncan.cou...@worc.ox.ac.uk To: John Lask jvl...@hotmail.com Cc: glasgow-haskell-users@haskell.org Sent: Sunday, August 23, 2009 12:34 AM Subject: Re: ghc 6.10.4 infix declarations and '\' bug or not ? On Sat, 2009-08-22 at 15:52 +1000, John Lask wrote: in declaring fixity for an operator (\\) to get it to compile using ghc 6.10.4, I needed to use the following code infixl 9 \\\ (\\) a b = etc ... where I assume the first \ escapes the second \, using infixl 9 \\ generates a syntax error infixl 9 \\ used to compile no problems with ghc 6.8.2 what is going on here ? Usually this problem is related to cpp, since \\ at the end of a line has special meaning to cpp. Are you sure that you're comparing like with like when you say it worked in ghc-6.8.2? If you're using cpp for the module now and in the past you were not then that would explain it. Another trick I've seen is: infixl 9 \\ -- this comment is here to defeat evil cpp mangling Duncan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
ghc 6.10.4 infix declarations and '\' bug or not ?
in declaring fixity for an operator (\\) to get it to compile using ghc 6.10.4, I needed to use the following code infixl 9 \\\ (\\) a b = etc ... where I assume the first \ escapes the second \, using infixl 9 \\ generates a syntax error infixl 9 \\ used to compile no problems with ghc 6.8.2 what is going on here ? why do I now need to add an additional \ ?, where is this change documented ?, is this a bug? ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] Haskell2Xml
the paper: Scripting XML with Generic Haskell Frank Atanassow, Dave Clarke and Johan Jeuring October 14, 2003 describes a translation from XML Schema to Haskell data types (like dtd2haskell) in generic haskell, I believe that the code for the tool described may also be available, how hard it would be to migrate over to vanilla haskell+generics is another question - Original Message - From: Dmitry Olshansky To: Haskell cafe Sent: Friday, August 07, 2009 7:31 PM Subject: Re: [Haskell-cafe] Haskell2Xml Like in Keith proposal I need it for working with web-services, maybe Xml transformations and so on. And I tried to make it by self with a partial success. To work with xml I only used xml package (Text.XML.Light). Now I am going to work a little (?) on this task to provide more standard and regular tool than I have now. So it is very interesting for me to learn any ideas (if exists) on this thing from community. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell2Xml
link to paper: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.1.7362 - Original Message - From: Dmitry Olshansky To: Haskell cafe Sent: Friday, August 07, 2009 7:31 PM Subject: Re: [Haskell-cafe] Haskell2Xml Like in Keith proposal I need it for working with web-services, maybe Xml transformations and so on. And I tried to make it by self with a partial success. To work with xml I only used xml package (Text.XML.Light). Now I am going to work a little (?) on this task to provide more standard and regular tool than I have now. So it is very interesting for me to learn any ideas (if exists) on this thing from community. -- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] funct.prog. vs logic prog., practical Haskell
I would have thought that a major motivation for the study of haskell,or for that matter ML, Clean, would be their type systems: statically typed higher order parametric polymorphism which is certainlly different enough from that of prolog to warrant study. So from the perspective of type systems and associated gaurantees functional programming languages probably represent the best environment in which to study these concepts. - Original Message - From: Petr Pudlak d...@pudlak.name To: Haskell Cafe haskell-cafe@haskell.org Sent: Sunday, August 02, 2009 8:25 PM Subject: [Haskell-cafe] funct.prog. vs logic prog., practical Haskell Hi all, I'd like to convince people at our university to pay more attention to functional languages, especially Haskell. Their arguments were that (1) Functional programming is more academic than practical. (2) They are using logic programming already (Prolog); why is Haskell better than Prolog (or generally a functional language better than a logic programming language)? (1) is easier to answer, there are a lots of applications at HaskellWiki, or elsewhere around the Internet, written in Haskell, OCaml, etc. Still, I welcome comments on your experience, for example, if you have written some larger-scale application in Haskell (or another a functional language) that is not at HaskellWiki, and perhaps if/why you would recommend doing so to other people. (2) is harder for me, since I've never programmed in Prolog or another language for logic programming. I'd be happy if anyone who is experienced in both Prolog and Haskell could elaborate the differences, pros cons etc. Thanks, Petr ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] lifting restrictions on defining instances
Can anyone explain the theoretical reason for this limitation, ie other than
it is a syntactical restriction, what would it take to lift this restriction
?
- Original Message -
From: Stefan Holdermans ste...@cs.uu.nl
To: Petr Pudlak d...@pudlak.name
Cc: haskell-cafe@haskell.org
Sent: Saturday, July 18, 2009 5:25 AM
Subject: Re: [Haskell-cafe] an instance in other than the last type
parameters
Petr,
If I want to make it a functor in the last type variable (b), I can just
define
instance Functor (X a) where
fmap f (X a b) = X a (f b)
But how do I write it if I want X to be a functor in its first type
variable?
Short answer: you can't. Easiest way to workaround is to define a newtype
wrapper around your original datatype:
newtype X' b a = X' {unX' :: X a b}
instance Functor (X' b) where
fmap g (X' (X a b)) = X' (X b (g a))
Cheers,
Stefan
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] hiding instance definitions in imported modules or redefining them, can it be done?
Is there a way to hide instance definitions when importing a module for instance I want to import Data.Monoid but wish to redefine the instance of Monoid for ( a-b) I don't suppose this is possible? Specifically, I wish to define a specialised instance of Monoid for String-Int, but it seems overlapping instances will not give me what I want, as this option seems to need to be applied at the definition site (aka Data.Monoid module, looking for confirmation of this?). The easy fix is just to do newtype M a b = M (a-b) etc..., but I was hopping to avoid this. I've encountered this issue several times. Why can't we redefine instances? I can't of thought that there are any seriouse technical issues in doing so? If so what are they? jvl ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Cross platform getProcessID
The short anser is...you need to make a ffi call to getCurrentProcessId unfortunately there is no binding to this function in System.Win32.Process which is the natural home for it. Perhaps you could submit a patch for Win32 package, once you have created the binding the signature for the function is quite simple, so there should be no problem with the ffi call DWORD GetCurrentProcessId(VOID) - Original Message - From: John Van Enk vane...@gmail.com To: Haskell Cafe haskell-cafe@haskell.org Sent: Monday, June 22, 2009 1:43 PM Subject: [Haskell-cafe] Cross platform getProcessID In the unix package, we have getProcessID. Is there a corresponding method for finding the process ID in Windows? /jve ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GHCI Curl under Windows
The issue you are experiencing is the result of ghci not using import
libraries to resolve external symbols. Just a bit of explanation for
reference, which will also help you understand the solution to your problem.
Take for example the function declared as
int myexport(int x){...}
when creating a dll the exported definitions will be included in the dll,
if your using mingw to create the dll, as
_myexport
or, if your using ms visual c:
myexport
The import libraries (.a,.lib) will contain
_myexport
__imp__myexport
in the case of mingw .a lib, and also .lib for ms visual c. These
entries enable the compiler to resolve the linkage.
A client of the library will, generally speaking, have the following
declaration
__declspec(dllimport) int myexport(int x);
the object file created will reference __imp__myexport
obviously if you have an object file with __imp__myexport
and no import file you will not be able to resolve __imp__myexport to
_myexport (or myexport) in the dll
and ghci does not use import libraries but just searches for the symbols
defined directly. It
would be nice if ghci could directly resolve symbols decorated like __imp__
.
what to do? Notice that the import libraries (for compilation) contain both
symbols
_myexport and __imp__myexport, therefore if you can get the haskell modules
to reference the _myexport
rather than __imp__myexport all will be ok both for ghci and also ghc
compilation.
so how did the __imp__ get there in the first place?
notice the curl has the cabal option via-C, consequently the curl headers
will be
read in ...
#if (defined(WIN32) || defined(_WIN32)) !defined(CURL_STATICLIB)
...
#define CURL_EXTERN __declspec(dllimport)
...
i.e. by default curls sais link me to the dynamic library, if in the
cabal file you define an option
cc-options: -DCURL_STATICLIB
then the
but retain the link to the dynamic library
Extra-libraries: curl
where libcurl is the name of the dynamic import library ie libcurl.a (you
need to rename libcurl.dll.a, libcurldll.a
or whatever your import is called) as it needs to match the dll name as
otherwise ghci will not find it eg libcurl.dll
and that's it - all should work fine now!
AN EXTRA NOTE ON IMPORT LIBRARIES
on my system I like to have both the static import and the dynamic import
libraries
which are named
libcurl.a (static)
libcurl.dll.a (dynamic import)
to make this work with both GHC and GHCI you need to do the following
cabal ...
Extra-libraries: curl.dll
-- reference the dynamic import library, whatever name you have
after building the package and installing (your versions will be different)
ghc-pkg unregister curl-1.3.2.1
edit the dist\installed-pkg-config and add
extra-ghci-libraries: libcurl, or whatever the name of your .dll file is.
Then run
ghc-pkg update dist\installed-pkg-config
what this will do, is tell ghci the dll name to search for, rather
than relying on the name that you have specified with Extra-libraries:
curl.dll
the benefit of this process is that it will enable you to leave the names
of your import libraries and dll files for curl untouched, which
could otherwise break other dependencies you may have.
The long and the short of it is --- much work still needs to be
done to ensure that building and maintaining packages on windows
platforms via cabal and ghc is painless - so far every
package I have used that relied on external libraries has required
some tweaking (and not just setting library paths).
- Original Message -
From: Sigbjorn Finne sigbjorn.fi...@gmail.com
To: Martin Huschenbett hus...@gmx.org
Cc: haskell haskell-cafe@haskell.org
Sent: Thursday, June 04, 2009 12:59 AM
Subject: Re: [Haskell-cafe] GHCI Curl under Windows
On Wed, 03 Jun 2009 05:27:53 -0700, Martin Huschenbett hus...@gmx.org
wrote:
Hi Haskellers,
I've installed the newest Haskell Platform under Vista and downloaded a
pre compiled version of curl-7.19.4 for MinGW. After changing the build
type in curl.cabal to Simple and supplying the needed paths I could even
build and install curl for haskell.
If I write a program using curl and compile it with GHC everything works
fine. But if I try to execute the main function of my program in GHCI I
always get the following error message:
Loading package curl-1.3.5 ... linking ... interactive:
C:\Devel\Haskell\curl-1.3.5\ghc-6.10.3\HScurl-1.3.5.o: unknown symbol
`__imp__curl_easy_getinfo': unable to load package `curl-1.3.5'
Did anybody have the same problem and knows how to fix it?
Hi Martin,
perhaps you already have, but did you go through this writeup
http://haskell.forkio.com/Home/curl-win32
and see if there are useful pointers there that might help?
--sigbjorn
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: ghc - force library search order
I hav a module that depends upon (binds to) the microsoft uuid.lib (libuuid.a) this is a static library which exports some labels such as IID_IPersistFile. I was playing around with trying to get it to work both with normal compiling via ghc and to dynamically load in ghci. As we know, ghci can't load static libraries and so was not able to resolve the linkage. I therefore decided to directly incorporate the objects of (libuuid.a) into the haskell .a and ghci .o file (ghci) . To do this I needed to ject --whole-archive libuuid.a --no-whole-archive (or alternatively the list of objects) into the link command at an appropriate point to enable the resolution of the linkage. I have achieved my goal but only by constructing the list of objects to link entirely manually, constructing both the .a and .o for the haskell library manually. I am not satisfied with this solution as it is fragile wrt changes in the module structure of the library I have constructed. jvl - Original Message - From: Simon Marlow marlo...@gmail.com To: John Lask jvl...@hotmail.com Cc: glasgow-haskell-users@haskell.org Sent: Monday, June 01, 2009 9:15 PM Subject: Re: ghc - force library search order On 29/05/2009 15:19, John Lask wrote: - Original Message - From: Duncan Coutts duncan.cou...@worc.ox.ac.uk To: John Lask jvl...@hotmail.com Sent: Friday, May 29, 2009 8:09 PM Subject: Re: [Haskell-cafe] ghc - force library search order On Fri, 2009-05-29 at 18:08 +1000, John Lask wrote: I need to force a library to be searched for unresolved symbols after all other libraries have been searched, and I would rather not resort to constructing the linker command line directly. Is there a way to do this? i.e. I want for example -lfoo to appear after all other haskell libraries and before system libraries (for example -lmsvcrt) once ghc has constructed the link command. i.e. how is it possible to coerce ghc into respecting dependencies between the libraries. GHC does a good job in general with native libraries, but there are allways corner cases. I have a feeling this is not possible, but it dosn't hurt to ask. No, there's currently no way to inject flags that come *after* the linker flags for the packages on the linker command line. It might help if you describe at a higher level what it is you're trying to do. There might be a better way to achieve it. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
[Haskell-cafe] ghc - force library search order
I need to force a library to be searched for unresolved symbols after all other libraries have been searched, and I would rather not resort to constructing the linker command line directly. Is there a way to do this? i.e. I want for example -lfoo to appear after all other haskell libraries and before system libraries (for example -lmsvcrt) once ghc has constructed the link command. i.e. how is it possible to coerce ghc into respecting dependencies between the libraries. GHC does a good job in general with native libraries, but there are allways corner cases. I have a feeling this is not possible, but it dosn't hurt to ask. jvl ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell] Re[2]: [Haskell-cafe] Is Haskell a Good Choice for WebApplications? (ANN: Vocabulink)
Well this is interesting. So what you are saying is that if your haskell application requires a peek memory utilisation of (for example) 1GB, after the memory intesive computation has completed and the GC has run (assuming all references have been dropped) the GHC RTS will retain the 1GB allocated to the process. Does this occur on both windows and posix platforms, does anyone know ? If so then this is a real issue. It would be reasonable to expect that the RTS release resources to the OS when not explicitly required. jvl - Original Message - From: Bulat Ziganshin bulat.zigans...@gmail.com To: FFT fft1...@gmail.com Cc: Chris Forno je...@jekor.com; hask...@haskell.org; haskell-cafe@haskell.org Sent: Thursday, May 07, 2009 6:18 AM Subject: [Haskell] Re[2]: [Haskell-cafe] Is Haskell a Good Choice for WebApplications? (ANN: Vocabulink) Hello FFT, Wednesday, May 6, 2009, 11:59:53 PM, you wrote: I've heard it's hard to contain a long-running Haskell application in a finite amount of memory not exactly. you may alloc fixed pool of memory to application (say, 1gb) if you know that it never need more memory. but as far as you don't do it, memory usage grows with each major GC. ghc just don't provide any way to return memory to OS (there is a ticket on it, you can add yourself to CC list to vote for its resolution) -- Best regards, Bulatmailto:bulat.zigans...@gmail.com ___ Haskell mailing list hask...@haskell.org http://www.haskell.org/mailman/listinfo/haskell ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GC [Is Haskell a Good Choice for Web Applications?]
for what its worth, I second this suggestion. - Original Message - From: Andrew Coppin andrewcop...@btinternet.com To: haskell-cafe@haskell.org Sent: Friday, May 08, 2009 6:01 AM Subject: [Haskell-cafe] GC [Is Haskell a Good Choice for Web Applications?] Simon Marlow wrote: http://hackage.haskell.org/trac/ghc/ticket/698 I presume that the reason for this is to avoid handing memory back only to immediately need it again? (I.e., we don't want to be constantly asking the OS to allocate and deallocate memory. Allocate it once and then let the RTS handle it.) How hard would it be to add a function to ask the RTS to shrink the allocated memory? E.g., you do something that you know consumes lots of RAM, you finish doing it, you know that your live set has probably gone way down now, so you ask the RTS to release some RAM if possible. Would that be difficult? (I might be talking moonshine, but isn't the parallel GC based around a block-structured heap? Does that affect the difficulty of the problem one way or the other?) We already have System.Mem, which currently contains a single function to suggest to the RTS that right now might be a good moment to perform some GC. I'd like to see some other functions added here - suggesting to the RTS that it should have a go at shrinking RAM usage is one, but it would be nice to at least be able to query how much RAM is allocated too. (I presume finding out how much we've allocated from the OS is fairly easy; finding out how much is live data is presumably far harder...) Maybe access to various interesting GC information - I don't know if the RTS actually records this stuff when not built for profiling though. (?) Just my thoughts... :-) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GC
on the other hand a function to release pool memory to the OS down to the current active level should (I hope) be easily implementable, and quickly incorporated into application where required, whereas arriving at one or more automatic deallocation policies would most likely require some analysis/trial and error. - Original Message - From: wren ng thornton w...@freegeek.org To: haskell-cafe@haskell.org Sent: Friday, May 08, 2009 9:33 AM Subject: Re: [Haskell-cafe] GC Daniel Fischer wrote: Am Donnerstag 07 Mai 2009 22:01:11 schrieb Andrew Coppin: Simon Marlow wrote: http://hackage.haskell.org/trac/ghc/ticket/698 I presume that the reason for this is to avoid handing memory back only to immediately need it again? (I.e., we don't want to be constantly asking the OS to allocate and deallocate memory. Allocate it once and then let the RTS handle it.) How hard would it be to add a function to ask the RTS to shrink the allocated memory? E.g., you do something that you know consumes lots of RAM, you finish doing it, you know that your live set has probably gone way down now, so you ask the RTS to release some RAM if possible. Would that be difficult? Another idea, I have no idea how hard or sensible it is: What if the GC detects how much memory is currently used (it does already do that, doesn't it?) and how much is allocated from the OS, and if less than a third or a quarter of the allocated memory is used, return the memory that exceeds twice the used memory to the OS? Behaviour might be configurable by an RTS flag. +1 (assuming the GC does detect current usage). I think this behavior (with flags to tune the multiples, or to disable it) is nicely high-level and easy for users to reason about. For users with intimate knowledge of the GC and their program's behavior it could be helpful to have the alternative proposal of an impure function to give hints to the RTS, but in general this seems like far too low-level of an approach to solve the general problem. -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] swish - semantic web in Haskell
you might like to change the name of the package slightly and thereby avoid confusion with swish the text indexing engine. jvl - Original Message - From: Doug Burke doug_j_bu...@yahoo.com To: Vasili I. Galchin vigalc...@gmail.com Cc: haskell-cafe@haskell.org Sent: Friday, May 01, 2009 11:15 PM Subject: Re: [Haskell-cafe] swish - semantic web in Haskell --- On Thu, 4/30/09, Vasili I. Galchin vigalc...@gmail.com wrote: From: Vasili I. Galchin vigalc...@gmail.com Subject: [Haskell-cafe] swish - semantic web in Haskell To: haskell-cafe@haskell.org haskell-cafe@haskell.org Cc: Galchin Vasili vigalc...@gmail.com Date: Thursday, April 30, 2009, 6:39 PM Hello, http://www.ninebynine.org/Software/swish-0.2.1.html I am trying to get permission from the author of Swish to move it into Hackage. I will write cabalize it get up to current Haskell standards. Before I go to this effort is anybody attempting to do this? Kind regards, Vasili Vasili, I recently downloaded the code and started looking at it, but I am *exceedingly* unlikely to have time to do this any time soon. So, if you have the time and the permission to do it, I'll be happy :-) Doug ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ghc: Var/Type length mismatch message - what does it mean?
consider the following types (from the paper:
Stream Fusion From Lists to Streams to Nothing at All)
data Stream a = forall s. Stream ( s -(Step a s)) s
data Step a s =
Done
| Yield a s
| Skip s
an instance of this data type is:
stream0 :: Stream ()
stream0 = Stream (\ s - Yield () s) ()
now consider:
data StreamM m a = forall s. StreamM ( s -m (Step a s)) s
and the following instance:
stream0IO :: StreamM IO ()
stream0IO = StreamM (\ s - return (Yield () s)) ()
loads ok, but as soon as we introduce the following constraint:
data Monad m = StreamM' m a = forall s. StreamM' ( s -m (Step a s)) s
stream0IO' :: StreamM' IO ()
stream0IO' = StreamM' (\ s - return (Yield () s)) ()
we get the following message when we load into ghci (6.8.2)
Var/Type length mismatch:
[]
[base:GHC.Base.(){(w) tc 40}]
is this a bug? if not, what is this message telling us ?
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] New System.Process
Something that has irked me in the past about System.Process is the inability to obtain an OS system handle from the haskell Process handle. Such a facility would greatly enhance the interoperabity of c and haskell libraries. Provision is made (although not standardised) to obtain OS specific handles from haskell File Handles which is very useful. The same should be provided for Haskell Process handles. The main barrier to such a facility is the variability between OS representations of such a type (aka windows Handles, unix PID). comments anyone. _ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] (no subject)
Hi has anyone had any success in running a recent version of hs-plugins on a windows platform. I refer to this post to the haskell list in December last year. The current version of hs-plugins dosn't appear to work either. Same problem ... http://www.haskell.org/pipermail/haskell/2007-December/020043.html jvl _ Meet singles near you. Try ninemsn dating now! http://a.ninemsn.com.au/b.aspx?URL=http%3A%2F%2Fdating%2Eninemsn%2Ecom%2Eau%2Fchannel%2Findex%2Easpx%3Ftrackingid%3D1046247_t=773166080_r=WL_TAGLINE_m=EXT___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Scripting COM Components from Haskell - GreenCard on Hackage
Gunther Hdirect can be found at: http://www.haskell.org/hdirect/ the Hdirect library was conceived prior to the finalisation of the haskell ffi, consequently some work would be required to adapt it to the current ffi. What you want is just the automation library which is only part of the overall package (the package includes ihc, the interface generator, from memory ), the automation library could easily be seporated from the rest of the package, stripping away the hdirect marshalling utils to make use of the current ffi functions and marshalling utils. This would be a relatively straight forward task, for someone that way inclined. you might also want to have a look at hugs.net: http://www.galois.com/~sof/hugs98.net/ John. Date: Tue, 5 Aug 2008 15:30:49 +0200 From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: [Haskell-cafe] Scripting COM Components from Haskell - GreenCard on Hackage CC: haskell-cafe@haskell.org No! Greencard is another story. The paper describes HDirect. On Tue, Aug 5, 2008 at 3:02 PM, GüŸnther Schmidt wrote: Hi, does anybody know if the Greencard package / lib is the same software that is mentioned in the paper Scripting COM Components from Haskell? http://research.microsoft.com/~simonpj/papers/com.ps.gz I managed to install the hackage Greencard package on XP with GHC 6.8.3 but it seems to be quite different from what the paper describes. Günther ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe _ Meet singles near you. Try ninemsn dating now! http://a.ninemsn.com.au/b.aspx?URL=http%3A%2F%2Fdating%2Eninemsn%2Ecom%2Eau%2Fchannel%2Findex%2Easpx%3Ftrackingid%3D1046247_t=773166080_r=WL_TAGLINE_m=EXT___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Question on declaring an instance
Consider the data type: Foo i o a = ... we want to declare an instance of Monad and Arrow for Foo without using a newtype (repackaging). The effect we want is to be able to construct an expression like: ( f g ) ( h i ) where f, g, h, i :: Foo i o a, for some i o a it is easy to declare instance Monad (Foo i o) where ... but how do we declare instance Arrow (Foo ... ), this instance takes a kind * - * - * it is easy to declare instance Arrow (Bar a) where ... where Bar a i o is a flipping of the order of the arguments to Foo i.e. Bar = ((flip . (flip .)) Foo Can Foo be declared an instance of both Arrow and Monad ? _ It's simple! Sell your car for just $30 at CarPoint.com.au http://a.ninemsn.com.au/b.aspx?URL=http%3A%2F%2Fsecure%2Dau%2Eimrworldwide%2Ecom%2Fcgi%2Dbin%2Fa%2Fci%5F450304%2Fet%5F2%2Fcg%5F801459%2Fpi%5F1004813%2Fai%5F859641_t=762955845_r=tig_OCT07_m=EXT___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] FW: containers-0.1.0.1
who is maintainer of containers package ... From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: containers-0.1.0.1 Date: Wed, 12 Mar 2008 23:48:33 + containers-0.1.0.1 will not build with ghc-6.6, the lines #include Typeable.h INSTANCE_TYPEABLE1(Set,setTc,Set) cause a parsing error, due no doubt to Typeable.h being different to 6.8 version _ What are you waiting for? Join Lavalife FREE _ Are you paid what you're worth? Find out: SEEK Salary Centre http://a.ninemsn.com.au/b.aspx?URL=http%3A%2F%2Fninemsn%2Eseek%2Ecom%2Eau%2Fcareer%2Dresources%2Fsalary%2Dcentre%2F%3Ftracking%3Dsk%3Ahet%3Asc%3Anine%3A0%3Ahot%3Atext_t=764565661_r=OCT07_endtext_salary_m=EXT___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] isFunction
Oleg provided the following code to test whether a is a function, this code will not type check in hugs, due to the overlapping instances in IsFunction (x-y) f IsFunction x f and the functional dependency | a- b ERROR isfunction.lhs:43 - Instances are not consistent with dependencies *** This instance: IsFunction a b *** Conflicts with : IsFunction (a - b) c *** For class: IsFunction a b *** Under dependency : a - b is there a way to acheive the same effect in hugs ? data HTrue data HFalse class IsFunction a b | a - b instance TypeCast f HTrue = IsFunction (x-y) f instance TypeCast f HFalse = IsFunction x f -- literally lifted from the HList library class TypeCast a b | a - b, b-a where typeCast :: a - b class TypeCast' t a b | t a - b, t b - a where typeCast' :: t-a-b class TypeCast'' t a b | t a - b, t b - a where typeCast'' :: t-a-b instance TypeCast' () a b = TypeCast a b where typeCast x = typeCast' () x instance TypeCast'' t a b = TypeCast' t a b where typeCast' = typeCast'' instance TypeCast'' () a a where typeCast'' _ x = x _ New music from the Rogue Traders - listen now! http://ninemsn.com.au/share/redir/adTrack.asp?mode=clickclientID=832referral=hotmailtaglineOct07URL=http://music.ninemsn.com.au/roguetraders___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] RE: simple function: stack overflow in hugs vs none in ghc
I agree with your analysis. if the following is tried in hugs then ghc you will obtain two different results.. return (repeat 'a') = \ x - print $ span (const True) x with hugs you will get a stack error, in ghc it executes in constant space, i.e. indefinitely. In essenece the above example does exactly the same as my ealier code. _ Advertisement: Need a Hand? Use Yellow.com.au http://a.ninemsn.com.au/b.aspx?URL=http%3A%2F%2Fadsfac%2Enet%2Flink%2Easp%3Fcc%3DPAS075%2E5683%2E0%26clk%3D1%26creativeID%3D73753_t=765559690_r=Hotmail_email_tagline_sept07_m=EXT ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] RE: simple function: stack overflow in hugs vs nonein ghc
afraid not the given example is too strict, the requirement is to generate the matched portion lazilly, and return the tail (unconsumed portion). In principle the function should be capable of being written to run in constant space which the given example dose not. From: Claus Reinke [EMAIL PROTECTED] To: john lask [EMAIL PROTECTED],[EMAIL PROTECTED],haskell-cafe@haskell.org Subject: Re: [Haskell-cafe] RE: simple function: stack overflow in hugs vs nonein ghc Date: Mon, 24 Sep 2007 13:05:24 +0100 return (repeat 'a') = \ x - print $ span (const True) x with hugs you will get a stack error, in ghc it executes in constant space, i.e. indefinitely. In essenece the above example does exactly the same as my ealier code. this thread might be relevant: http://www.haskell.org/pipermail/hugs-bugs/2007-June/001815.html http://www.haskell.org/pipermail/hugs-bugs/2007-June/001816.html http://www.haskell.org/pipermail/hugs-bugs/2007-June/001817.html claus _ Advertisement: Love Footy? Get AFL, NRL, Rugby live scores and video now! http://ninemsn.com.au/share/redir/adTrack.asp?mode=clickclientID=819referral=hotmailtaglineURL=http://sports.ninemsn.com.au ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] RE: simple function: stack overflow in hugs vsnonein ghc
nope. it is true that in the case of an infinite list it exibits the desired behaviour but ... return (replicate 100 'a') = \x-print $ spant (const True) x ERROR - Garbage collection fails to reclaim sufficient space i.e. as the function unfold, the thunk representing the second term builds up on the heap. (not sure why it works for an infinite list, hugs must drop the reference to the tail ?) to obtain a function that will properly operate in constant space, for every unfolding of the first term we need to enforce evaluation of the second term. From: Claus Reinke [EMAIL PROTECTED] To: john lask [EMAIL PROTECTED] CC: haskell-cafe@haskell.org Subject: Re: [Haskell-cafe] RE: simple function: stack overflow in hugs vsnonein ghc Date: Mon, 24 Sep 2007 16:20:42 +0100 afraid not the given example is too strict, the requirement is to generate the matched portion lazilly, and return the tail (unconsumed portion). ah yes, without optimisations, Prelude.span builds up stack, while the continuation-based alternative i mentioned is too strict for some uses. In principle the function should be capable of being written to run in constant space which the given example dose not. return (repeat 'a') = \ x - print $ span (const True) x how about the old spec, then? span p l = (takeWhile p l,dropWhile p l) since takeWhile takes forever, here, it isn't even inefficient!-) claus with hugs you will get a stack error, in ghc it executes in constant space, i.e. indefinitely. In essenece the above example does exactly the same as my ealier code. this thread might be relevant: http://www.haskell.org/pipermail/hugs-bugs/2007-June/001815.html http://www.haskell.org/pipermail/hugs-bugs/2007-June/001816.html http://www.haskell.org/pipermail/hugs-bugs/2007-June/001817.html _ Get more out of your e-mail. Update to Windows Live Hotmail today! http://ninemsn.com.au/share/redir/adTrack.asp?mode=clickclientID=778referral=HotmailTaglineURL=http://g.msn.com/8HMBEN/14811??PS= ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell] simple function: stack overflow in hugs vs none in ghc
Hi hoping someone can shed some light on this: The following code causes a C stack overflow in hugs (version 20051031) but not in ghc (version 6.6) The point of the exercise is to process a very large file lazily, returning the consumed and unconsumed parts (i.e. basic parser combinators). The simplified (stylised example of the problem) is displayed bellow. test1 (on a large file) will succeed in ghc but fail in hugs test2 on same file will succeed in both ghc and hugs the problem appears to be retaining a hold on the unconsummed portion and returning it. maybe something to do with updating CAFS, all too subtle for me. The question: is there any changes that can be made to the code to make test1 work in hugs without changing the essence of the function. test1 = readFile big.dat = (\x-print $ parse x) test2 = readFile big.dat = (\x-print $ fst $ parse x) big.dat is just some large data file say 1MB. (not particularly large by todays standards!) parse x = sqnc item x where item =( \ ts - case ts of [] - ( Nothing, []) ts - ( Just (head ts), tail ts) ) sqnc p ts = let ( r, ts' ) = p ts in case r of Nothing - ([],ts') Just x - let (r',ts'') = (sqnc p ts') in ( x:r', ts'' ) _ Advertisement: Search for local singles online at Lavalife http://a.ninemsn.com.au/b.aspx?URL=http%3A%2F%2Flavalife9%2Eninemsn%2Ecom%2Eau%2Fclickthru%2Fclickthru%2Eact%3Fid%3Dninemsn%26context%3Dan99%26locale%3Den%5FAU%26a%3D30290_t=764581033_r=email_taglines_Search_m=EXT ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
ghci 6.6 foreign import stdcall broken, panic, panic!!!!
ghci 6.6 foreign import stdcall broken, panic, panic Hello I would like to report what I think is a problem with GHCI foreign function imports of c functions declared with stdcall calling convention (1) and also with loading objects containing dll imports (2). I will attempt to log this in ghc trac. What is the problem ? -- (1) Prelude :load htest3 [1 of 1] Compiling Main ( htest3.hs, interpreted ) During interactive linking, GHCi couldn't find the following symbol: test This may be due to you not asking GHCi to load extra object files, archives or DLLs needed by your current session. Restart GHCi, specifying the missing library using the -L/path/to/object/dir and -lmissinglibname flags, or simply by naming the relevant files on the GHCi command line. Alternatively, this link failure might indicate a bug in GHCi. If you suspect the latter, please send a bug report to: glasgow-haskell-bugs@haskell.org (2) ghci -fglasgow-exts test_proxy5a.o -ltest3b test_proxy5a.o: unknown symbol `__imp__test' final link ... : linking extra libraries/objects failed detail follows ... CONCLUSSION REACHED (1) ghci handling of mangling of stdcall function names broken. (2) ghci loading of c object files dll imports name resolution broken. (1) ghci dose not correctly look for symbols decorated in the stdcall manner in the object files ie. it looks for _test when it should (according to stdcall convention) look for [EMAIL PROTECTED] stdcall symbols in object files are decorated with the number of bytes that should be popped from the stack before the function returns. (2) ghci cannot properly resolve dllimports in c object files i.e. if an object loaded by ghci (eg test_proxy, with c function test_proxy) calls functions from a dll (eg test) then that function in the object file will be decorated as this in normal course linked agains a .lib or a .a file will be resolved to _test function in the dll but ghci does not do this. ofcourse these problems go away when using ghc ... but well what's the point of ghci then? SUMMARY OF TESTS and METHODOLOGY 1) REFERENCE CASE verify that ccall works .. Create c file test1a.c and function test(int) in the file create haskell file htest1.hs with function ctest calling test check this works ok with (a) c object loaded (test1a.c, htest1.hs )-- OK, RIGHT! (b) windows dll, c is function dll export (test1b.c, htest1.hs ) -- OK, RIGHT! 3) change calling convention to stdcall (a) check loading of function from object (test3a.c, htest3.hs) -- FAIL, WRONG (b) check loading of stdcall function from dll -- FAIL, WRONG 4) try what shouldn't work (a) htest3 against object test1a, i.e. what hapens when you try loading a haskell module with foreign import stdcall against c function declared with ccall convention ghci loaded -- OK!!, WRONG, it should not have resolved the symbol and not loaded ghc called function and crashed -- given that it resolved the symbol and called the function this is expected (b) htest3 against dll htest1b.dll same result as 4a -- expected, behaviour consistent in both cases with resolving stdcall callouts (symbols test) in a manner consistent with ccalls i.e. resolving the call to c function test as a call to symbol _test rather than [EMAIL PROTECTED] as it should be according to stdcall convention yet the function is called as stdcall c function consequently ghci crashes when the ccall function returns and the stack has not been cleared of the function arguments as is required by the stdcall convention 5) Hmm, lets see what happens when we have a ccall c proxy function calling stdcall c function in dll etc? (a) test_proxy5a.o with test3b.dll ccall function calling stdcall function in dll unknown symbol __imp__test -- FAILED, WRONG dllimports are decorated with __imp__ so a stdcall dllimport to a c function test will appear as [EMAIL PROTECTED] the dll will export symbol [EMAIL PROTECTED], usually it is the function of the import library .a or .lib depending upon which linker mingw or msvc to resolve [EMAIL PROTECTED] to reference [EMAIL PROTECTED] in dll (b) test_proxy5b.o with test3b.dll, htest5.hs ccall function calling stdcall function (not declared as dllimport) LOADS OK, RUNS OK test_proxy5b imports symbol [EMAIL PROTECTED] the test3b.dll exports symbol [EMAIL PROTECTED] arguably this is correct behaviour as __imp__ decoration is an MS innovation and case (a) should be handled together with case (b). (c) whell what about test_proxy5b.o with test1b.dll i.e. c stdcall to a c function declared with ccall convention from .o object loaded by ghci should fail to resolve symbols, should crash program does niether hey this has me stumped
[Haskell] Forcing Type Class Equality
** this is literate haskell hoping someone can help me. What I am trying to do is class Ba1 a ba1 :: Ba1 a = a - IO () ba1 x = print helllo what I wish to do is declare another function class Foo a proxy :: Foo a = a - IO () so that I can do something like proxy x = ba1 x this does not work in hugs and gives ERROR test.lhs:19 - Cannot justify constraints in explicitly typed binding *** Expression: proxy *** Type : Foo a = a - IO () *** Given context : Foo a *** Constraints : Ba1 a which is entirely expected. The trick is to tell hugs that Foo and Ba1 are the same so how do I do that ? I have tried instance Ba1 a = Foo a instance Foo a = Ba1 a which should define equality but to no avail ?? Can this be done ? I thought the problem might be drawing the inference Foo == Ba1 and to try and force the inference i did: class Foo a proxy1 :: (Foo a,Ba1 a) = a - IO () proxy1 x = ba1 x proxy2 :: Foo a = a - IO () proxy2 x = proxy x This typed checked but Main :load test Main proxy2 ERROR - *** The type checker has reached the cutoff limit while trying to *** determine whether: *** Foo a *** can be deduced from: *** () *** This may indicate that the problem is undecidable. However, *** you may still try to increase the cutoff limit using the -c *** option and then try again. (The current setting is -c40) any ideas out there ?? _ Meet Sexy Singles today @ Lavalife - Click here http://a.ninemsn.com.au/b.aspx?URL=http%3A%2F%2Flavalife9%2Eninemsn%2Ecom%2Eau%2Fclickthru%2Fclickthru%2Eact%3Fid%3Dninemsn%26context%3Dan99%26locale%3Den%5FAU%26a%3D22740_t=751140432_r=emailtagline_meetsexy_june_m=EXT ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
RE: [Haskell] Forcing Type Class Equality
NB the essence what I am trying to do is to define a proxy class Foo for class Ba1 I would have thought that something as simple as the following would have worked ?? class Ba1 a where dosomething :: a - IO () ba1 :: Ba1 a = a - IO () ba1 x = dosomething x instance Ba1 Int where dosomething x = print x instance Ba1 Char where dosomething x = print x what I wish to do is declare another function class Foo a instance Foo a = Ba1 a proxy :: Foo a = a - IO () proxy x = ba1 x _ realestate.com.au: the biggest address in property http://ninemsn.realestate.com.au ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: Records (was Re: [Haskell] Improvements to GHC)
correct me if I am wrong but ...
1. Field namespaces: solved by using type classes
This would imply that the type of the field is the same between all
instances of this common field.
Under this proposal two fields with same label and different type would
not be possible
eg { name :: String }, { name :: Int }
John
- Original Message -
From: Rob Ennals [EMAIL PROTECTED]
To: Johannes Waldmann [EMAIL PROTECTED]
Cc: haskell@haskell.org
Sent: Wednesday, November 23, 2005 1:32 AM
Subject: Re: Records (was Re: [Haskell] Improvements to GHC)
Hi guys,
Since discussion has returned to records, it might be useful for me to
post a link to a proposal that I knocked up a while back when this
topic came up a few years ago:
http://www.cambridge.intel-research.net/~rennals/records.pdf
The basic idea is to keep records largely as they are, but add two
extensions:
- field getter functions are placed in type classes
- fields desugar to setter functions as well as getters
Useful features of this approach are:
- backward compatibility with existing code
- the existing type-class mechanism is used for shared field names
- setters can be redefined if a type is changed, just as getters can now
To go through Dave's issues:
1. Field namespaces: solved by using type classes
2. Multi-constructor getters: solved by desugaring to functions
3. Safe getters for multi-constructor data types: ditto
4. Getters for multiple data types with a common field: solved by
type-classes (no special constains feature required)
5. Setters as functions: yep
6. Anonymous records: not supported
7. Unordered records: yep (if I understand the problem correctly)
And Georg's points:
8. Subtyping: yep -using type classes
9. higher order versions for selecting, updateing ... : not sure what
is meant here
Of course, my proposal might very well not do what you want, but I
thought it was worth posting it again.
Hope people find this useful.
-Rob
On 11/22/05, Johannes Waldmann [EMAIL PROTECTED] wrote:
On records in Haskell - can we start by formulating requirements
(design goals). What do we want from a record system,
and what are non-goals.
Some of the proposals here sound like records should be more like
objects (with some kind of inheritance). Do we really want this?
We already have inheritance (for interfaces). Isn't that enough?
My main objection is that concrete data types (e. g. records)
should not be exposed by a module anyway,
and should definitely not be a base for derivations
(Compare the OO design pattern literature).
Still if they are exposed (or while we're inside a module),
what makes the current records quite impractical
is the namespace issue (for component names).
Sure, one thing would be to invent some ad-hoc solution
(automatic qualification by type name or something)
but another possibility is to allow ad-hoc polymorphisms
generally in the language.
Just my 2 cent (and none of them new, I'm afraid)
--
-- Johannes Waldmann -- Tel/Fax (0341) 3076 6479/80 --
http://www.imn.htwk-leipzig.de/~waldmann/ ---
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Improvements to GHC
I would like to sound out the Haskell community on what the feeling are most desirable to improve the commerciality (i.e. its general use) of ghc and Haskell in general (as distinct from feature set) my pick would be to 1) GHC runtime to be dynamically loaded. Enable the ghc runtime system to be loaded as a shared object/dll rather than being statically compiled in. I think the reason this has yet to be done is because it is a rather tricky issue, perhaps those in the know can comment. 2) Improving Haskell support for records. There has been much discussion over the years, some experimentation, but which alas has amounted to no change or improvement in Haskell record support. Again in my opinion the area that Haskell compares least favourably with other languages is in the area of record support particularly a) no distinct namespace for record fields (forcing people to resort to the module system to resolve name space clashes) b) subclassing on records would be great. All these things have been discussed before. The most important is (a) as it would obviate some of the tortured coding that currently appears in many Haskell modules. Additionally c) first class labels would be nice 3) Macro / conditional compilation / compiler meta language / additional binding forms These are perhaps distinct issues but can be discussed together. The prevalent use of #ifdef and the cpp is indicative of the general need to have some standard means by which differences between compilers ghc/hugs/nhc can be accommodated for in the source code. To date this issue has not been tackled in any meaningful way, perhaps we can continue to use cpp but for the sake of portability A means of defining additional binding forms would be nice as it would further facilitate embedded dsl for which Haskell is pre-eminent, and which use is a great motivator for venturing into Haskell in the first place. 4) Taking up the issue of portability and byte codes in a recent thread. The lvm used in the helium compiler perhaps offers the opportunity of defining a standard Haskell byte code platform which other compilers can target for instance ghc/hugs (hugs has in its code base the possibility of writing out a compiled form aka compiler) - thereby separating the compile time and run time platforms, providing a standard Haskell target platform. ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
