[ ghc-Bugs-782761 ] Wrong line count in parsec under linux on dos-style files
Bugs item #782761, was opened at 2003-08-04 04:32 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=782761group_id=8032 Category: hslibs/text Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Wrong line count in parsec under linux on dos-style files Initial Comment: Parsec doubles the line count (reported e.g. in a parse error) when run (at least on a linux box) on DOS-style files (with DOS-style newlines) I have GHC 6.0 My e-mail address is [EMAIL PROTECTED] Bye Vincenzo Ciancia -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=782761group_id=8032 ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: DLL problem with GHC 6.0.1
I have run into something in GHC that looks like a bug (GHC 6.0.1 under Win2k). A DLL with several exported FFI functions reports (and then terminates): ghcDll: internal error: schedule: invalid what_next field Please report this as a bug to [EMAIL PROTECTED], or http://www.sourceforge.net/projects/ghc/ What is really strange: I get this error ONLY when I run my application (C++ code which loads the DLL dynamically) under MS Visual Studio 6 in Debug Mode. When I run the same executable from shell/command prompt, then everything works. Also, when I compile the DLL with GHC version 5.x, I can run the application from Visual Studio 6 without problems. So this seems to be GHC 6.x specific. Not 100% sure, but looks like I get this error on a first call to any FFI function. Unfortunately the application is rather large but I could try to simplify it. I had this problem also with GHC 6.0.0. Any ideas? Just wondering: are you using the DLL wrapper code that comes with H/Direct? (it looks like it from the error message - ghcDll is what that wrapper uses as the dummy binary name). If you're using H/Direct, then there are one or two bugs in the DLL support that I believe have been fixed recently. In particular, DllCanUnloadNow() was bogusly returning S_OK all the time, which could lead to the crash you mention above. Change DllCanUnloadNow to consistently return E_FAIL to work around it, or grab new H/Direct sources from CVS. Cheers, Simon ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: linker errors
One of GHC's infelicities is that it only supports tuples up to a certain size -- currently 62. You just can't get bigger tuples. Your program uses a 73-tuple. My guess is that your code is generated by some other program that's generating big tuples? The only workaround is to nest your tuples. It would really be much better if GHC complained in the front end about over-size tuples. I'll fix that. The real fix (arbitrary size tuples) isn't really hard, but it involves real work so we keep postponing it on the gounds that it seldom bites. So please continue to say if it bites you, so that we know. It used to be the case that simply having a nest of more than 62 mutually-recursive functions would trigger this bug, but that should no longer be the case with 6.0. Please say if that is happening. Simon | -Original Message- | From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] | On Behalf Of A.P. Rao | Sent: 04 August 2003 05:50 | To: [EMAIL PROTECTED] | Subject: linker errors | | Hi, | | I am getting an undefined reference error listed | below when I try to | build my program. I am able to successfully compile | and link a trivial | Hello World program, but not my application code. | | I tried 3 different versions of ghc (5.04.3, 6.0 and | 6.0.1) on my | redhat-9 linux pc. The gcc compiler is at version | 3.2.2 (gcc (GCC) | 3.2.2 20030222 (Red Hat Linux 3.2.2-5)). I even | tried the ghc 6.0.1 | compiler built on my own pc. The result is the same. | | Error: | | AsnParser.o(.text+0x21139): In function `r2CD0_entry': | : undefined reference to `DataziTuple_Z73T_con_info' | collect2: ld returned 1 exit status | | | Any suggestions as to what may be causing this and | how I can get rid | of it. To me, it looks like a code-generation bug on | ghc's side. | | Thanks, | A.P. Rao | | | __ | Do you Yahoo!? | Yahoo! SiteBuilder - Free, easy-to-use web site design software | http://sitebuilder.yahoo.com | ___ | Glasgow-haskell-users mailing list | [EMAIL PROTECTED] | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: linker errors
The code is hand-written and the maximum tuple-size used is 4. It works fine in Hugs. It uses the Parsec library (not the version in GHC's text package, but from a local copy. The ParsecPrim.hs was replaced by the version from Parsec's web-site -- it works as I expected, but not the one distributed with GHC or Hugs). The code makes straight-forward use of Parsec combinators for parsing ASN.1, and I can't see a nesting of anything close to 62 mutually recursive functions. If there is a readme type of document that explains the names and the tables generated in the .hc files, it may help me track down what construct is causing this problem. Right now, I can't recognize anything in the lines surrounding the place where this DataziTuple_Z73T_con_info symbol is used in the .hc file. Thanks, A.P. Rao. --- Simon Peyton-Jones [EMAIL PROTECTED] wrote: One of GHC's infelicities is that it only supports tuples up to a certain size -- currently 62. You just can't get bigger tuples. Your program uses a 73-tuple. My guess is that your code is generated by some other program that's generating big tuples? The only workaround is to nest your tuples. It would really be much better if GHC complained in the front end about over-size tuples. I'll fix that. The real fix (arbitrary size tuples) isn't really hard, but it involves real work so we keep postponing it on the gounds that it seldom bites. So please continue to say if it bites you, so that we know. It used to be the case that simply having a nest of more than 62 mutually-recursive functions would trigger this bug, but that should no longer be the case with 6.0. Please say if that is happening. Simon __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Polymorphic kinds
Hello,
I am experimenting with GHC to write low level code (e.g., device
drivers, interrupt handlers). The ultimate goal is to write a
prototype operating system in Haskell, using the GHC RTS as a kind of
microkernel (this appears to be relatively easy by removing all the
dependencies on an operating system, and providing a block allocator
and interval timers).
I have added the necessary primitive operations to generate privileged
instructions for IA32 to GHC, and it seems to work fine, good quality
assembly code is generated.
Now, I would like to make use of do-notation to write cleaner code
(threading a State# RealWorld through computations is quite ugly).
I want to avoid allocating memory in parts of the code, so I would
like to be able to have monadic computations which return unboxed
values. Sadly, GHC currently does not appear to allow that.
The following example illustrates the problem:
{-# OPTIONS -fglasgow-exts #-}
import GHC.Prim
x :: IO Int#
x =
return 1#
GHC (HEAD from 2003-08-01) reports:
T.lhs:5:
Kind error: Expecting a lifted type, but `Int#' is unlifted
When checking kinds in `IO Int#'
In the type: IO Int#
While checking the type signature for `x'
T.lhs:7:
Couldn't match `*' against `#'
When matching types `a' and `Int#'
Expected type: a
Inferred type: Int#
In the first argument of `return', namely `1#'
After looking into the problem for a while, I realized that GHC does
not have polymorphic kinds - after checking a bunch of definitions, it
zonks all kind variables to (Type *) and all boxity variables to *.
So IO has kind (Type * - Type *), and cannot be applied to an unboxed
value of kind (Type #).
GHC has had explicit kind annotations for a while:
http://www.haskell.org/pipermail/haskell/2002-February/008906.html
So I ought to be able define an IO# type for computations that return
unboxed values.
(By the way, is there already an unboxed unit value and type?)
Strangely, GHC did not recognizes # as the kind of unlifted types, so
I added that to the compiler, and hoped that things would work out.
Well, almost.
{-# OPTIONS -fglasgow-exts #-}
import GHC.Prim
newtype IO# (a :: # ) = IO# (State# RealWorld - (# State# RealWorld, a #))
x :: IO# Int#
x = IO# (\ s - (# s, 1# #))
GHC reports:
T.lhs:8:
Illegal unlifted type argument: Int#
In the type: IO# Int#
While checking the type signature for `x'
The example is accepted if newtype is replaced by type (and by
removing uses of the IO# value constructor), so I can proceed with my
experiment by not using do-notation (defining return#, then#, etc
appears to work fine).
Not being able to use do-notation is slightly inconvenient; is there a
reason why newtypes cannot be applied to unlifted type arguments?
I expect that I would eventually have been beaten anyway when trying
to make an instance of the Monad type class for the above IO# newtype,
since Monad is probably regarded as a predicate of kind (* - *) - P
(where P would be the hypothetical kind of propositions); application
to an operator of kind (# - *) would fail.
What would need to be done to extend the compiler so that it allows IO
computations to be able to return unboxed values? For some reason I
am worried that just having polymorphic kind may not be enough.
I also fail to understand all the implications of having polymorphic
kinds, so I would greatly appreciate if one of the GHC experts could
say something about that too.
--
Sebastien
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC version 6.0.1
On Wed, Jul 30, 2003 at 01:06:02PM +0100, Simon Marlow wrote: = The (Interactive) Glasgow Haskell Compiler -- version 6.0.1 = We are pleased to announce a new patchlevel release of the Glasgow Haskell Compiler (GHC), version 6.0.1. Debian packages are now in the archive for unstable; just apt-get update and apt-get install ghc6 ghc6-prof ghc6-doc. There are also ghc6-hopengl, ghc6-threaded-rts and ghc6-libsrc packages. It should enter testing in 10 days time. Stable packages are available from Isaac's Haskell Experimental repository. To use them, add deb http://www.syntaxpolice.org/haskell-experimental/ stable/ to your /etc/apt/sources.list and install as above. Thanks Ian ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Polymorphic kinds
The ultimate goal is to write a prototype operating system in Haskell, using the GHC RTS as a kind of microkernel As a useful stepping stone towards that goal, you might look at Utah's OSKit: http://www.cs.utah.edu/flux/oskit/ It gives you a bunch of useful bits like bootloaders, device drivers, filesystems and network stacks with well-defined interfaces which let you quickly get a system up and running and then gradually replace the bits. People have used the OSKit to build Scheme, Java and ML-based systems. See the links at the end of this page: http://www.cs.utah.edu/flux/oskit/projects.html I'd also recommend reading the papers about the Janos project (a Java OS) especially: Processes in KaffeOS: Isolation, Resource Management, and Sharing in Java Drawing the Red Line in Java. both available from: http://www.cs.utah.edu/flux/janos/pubs.html These talk about OS features which appear to be redundant when you work in a high-level, strongly-typed language but which prove to have significant value when you look more closely. Finally, I recommend looking at INRIA's Devil project http://compose.labri.fr/prototypes/devil/ Devil is an IDL for defining the interface to devices - like what does each bit in a control register or interrupt mask do? They have somewhat limited goals but for what they do, they are many, many, many times better than the status quo as exemplified by the Linux/*BSD/Windows/etc kernels. Hope this is helpful. -- Alastair Reid ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC version 6.0.1
In article [EMAIL PROTECTED], Ian Lynagh [EMAIL PROTECTED] wrote: Debian packages are now in the archive for unstable; just apt-get update and apt-get install ghc6 ghc6-prof ghc6-doc. There are also ghc6-hopengl, ghc6-threaded-rts and ghc6-libsrc packages. It should enter testing in 10 days time. /usr/bin/ghc etc. links don't work out of the box. It looks like your post-install script needs to call update-alternatives on the four links. -- Ashley Yakeley, Seattle WA ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC version 6.0.1
On Mon, Aug 04, 2003 at 02:11:19PM -0700, Ashley Yakeley wrote: In article [EMAIL PROTECTED], Ian Lynagh [EMAIL PROTECTED] wrote: Debian packages are now in the archive for unstable; just apt-get update and apt-get install ghc6 ghc6-prof ghc6-doc. There are also ghc6-hopengl, ghc6-threaded-rts and ghc6-libsrc packages. It should enter testing in 10 days time. /usr/bin/ghc etc. links don't work out of the box. It looks like your post-install script needs to call update-alternatives on the four links. This is caused by a bug in the remove scripts of some of the old packages. Running update-alternatives --auto ghc as root should fix it. Thanks Ian ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: The madness of implicit parameters: cured?
Ben Rudiak-Gould wrote: [...] The final straw was: Prelude let ?x = 1 in let g = ?x in let ?x = 2 in g 1 Prelude let ?x = 1 in let g () = ?x in let ?x = 2 in g () 2 This is insanity. I can't possibly use a language feature which behaves in such a non-orthogonal way. Well, this is not insanity (only a little bit). In the first example, you define a *value* g, i.e., g is bound to the value of ?x in its current environment (though this value is not yet evaluated due to lazy evaluation), whereas in the second example you define a function. The real insanity in this point is that Haskell -- in contrast to Clean -- offers no way to distinguish function bindings and value bindings and therefore you cannot define nullary functions (except by some judicious use type signatures), which is the heart of the monomorphism restriction mentioned by somebody else on this list (and discussed regularly on this list :-). Now the interesting part: I think I've managed to fix these problems. I'm afraid that my solution will turn out to be just as unimplementable as my original file I/O proposal, and that's very likely in this case since I'm far from grokking Haskell's type system. So I'm going to present my idea and let the gurus on this list tell me where I went wrong. Here we go. [...] Now introduce the idea of explicit named parameters to Haskell. This requires three extensions: a new kind of abstraction, a new kind of application, and a way of representing the resulting types. This looks quite similar to the labeled parameters in Objective Caml. However, Objective Caml's solution seems to be more general. For instance, you can pass labeled parameters in arbitrary order and you can have default value for optional arguments. [...] Why are the semantics so much clearer? I think the fundamental problem with the existing semantics is the presence of an implicit parameter environment, from which values are scooped and plugged into functions at hard-to-predict times. If you keep the distinction between values and functions in mind, I do not think that it is hard to predict when an implicit parameter is substituted (if you are willing to accept the principal problem that it is hard to predict which value is substituted with every kind of dynamic scoping :-). By substituting a notation which clearly means I want this implicit parameter of this function bound to this value right now, and if you can't do it I want a static type error, we avoid this ambiguity. IMHO, this problem were solved much easier by introducing a new syntax to distinguish value and (nullary) function bindings, as was already repeatedly asked for on this list in the context of the monomorphism restriction. Personally, I'd suggest to use let x - e in ... to introduce a value binding (as it is quite similar to the bindings introduced in a do-statement) and use let x = e to introduce a nullary function. (I prefer - over := which John Hughes and others suggested some time ago because we don't loose an operator name). Thus, you example let ?x = 1 in let g = ?x in let ?x = 2 in g will behave as you did expect, viz. evaluate to 2, whereas let ?x = 1 in let g - ?x in let ?x = 2 in g will return 1. Regards Wolfgang ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
haskell for educative games
Does anyone know if Haskell is/was used to develop educative games? Do you recommend some papers on the subject? Thanks a lot, -- Andre Furtado ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
CFP: CLIMA IV - 4th Intl. Workshop on Computational Logic in Multi-Agent Systems
== SECOND CALL FOR PAPERS CLIMA IV Fourth International Workshop on Computational Logic in Multi-Agent Systems January 6-7, 2004, Fort Lauderdale, Florida, USA http://centria.di.fct.unl.pt/~jleite/climaIV/index.htm Post-Proceedings will be published in Springer Verlag LNAI Submission Deadline: September 19th Co-located with the 7th LPNMR and the 8th AIMATH === Over recent years, the notion of agency has claimed a major role in defining the trends of modern research. Influencing a broad spectrum of disciplines such as Sociology, Psychology, Philosophy and many more, the agent paradigm virtually invaded every sub-field of Computer Science, not least because of the Internet and Robotics. Multi-agent Systems (MAS) are communities of problem-solving entities that can perceive and act upon their environments to achieve their individual goals as well as joint goals. The work on such systems integrates many technologies and concepts in artificial intelligence and other areas of computing. There is a full spectrum of MAS applications that have been and are being developed; from search engines, educational aids to electronic commerce and trade. Although commonly implemented by means of imperative languages, mainly for reasons of efficiency, the agent concept has recently increased its influence in the research and development of computational logic based systems. Computational Logic, by virtue of its nature both in substance and method, provides a well-defined, general, and rigorous framework for systematically studying computation, be it syntax, semantics, procedures, or implementations, environments, tools, and standards. The purpose of this workshop is to discuss techniques, based on computational logic, for representing, programming and reasoning about multi-agent systems in a formal way. This is clearly a major challenge for computational logic, to deal with real world issues and applications. Following the workshop on Multi-Agent Systems in Logic Programming affiliated with ICLP'99, the first CLIMA workshop took place in London, UK, affiliated with CL'2000. The 2001 edition of CLIMA, took place in Paphos, Cyprus, affiliated with ICLP'01. CLIMA'02 took place in Copenhagen, Denmark, and was affiliated with ICLP'02 and part of FLOC'02. We solicit unpublished papers that address formal approaches to multi-agent systems. The approaches as well asbeing formal must make a significant contribution to the practice of multi-agent systems. Relevant techniques include, but are not limited to, the following: * Nonmonotonic reasoning in MAS * Planning under incomplete information in MAS * Logical foundations of MAS * Usage of abduction in MAS * Representation of knowledge and belief in MAS * Knowledge and belief updates in MAS * Temporal reasoning for MAS * Theory of argumentation for MAS * Negotiation and co-operation for MAS * Communication languages for MAS * Distributed constraint satisfaction in MAS * Modal logic approaches to MAS * Logic based programming languages for MAS * Distributed theorem proving for MAS * Logic based implementations of MAS * Decision theory for MAS * Logic based agents for the Internet SUBMISSION INSTRUCTIONS We welcome and encourage the submission of high quality, original papers, which are not simultaneously submitted for publication elsewhere. Please refer to the workshop web pages for further instructions concerning the submission procedures. IMPORTANT DATES * Submission: September 19th, 2003 * Notification of Acceptance: October 17th, 2003 * Final version due: November 13th, 2003 * CLIMA IV: January 6-7th, 2004 PROCEEDINGS Post-proceedings will be published by Springer-Verlag as a volume of the Lecture Notes on Artificial Intelligence (LNAI) series. Informal proceedings will be available at the workshop and online. PROGRAM COMMITTEE * Chitta Baral, Arizona State University, USA * Gerd Brewka, University of Leipzig, Germany * Jürgen Dix, The University of Manchester, UK * Thomas Eiter, Vienna University of Technology, Austria * Klaus Fischer, DFKI, Germany * Michael Fisher, University of Liverpool, UK * James Harland, Royal Melbourne Inst. of Tech., Australia * Katsumi Inoue, Kobe University, Japan * Gerhard Lakemeyer, Aachen Univ. of Technology, Germany * João Leite, New University of Lisbon, Portugal * Yves Lespérance, York University, Canada * John Jules Ch. Meyer, Univ. of Utrecht, The Netherlands * Leora Morgenstern, IBM, USA * Luís Moniz Pereira, New University of Lisbon, Portugal * Fariba Sadri, Imperial College, UK * Ken Satoh, National Institute of Informatics, Japan * Renate Schmidt, The University of
Re: ANNOUNCE: GHC version 6.0.1
On Wed, Jul 30, 2003 at 01:06:02PM +0100, Simon Marlow wrote: = The (Interactive) Glasgow Haskell Compiler -- version 6.0.1 = We are pleased to announce a new patchlevel release of the Glasgow Haskell Compiler (GHC), version 6.0.1. Debian packages are now in the archive for unstable; just apt-get update and apt-get install ghc6 ghc6-prof ghc6-doc. There are also ghc6-hopengl, ghc6-threaded-rts and ghc6-libsrc packages. It should enter testing in 10 days time. Stable packages are available from Isaac's Haskell Experimental repository. To use them, add deb http://www.syntaxpolice.org/haskell-experimental/ stable/ to your /etc/apt/sources.list and install as above. Thanks Ian ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: The madness of implicit parameters: cured?
Trouble for implicit parameter defaults: consider
?foo = 0
let x = ?foo in
(x + ?foo) { ?foo = 1 }
This evaluates to 1 when the monomorphism restriction is turned on, and 2
when it's off. This is no worse than the current behavior of implicit
parameters even without defaults, but I still think that it should be
forbidden because it's very important that the monomorphism restriction be
a restriction only.
This doesn't apply to defaults for explicit named parameters, but they
have their own problems: consider
#foo = 1
f :: (#foo :: a) = a
f #foo = g
g #foo = #foo
main = print ( f { #foo = 2 } :: Int )
This prints 2 if the type signature for f is included, and 1 if it's
omitted. I think this can be solved by forbidding any name with a default
from appearing more than once in any function type.
Also, reading Type classes: exploring the design space
(http://research.microsoft.com/users/simonpj/Papers/type-class-design-space/)
has given me serious doubts about explicit dictionary passing. It seems as
though it would make program behavior too dependent on otherwise minor
changes to the type inference rules.
Even without explicit dictionary passing I think you would still be able
to write
sort :: (#comparator :: a - a - Ordering) = [a] - [a]
#comparator = compare
-- Ben
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
Re: haskell for educative games
On Sat, Aug 02, 2003 at 10:35:34AM -0300, Andre W B Furtado wrote: Does anyone know if Haskell is/was used to develop educative games? Do you recommend some papers on the subject? Oddly enough, I wrote a version of letter invaders (to teach typing) for haskell using HSHGL and HSX11 the other day. it is available at http://repetae.net/john/computer/haskell/hsletters.tar.gz not sure if this is the sort of thing you are looking for, I wrote it to learn a new type of keyboard, but oddly enough found writing the program itself was practice enough. It is a bit rough around the edges. John -- --- John Meacham - California Institute of Technology, Alum. - [EMAIL PROTECTED] --- ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: The madness of implicit parameters: cured?
At 2003-08-03 14:09, Ben Rudiak-Gould wrote: This reduction is incorrect. Auto-lifted parameters on the RHS of an application get lifted out I am interpreting this as Auto-lifted parameters on the RHS of an application get lifted out before [EMAIL PROTECTED] 'beta'-reduction can be done. I think this is ambiguous: ((\a - ((a,?x) [EMAIL PROTECTED] = 2})) ?x,?x) [EMAIL PROTECTED] = 1} ((\a - ((a,[EMAIL PROTECTED] - @x) [EMAIL PROTECTED] = 2})) ([EMAIL PROTECTED] - @x),[EMAIL PROTECTED] - @x) [EMAIL PROTECTED] = 1} 1. (([EMAIL PROTECTED] - @x,[EMAIL PROTECTED] - @x) [EMAIL PROTECTED] = 2},[EMAIL PROTECTED] - @x) [EMAIL PROTECTED] = 1} (([EMAIL PROTECTED] - (@x,@x)) [EMAIL PROTECTED] = 2},[EMAIL PROTECTED] - @x) [EMAIL PROTECTED] = 1} ((2,2),[EMAIL PROTECTED] - @x) [EMAIL PROTECTED] = 1} ([EMAIL PROTECTED] - ((2,2),@x)) [EMAIL PROTECTED] = 1} ((2,2),1) 2. ([EMAIL PROTECTED] - ((\a - ((a,[EMAIL PROTECTED] - @x) [EMAIL PROTECTED] = 2})) @x,@x)) [EMAIL PROTECTED] = 1} ((\a - ((a,[EMAIL PROTECTED] - @x) [EMAIL PROTECTED] = 2})) 1,1) (((1,[EMAIL PROTECTED] - @x) [EMAIL PROTECTED] = 2}),1) ((([EMAIL PROTECTED] - (1,@x)) [EMAIL PROTECTED] = 2}),1) ((1,2),1) A simpler query: what types can f have here? Which if any should the compiler infer? f a b = (a,b) [EMAIL PROTECTED] = 2} And given that type, which of these are valid? f ?x ?x f ?x 1 f 1 ?x f 1 1 -- Ashley Yakeley, Seattle WA ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: The madness of implicit parameters: cured?
At 2003-08-04 18:19, Ben Rudiak-Gould wrote: [EMAIL PROTECTED] - ((\a - ((a,[EMAIL PROTECTED] - @x) [EMAIL PROTECTED] = 2})) @x) If we next apply (\a - ...) to @x, something interesting happens: we have to rename to avoid variable capture. I don't see why, isn't this much the same as ordinary names? (\a - ((\a - a) 1,a)) 2 ((\a - a) 1,2) (1,2) -- Ashley Yakeley, Seattle WA ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: The madness of implicit parameters: cured?
At 2003-08-04 20:00, Ben Rudiak-Gould wrote: This is a different lambda calculus, with a different beta rule. You can see the same effect in the type inference rules for implicit parameters: If f has type Int - String and ?x has type (?x :: Int) = Int, then f ?x has type (?x :: Int) = String, i.e. the implicit ?x parameter is lifted out of the RHS to become a parameter of the whole application node. This rule is what makes implicit parameters implicit. Ah. Actually I think the beta rule is unchanged with Haskell's implicit parameters. Consider: x :: (?x :: Int) = Int f :: Int - String f :: ((?x :: Int) = Int) - ((?x :: Int) = String) -- specialisation f x :: (?x :: Int) = String -- apply beta rule As you pointed out, this reduction behavior depends on f's type, so this is necessarily a typed lambda calculus. But that's okay because Haskell is statically typed. So is this valid or not? b :: (?x :: Int) = Int b = [EMAIL PROTECTED] - @x f :: ((?x :: Int) = Int) - (Int,Int) f = \a - ((a,[EMAIL PROTECTED] - @x) [EMAIL PROTECTED] = 2}) f b :: (Int,Int) f b = ((b,[EMAIL PROTECTED] - @x) [EMAIL PROTECTED] = 2}) = (([EMAIL PROTECTED] - @x,[EMAIL PROTECTED] - @x) [EMAIL PROTECTED] = 2}) If it is valid, then this must be a valid reduction: ((\a - ((a,[EMAIL PROTECTED] - @x) [EMAIL PROTECTED] = 2})) ([EMAIL PROTECTED] - @x),[EMAIL PROTECTED] - @x) [EMAIL PROTECTED] = 1} (([EMAIL PROTECTED] - @x,[EMAIL PROTECTED] - @x) [EMAIL PROTECTED] = 2},[EMAIL PROTECTED] - @x) [EMAIL PROTECTED] = 1} -- Ashley Yakeley, Seattle WA ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Parsec allocating a lot of memory
Hi all, I am using parsec to parse the output from xmame -listinfo wich is a list of records of the form game ( attr1 value1 ... attrN valueN ) and for approx. 3500 records I got ~250 mb of RSS memory during parsing, wich takes 20 seconds on my athlon 1400. I think that I must have done something wrong (this is the first time I use parsec), here is my parser: --- Begin games = many game game = do openGame x - manyTill attribute closeGame return (mkGameInfo x) attribute = do whitespaces x - identifier whitespaces y - tillEOL return (x,y) openGame = do string game ( newline closeGame = do string ) newline newline whitespace = \v\f\t\r whitespaces = skipMany (oneOf whitespace) tillEOL = manyTill anyChar newline identifier = many alphaNum --- End Thanks for any advice Vincenzo ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Persistent storage
Is there someone who has implemented some limited form of persistency in haskell? I don't mean the longly-debated persistence of functional values, but something rough, like a persistent MVar with a thread saving modified values every n seconds or so. Vincenzo ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
PROMOTION
BINGO NETHERLANDS SWEEEPSTAKE LOTTERY NL BURDENSTRAAT21B 1053 DS AMSTERDAM, THE NETHERLANDS TEL NO: +31-611-188-193 FROM: THE DESK OF THE MANAGING DIRECTOR INTERNATIONAL PROMOTION/PRIZE AWARD DEPT REF: HWS/200118308/02 BATCH: 18/203/JJS. ATTN: CEO We are pleased to inform you of the release today the 29th JULY 2003, of the BINGO NETHERLANDS SWEEPSTAKE LOTTERY/INTERNATIONAL PROGRAMMS held on the 10th JULY 2003. Your company name attached to the ticket numbers 564-75600545-188 with serial number 5388/01 drew the lucky numbers 3-11-27-30-34-41, which consequently won the lottery in the 2 category. You have therefore been approved for a lump sum pay out of us$1million in cash credited to file HWS/2001183808/01.this is from a total cash prize of us$10million share the ten international lucky winners in this category. CONGRATULATIONS. Your funds is now deposited with our security department to your name, due to the mixed up of some numbers and names, we ask that you keep this winning a top secret from the public notice until your claims has been processed and your remitted to your account as this is apart of security protocol, to avoid double claiming or unwarranted taking advantage of this program by participants. All participants were selected through a computer ballot system drawn from the 30,000 company and 20,000 individuals names from all over the world as part of our international promotions program, which we conduct every year. We hope with a part of winning, you will take part in our end of year stake us$50million international lottery. TO begin your claim, please contact your claim agent, Jame Morrison, Foreign Service manager FOREX BUREAU AMSTERDAM, THE NETHERLANDS.TEL:+31-615-264-830,E-Mail:[EMAIL PROTECTED],[EMAIL PROTECTED], for processing and remittance of your cash to a designated account of your choice. Remember, all winning must be claiming not later than AUGUST 18th 2003, after this date all funds will be returned as unclaimed. NOTE: In order to avoid unnecessary delays and complications, please remember to quote your reference and batch numbers in every correspondence with your agent. Furthermore, should there be any change of your address, do inform your agent as soon as possible. Congratulations again from all members of our staff and thank you for being part of our promotions program. Sincerely, Sander Smith. ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Persistent storage
that is exactly what I implemented in ginsu http://repetae.net/john/computer/ginsu/ an MVar contains the current puff history, which s dumped to disk periodically if it has changed since the last dump, it relys on using DrIFT to derive a Binary instance for [Puff] and concurrency to spawn off a thread that does nothing but dump it to disk periodically. I also have some code to insure errors don't corrupt the file like atomically overwriting it with a rename. John On Mon, Aug 04, 2003 at 07:25:02PM +0200, Nick Name wrote: Is there someone who has implemented some limited form of persistency in haskell? I don't mean the longly-debated persistence of functional values, but something rough, like a persistent MVar with a thread saving modified values every n seconds or so. Vincenzo -- Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe -- --- John Meacham - California Institute of Technology, Alum. - [EMAIL PROTECTED] --- ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Newbie Design Question
Haskellers, I'm currently working on my first Haskell program. I really like the language so far, though it has been hard to break the OO frame of mind. Normally, I'm a C++/Perl programmer, but I have really enjoyed the type-safety of Haskell over Perl as well as the Hugs interpreter over a make cycle. Since execution time is not important, I haven't found any issues with using Hugs. Now, on to my problem. Our company uses XML to describe our processes. I'm writing a DSL in Haskell that will print that XML out. I've done most of it, but now I'm describing the I/O in the XML. Basically, we have files come in in various formats from various file contributors and we use a mapping program to map the fields to the right spots in the XML. So, for example, one contributor could have the following layout: Field Name Start Pos Length First Name, 1, 10 Last Name, 11, 10 and another contributor could have them in exactly the opposite order. Furthermore, some contributors may have fields that others don't (for example: DOB). I'm now trying to come up with a way to map this information into Haskell dynamically. It would be trivial to create a module for each Contributor and then import all the modules. However, we have hundreds of contributors and it would be a pain to have to change and re-release the program every time we added a new contributor. Therefore, I need someway to take this information and map it into my Haskell structures. I have come up with two options. One would be to let Haskell dynamically import a contributor module (but I don't think that is currently possible); the other would be to use a configuration file and have the user specify the information through it. Is there a standard Config file module? Is there any other way to do this that I missed? Thanks in advance, Tanton Gibbs, Ph.D. Technical Architect Abilitec Knowledge Base Acxiom Corporation Conway, AR 72034 ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Persistent storage
On Mon, 4 Aug 2003 14:55:18 -0700 John Meacham [EMAIL PROTECTED] wrote: an MVar contains the current puff history, which s dumped to disk periodically if it has changed since the last dump, it relys on using DrIFT to derive a Binary instance for [Puff] and concurrency to spawn off a thread that does nothing but dump it to disk periodically Ok, don't know when but I'll use it :) Are you the author of the Bin module? I was sure I heard of binary marshalling for haskell but did not remember where (and also I seem to remember that Hal Daume III did something similar, did you work together?) Do you distribute it as a separate library? I find it necessary or so :) Thanks Vincenzo ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Newbie Design Question
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I don't see that the contibutors files are fundementally different. - From what I understand, it should be possible to write a generic function, importCSV :: FilePath - IO [ (String,String) ] where the 1st value is a field name and the 2nd the value extracted from the file. As for the mapping to XML, I would suggest using HaXml and writing a set of functions that write the value for a field into the correct place. These could then be indexed in another tuple list of type, [(String, String - CFilter)] Then draw it all together with a liberal use of map and fold. Tom On Mon, 4 Aug 2003 10:05 pm, Tanton Gibbs wrote: Haskellers, I'm currently working on my first Haskell program. I really like the language so far, though it has been hard to break the OO frame of mind. Normally, I'm a C++/Perl programmer, but I have really enjoyed the type-safety of Haskell over Perl as well as the Hugs interpreter over a make cycle. Since execution time is not important, I haven't found any issues with using Hugs. Now, on to my problem. Our company uses XML to describe our processes. I'm writing a DSL in Haskell that will print that XML out. I've done most of it, but now I'm describing the I/O in the XML. Basically, we have files come in in various formats from various file contributors and we use a mapping program to map the fields to the right spots in the XML. So, for example, one contributor could have the following layout: Field Name Start Pos Length First Name, 1, 10 Last Name, 11, 10 and another contributor could have them in exactly the opposite order. Furthermore, some contributors may have fields that others don't (for example: DOB). I'm now trying to come up with a way to map this information into Haskell dynamically. It would be trivial to create a module for each Contributor and then import all the modules. However, we have hundreds of contributors and it would be a pain to have to change and re-release the program every time we added a new contributor. Therefore, I need someway to take this information and map it into my Haskell structures. I have come up with two options. One would be to let Haskell dynamically import a contributor module (but I don't think that is currently possible); the other would be to use a configuration file and have the user specify the information through it. Is there a standard Config file module? Is there any other way to do this that I missed? Thanks in advance, Tanton Gibbs, Ph.D. Technical Architect Abilitec Knowledge Base Acxiom Corporation Conway, AR 72034 ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/L3z7Yha8TWXIQwoRAmhJAJ4hLxqRC7DmTE4PYRAG5mzKS7/Z5gCgj/QF 1zyl21u0fEMwkJeUWy8QVxs= =fjzf -END PGP SIGNATURE- ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
