[ ghc-Bugs-1363942 ] nativeGen/MachRegs.lhs:1016: parse error
Bugs item #1363942, was opened at 2005-11-22 16:22 Message generated for change (Comment added) made by simonmar You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1363942group_id=8032 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Compiler Group: None Status: Closed Resolution: Fixed Priority: 5 Submitted By: John Goerzen (jgoerzen) Assigned to: Nobody/Anonymous (nobody) Summary: nativeGen/MachRegs.lhs:1016: parse error Initial Comment: I am attempting to build GHC 6.4.1 on AIX 5.1L using GHC 6.2.1 as the host compiler. Everything proceeds fine until the crash here. I believe that the problem is that no content for the callClobberedRegs defined for AIX. In particular, powerpc_TARGET_ARCH will be defined, but there is no clause in that file for PowerPC. I will attach a build log. -- Comment By: Simon Marlow (simonmar) Date: 2005-11-23 12:21 Message: Logged In: YES user_id=48280 Fixed to omit building the NCG on AIX by default. -- Comment By: John Goerzen (jgoerzen) Date: 2005-11-22 16:27 Message: Logged In: YES user_id=491567 a further comment: perhaps this is a configure error -- nativeGen still isn't available on AIX, is it? I just ran ./configure --prefix=/usr/local to start this. -- Comment By: John Goerzen (jgoerzen) Date: 2005-11-22 16:23 Message: Logged In: YES user_id=491567 Forgot to add: using GCC 4.0.3. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1363942group_id=8032 ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-1364837 ] AdjustorAsm.S doesn't build on AIX
Bugs item #1364837, was opened at 2005-11-23 12:09 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1364837group_id=8032 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Compiler Group: None Status: Open Resolution: None Priority: 5 Submitted By: John Goerzen (jgoerzen) Assigned to: Nobody/Anonymous (nobody) Summary: AdjustorAsm.S doesn't build on AIX Initial Comment: OK, this is a weird one. I'm building GHC 6.4.1 on AIX and using IBM's assembler, since GNU binutils is known to have issues on AIX. When the build reached AdjustorAsm.S, I got: imer.h -#include ProfHeap.h -#include LdvProfile.h -#include Profiling.h -#inclu de Apply.h -fvia-C -dcmm-lint -c AdjustorAsm.S -o AdjustorAsm.o Assembler: /tmp//ccq7dlbU.s: line 15: 1252-016 The specified opcode or pseudo-op is not val id. Use supported instructions or pseudo-ops only. /tmp//ccq7dlbU.s: line 48: 1252-149 Instruction subf is not implemented in the c urrent assembly mode COM. /tmp//ccq7dlbU.s: line 52: 1252-142 Syntax error. /tmp//ccq7dlbU.s: line 53: 1252-142 Syntax error. /tmp//ccq7dlbU.s: line 58: 1252-142 Syntax error. /tmp//ccq7dlbU.s: line 59: 1252-142 Syntax error. make[2]: *** [AdjustorAsm.o] Error 1 After some research, I added -opta -Wa,-mppc, which reduced the errors to: /tmp//ccA1yNhC.s: line 15: 1252-016 The specified opcode or pseudo-op is not val id. Use supported instructions or pseudo-ops only. /tmp//ccA1yNhC.s: line 52: 1252-142 Syntax error. /tmp//ccA1yNhC.s: line 53: 1252-142 Syntax error. /tmp//ccA1yNhC.s: line 58: 1252-142 Syntax error. /tmp//ccA1yNhC.s: line 59: 1252-142 Syntax error. I examined the temp files and found that line 15 contains only the word .text. I was finally able to work around the problem by adding -opta -save-temps to the command line, then using GNU as like so: as mppc -I. AdjustorAsm.s -o AdjustorAsm.o I then copied the resulting .o file to the thr, p, debug, etc. .o files. The build was then able to complete. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1364837group_id=8032 ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-1364839 ] Cabal tries to build ghci libraries on install
Bugs item #1364839, was opened at 2005-11-23 12:11 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1364839group_id=8032 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build System Group: None Status: Open Resolution: None Priority: 5 Submitted By: John Goerzen (jgoerzen) Assigned to: Nobody/Anonymous (nobody) Summary: Cabal tries to build ghci libraries on install Initial Comment: This is with GHC 6.4.1. ghci is not supported on AIX. I recently tried to isntall MissingH with Cabal. I got: # ./setup install Installing: /usr/local/lib/MissingH-0.12.0 /usr/local/bin MissingH-0.12.0... Registering MissingH-0.12.0... Reading package info from .installed-pkg-config ... done. building GHCi library /usr/local/lib/MissingH-0.12.0/HSMissingH-0.12.0.o...ld: 0706-027 The -x flag is ignored. ld: 0706-012 The -- flag is not recognized. ld: 0706-012 The -w flag is not recognized. ld: 0706-012 The -h flag is not recognized. ghc-pkg list does not see the package after this, either. I'm not sure why Cabal seems to think it needs to build a GHCi library, and it's even more concerning that invalid flags are being given to ld. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1364839group_id=8032 ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: GHC targetting Java?
| On a similar note, how about the .NET support? Can it work on a | platform where the only .NET support is Mono? This comes up regularly. Here's my message from Jan: http://www.haskell.org/pipermail/glasgow-haskell-users/2005-January/0075 94.html Simon === It'd make a lot of sense to give GHC a .NET back end, and it's a question that comes up regularly. The reason that we haven't done it here, at GHC HQ, is because it's a more substantial undertaking than might at first appear (see below). Furthermore, it'd permanently add a complete new back-end platform for us to maintain. Given our rather limited development effort (= Simon and me), we have so far not bitten the bullet, and we have no immediate plans to do so. It'd be a good, well-defined project for someone else to tackle, and there is some good groundwork already done: * Sigbjorn Finne did a simple interop implementation that allows a Haskell program to be compiled to native code (as now) but to call .NET programs via a variant of the FFI. I don't think this work is in active use, and I'd be surprised if it worked out of the box, but it could probably be revived with modest effort * Andre Santos and his colleagues at UFPE in Brazil are working on a .NET back end, that generates CLR IL, though I don't know where they are up to. * [This para wasn't in the original message] Nigel Perry and Oliver Hunt have a Haskell.NET prototype that works using GHC to compile to Core, and then compiling Core to NET. I'm not sure what stage it is at. * GHC.Net would be extra attractive if there was a Visual Studio integration for GHC. Substantial progress on this has been made in 2004 by Simon Marlow, Krasimir Angelov, and Andre Santos and colleagues. There may be others that I don't know of. If anyone wants to join in this effort, do contact the above folk. And please keep us informed! Simon Here's a summary of why it's a non-trivial thing to do: * The first thing is to generate native CLR Intermediate Language (IL). That's not really hard. Requires thinking about representations for thunks and functions, and it may not be particularly efficient, but it can surely be done. An open question is about whether to generate verifiable IL or not. The trouble here is that Haskell's type system is more expressive than the CLR's in some ways, notably the use of higher-kinded type variables. So, to generate verifiable IL one is bound to need some run-time casts, and it's not clear how to minimise these. At first blush this is *all* you need do. But it isn't! * Next, you need to think about how to inter-operate with .NET libraries. You don't really want to write foreign import... for each and every import. You'd like GHC to read the CLR meta-data directly. But there are lots of tricky issues here; see the paper that Mark Shields and I wrote about Object-oriented style overloading for Haskell. * Now you need to figure out how to implement GHC's primitive operations: the I/O monad arbitrary precision arithmetic concurrency exceptions finalisers stable pointers software transactional memory Not all of these are necessary, of course, but many are used in the libraries. The CLR supports many of them (e.g. concurrency) but with a very different cost model. * Last, you have to figure out what to do for the libraries. GHC has a pretty large library, and you either have to implement the primops on which the library is based (see previous point), or re-implement it. For example, GHC's implementation of I/O uses mutable state, concurrency, and more besides. For each module, you need to decide either to re-implement it using .NET primitives, or to implement the stuff the module is based on. These challenges are mostly broad rather than deep. But to get a production quality implementation that runs a substantial majority of Haskell programs out of the box requires a decent stab at all of them. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: adding to GHC/win32 Handle operations support of Unicode filenamesand files larger than 4 GB
This sounds like a good idea to me.
As far as possible, we should keep the platform-dependence restricted to
the implementation of one module (System.Posix.Internals will do, even
though this isn't really POSIX any more). So System.Posix.Internals
exports the CFilePath/CFileOffset types, and the foreign functions that
operate on them.
Alternatively (and perhaps this is better), we could hide the difference
even further, and provide functions like
rmDir :: FilePath - IO CInt
in System.Posix.Internals. Similarly for functions that operate on
COff, they would take/return Integer (eg. we already have
System.Posix.fdFileSize).
As regards whether to use feature tests or just #ifdef mingw32_HOST_OS,
in general feature tests are the right thing, but sometimes it doesn't
buy you very much when there is (and always will be) only one platform
that has some particular quirk. Writing a bunch of autoconf code that
would, if we're lucky, handle properly the case when some future version
of Windows removes the quirk, is not a good use of developer time.
Furthermore, Windows hardly ever changes APIs, they just add new ones.
So I don't see occasional use of #ifdef mingw32_HOST_OS as a big deal.
It's more important to organise the codebase and make sure all the
#ifdefs are behind suitable abstractions.
Cheers,
Simon
On 21 November 2005 12:01, Bulat Ziganshin wrote:
Simon, what you will say about the following plan?
ghc/win32 currently don't support operations with files with Unicode
filenames, nor it can tell/seek in files for positions larger than 4
GB. it is because Unix-compatible functions open/fstat/tell/... that
is supported in Mingw32 works only with char[] for filenames and
off_t (which is 32 bit) for file sizes/positions
half year ago i discussed with Simon Marlow how support for unicode
names and large files can be added to GHC. now i implemented my own
library for such files, and got an idea how this can incorporated to
GHC with minimal efforts:
GHC currently uses CString type to represent C-land filenames and COff
type to represent C-land fileseizes/positions. We need to
systematically change these usages to CFilePath and CFileOffset,
respectively, defined as follows:
#ifdef mingw32_HOST_OS
type CFilePath = LPCTSTR
type CFileOffset = Int64
withCFilePath = withTString
peekCFilePath = peekTString
#else
type CFilePath = CString
type CFileOffset = COff
withCFilePath = withCString
peekCFilePath = peekCString
#endif
and of course change using of withCString/peekCString, where it is
applied to filenames, to withCFilePath/peekCFilePath (this will touch
modules System.Posix.Internals, System.Directory, GHC.Handle)
the last change needed is to conditionally define all c_* functions
in System.Posix.Internals, whose types contain references to filenames
or offsets:
#ifdef mingw32_HOST_OS
foreign import ccall unsafe HsBase.h _wrmdir
c_rmdir :: CFilePath - IO CInt
#else
foreign import ccall unsafe HsBase.h rmdir
c_rmdir :: CFilePath - IO CInt
#endif
(note that actual C function used is _wrmdir for Windows and rmdir for
Unix). of course, all such functions defined in HsBase.h, also need to
be defined conditionally, like:
#ifdef mingw32_HOST_OS
INLINE time_t __hscore_st_mtime ( struct _stati64* st ) { return
st-st_mtime; } #else
INLINE time_t __hscore_st_mtime ( struct stat* st ) { return
st-st_mtime; } #endif
That's all! of course, this will broke compatibility with current
programs which directly uses these c_* functions (c_open, c_lseek,
c_stat and
so on). this may be issue for some libs. are someone really use these
functions??? of course, we can go in another, fully
backward-compatible way, by adding some f_* functions and changing
high-level modules to work with these functions
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Patch: Add support for using --mk-dll with --make
On 21 November 2005 22:03, Esa Ilari Vuokko wrote: Attached small simple patch that allows using --mk-dll with --make. Behaviour before patch was to link .exe instead .dll, as batchmode simply called staticLink - now doMkDLL is called instead. * Add support for using --mk-dll with --make I changed documentation a bit, and moved --mk-dll from 4.17.3 Alternative modes of operation into 4.17.21 Linking options. This documentation change isn't tested, as I don't have necessary tools installed on my machine. But it *seems* harmless (and I think, more intuitive.) Due to lack of tools, and because there's little to say, I didn't touch 11.5. Building and using Win32 DLLs. Patch should apply cleanly on cvs HEAD with patch -p0 under fptools. Any comments are welcome. Committed, thanks! Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Problems with 6.x compilers
On 22 November 2005 17:18, Michael Marte wrote: I am having some annoying problems with the 6.x compilers: 6.4 and 6.4.1: When repeating a build (with ghc --make) all modules are rebuild even if nothing has changed. With earlier compilers, only linking takes place in this setting. Can I change this behaviour? I cannot develop this way. Should not happen, if it does there is a bug. Can you tell us how to repeat the behaviour you're seeing? We aren't seeing any unecessary recompilation here. 6.2 and up: The object file is named after the module, not after the source file as in 5.04. As there are several main modules in my project, each in its own source file, all I get is a big mess. Any suggestions? The object file is named after the source file, unless you use -odir. The behaviour is clearly specified in the user's guide: http://www.haskell.org/ghc/docs/latest/html/users_guide/separate-compila tion.html#output-files the behaviour has been through several revisions before we arrived at this, and I'm not keen to change it. You can have several Main modules in the same directory if you don't use -odir. If you do use -odir, then you need to use a different value for -odir for each different program. Alternatively use -main-is, as Bulat suggested (actually this is better, IMO). Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: GHC targetting Java?
On 23 November 2005 09:32, Simon Peyton-Jones wrote: On a similar note, how about the .NET support? Can it work on a platform where the only .NET support is Mono? This comes up regularly. Here's my message from Jan: http://www.haskell.org/pipermail/glasgow-haskell-users/2005-January/0075 94.html Added to the FAQ. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Problems with 6.x compilers
6.4 and 6.4.1: When repeating a build (with ghc --make) all modules are rebuild even if nothing has changed. With earlier compilers, only linking takes place in this setting. Can I change this behaviour? I cannot develop this way. Should not happen, if it does there is a bug. Can you tell us how to repeat the behaviour you're seeing? We aren't seeing any unecessary recompilation here. I think I had that effect exactly when using -ddump-minimal-imports Wolfram ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Problems with 6.x compilers
Simon, On Wed, 23 Nov 2005, Simon Marlow wrote: On 22 November 2005 17:18, Michael Marte wrote: I am having some annoying problems with the 6.x compilers: 6.4 and 6.4.1: When repeating a build (with ghc --make) all modules are rebuild even if nothing has changed. With earlier compilers, only linking takes place in this setting. Can I change this behaviour? I cannot develop this way. Should not happen, if it does there is a bug. Can you tell us how to repeat the behaviour you're seeing? We aren't seeing any unecessary recompilation here. Like Wolfram Kahl, I am using -ddump-minimal-imports. I cannot check whether the use of this option causes the problem, because I returned to 6.2 already to continue porting my project from ghc 5. 6.2 and up: The object file is named after the module, not after the source file as in 5.04. As there are several main modules in my project, each in its own source file, all I get is a big mess. Any suggestions? The object file is named after the source file, unless you use -odir. The behaviour is clearly specified in the user's guide: http://www.haskell.org/ghc/docs/latest/html/users_guide/separate-compila tion.html#output-files the behaviour has been through several revisions before we arrived at this, and I'm not keen to change it. You can have several Main modules in the same directory if you don't use -odir. If you do use -odir, then you need to use a different value for -odir for each different program. Alternatively use -main-is, as Bulat suggested (actually this is better, IMO). I followed the suggestion of Bulat: I renamed the modules and used -main-is. Thanks everybody! Michael ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Checking for WHNF (a horrible naughty thing)
I would like to do a horrible naughty thing (which I promise never to expose to the world). I would like to tell whether a term is in WHNF, without forcing evaluation of that term. Something like: isWHNF :: a - Bool Is there a way of doing this? I can fake it with an IORef and much unsafeness, but I'm wondering if there's a safe-but-ugly way of doing the test in GHC. If you're curious, I'm trying to compact exactly the evaluated spine of a list without changing the list's laziness in any way. It remains to be seen whether this is even vaguely a good idea. :-) -Jan-Willem Maessen ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
problem using ghc-6.5.20051122-i386-unknown-linux.tar.bz2
I downloaded ghc-6.5.20051122-i386-unknown-linux.tar.bz2 and tried to use it (as bootstrap for building Haskell at first, but building Pugs fails the same way) It installed fine. My attempts to compile something with it result with a following error: ghc-6.5.20051122: could not execute: gcc-3.4.3 ghc: 16599408 bytes, 3 GCs, 123124/123124 avg/max bytes residency (1 samples), 15M in use, 0.00 IN IT (0.00 elapsed), 0.11 MUT (0.21 elapsed), 0.02 GC (0.03 elapsed) :ghc Indeed, the compiler I have has version gcc-3.3.4, and this mismatches with gcc-3.4.3, also How should I avoid this problem? Why having that precise requirement of GCC version? Best regards, Vadim. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Checking for WHNF (a horrible naughty thing)
The appended snippet might help..
--sigbjorn
-- whnf.hs
import Foreign.StablePtr
import System.IO.Unsafe
isWHNF :: a - Bool
isWHNF a = unsafePerformIO $ do
stl - newStablePtr a
rc - isWhnf stl
freeStablePtr stl
return (rc /= 0)
foreign import ccall safe isWhnf isWhnf :: StablePtr a - IO Int
/* whnf.c */
#include Rts.h
int
isWhnf(StgStablePtr st)
{
StgClosure* c = (StgClosure*)(stable_ptr_table[(StgWord)st].addr);
return !(closure_THUNK(c));
}
- Original Message -
From: Jan-Willem Maessen [EMAIL PROTECTED]
To: glasgow-haskell-users glasgow-haskell-users@haskell.org
Sent: Wednesday, November 23, 2005 08:10
Subject: Checking for WHNF (a horrible naughty thing)
I would like to do a horrible naughty thing (which I promise never to
expose to the world). I would like to tell whether a term is in
WHNF, without forcing evaluation of that term. Something like:
isWHNF :: a - Bool
Is there a way of doing this? I can fake it with an IORef and much
unsafeness, but I'm wondering if there's a safe-but-ugly way of doing
the test in GHC.
If you're curious, I'm trying to compact exactly the evaluated spine
of a list without changing the list's laziness in any way. It
remains to be seen whether this is even vaguely a good idea. :-)
-Jan-Willem Maessen
___
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[2]: Patch for Word64
Hello Simon, Wednesday, November 23, 2005, 2:28:26 PM, you wrote: SM int64ToWord64# = unsafeCoerce# SM word64ToInt64# = unsafeCoerce# SM this should reduce the cost of the conversions to zero, which is a SM simpler way to fix the performance bug (if it works). SM If you confirm that this also improves performance, I'll commit it. If SM not, I'll commit your patch instead. please don't forget about: int32ToWord32# word32ToInt32# intToInt32# int32ToInt# wordToWord32# word32ToWord# int2Word# word2Int# -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re[2]: adding to GHC/win32 Handle operations support of Unicode filenamesand files larger than 4 GB
Hello Simon, Wednesday, November 23, 2005, 2:22:02 PM, you wrote: SM This sounds like a good idea to me. SM As far as possible, we should keep the platform-dependence restricted to SM the implementation of one module (System.Posix.Internals will do, even SM though this isn't really POSIX any more). So System.Posix.Internals SM exports the CFilePath/CFileOffset types, and the foreign functions that SM operate on them. SM Alternatively (and perhaps this is better), we could hide the difference SM even further, and provide functions like SM rmDir :: FilePath - IO CInt SM in System.Posix.Internals. Similarly for functions that operate on SM COff, they would take/return Integer (eg. we already have SM System.Posix.fdFileSize). well... but not well :) let's consider function c_open for more informative example. between functions c_open and openFile there is several levels of translation: 1) convert C types to Haskell types 2) check for errno and raise exception on error 3) convert interfaces (translate IOMode to CMode in this example) 4) convert file descriptors to Handles you suggestion is to build middle-level library whose functions lie between step 1 and 2 in this scheme: c_open :: CFilePath - CInt - CMode - IO CInt 1) convert C types to Haskell types open :: String - Int - CMode - IO Int 2) check for errno 3) convert interfaces 4) convert file descriptors to Handles This have one obvious benefit - these functions will look very like to its C counterparts. but on the other side, resulting functions will not belong to C, nor to Haskell world - they will use Haskell types but C-specific error signalling moreover, adding such middle-level functions will not help making implementation simpler - all differences between platforms are already covered by definitions of CFilePath/CFileOffset/withCFilePath/peekCFilePath but i propose to make these middle-level functions after stage 2 or even 3 in this scheme - so that they will be fully in Haskell world, only work with file descriptors instead of Handles. for example: lseek :: Integral int = FD - SeekMode - int - IO () lseek h direction offset = do let whence :: CInt whence = case mode of AbsoluteSeek - sEEK_SET RelativeSeek - sEEK_CUR SeekFromEnd - sEEK_END throwErrnoIfMinus1Retry_ lseek $ c_lseek (fromIntegral h) (fromIntegral offset) direction profits: 1) current GHC.Handle code is monolithic, it performs all these 4 steps of translation in one function. this change will simplify this module and concenrate it on solving only one, most complex, task - implementing operations on Handles via operations on FDs 2) part of code in GHC.Handle, what is not really GHC-specific, will be moved to standard hierarchical libraries, where it will become ready to use by other Haskell implementations 3) alternative Handle implementations can use these middle-level functions and not reinvent the wheel. just for example - in http://haskell.org/~simonmar/new-io.tar.gz openFile code is mostly copied from existing GHC.Handle 4) we will get full-fledged FD library on GHC, Hugs and NHC for free 5) if this FD library will have Handle-like interface, it can be used as poor men's drop-in replacement of Handle library in situations where we don't need its buffering and other advanced features so, as first step i propose to move middle-level code from GHC.Handle to Posix.Internals, join FD type definitions, replace CString with CFilePath where appropriate, and so on. and only after this - make changes specific for windows. i can do it all. what you will say? That's all! of course, this will broke compatibility with current programs which directly uses these c_* functions (c_open, c_lseek, c_stat and so on). this may be issue for some libs. are someone really use these functions??? of course, we can go in another, fully backward-compatible way, by adding some f_* functions and changing high-level modules to work with these functions if my changes will be committed only to GHC 6.6 (HEAD) branch, the problem that types of c_* functions is changed will not be a big problem - you anyway change some interfaces between major releases. but now i'm realized that Posix.Internals is part of libraries common for several Haskell compilers. can such changes break their working? moreover, i plan to move throwErrnoIfMinus1RetryOnBlock to Foreign.C.Error, and sEEK_CUR/sEEK_SET/sEEK_END - to Posix.Internals. can it be done? SM As regards whether to use feature tests or just #ifdef mingw32_HOST_OS, SM in general feature tests are the right thing, but sometimes it doesn't SM buy you very much when there is (and always will be) only one platform SM that has some particular quirk. Writing a bunch of autoconf code that SM would, if we're lucky, handle properly the case when some future version SM of Windows removes the quirk, is not a good use of developer time. SM Furthermore, Windows hardly
GHC 6.6
Help build the anticipation: http://haskell.org/hawiki/GHC_206_2e6 Present text: GHC 6.6: Will be out before May 2006. Included: * Parallel GHC * Associated types with class Maybe: * Impredicativity * GADT Typeclass interaction * Data types as kinds No: Jim ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Patch for Word64
Bulat Ziganshin wrote: Hello Simon, Wednesday, November 23, 2005, 2:28:26 PM, you wrote: int64ToWord64# = unsafeCoerce# word64ToInt64# = unsafeCoerce# this should reduce the cost of the conversions to zero, which is a simpler way to fix the performance bug (if it works). If you confirm that this also improves performance, I'll commit it. If not, I'll commit your patch instead. please don't forget about: int32ToWord32# word32ToInt32# intToInt32# int32ToInt# wordToWord32# word32ToWord# int2Word# word2Int# These are already free, as I understand. When I compare Int, Word, Int#, Word#, Int32 (same thing as Int), and Word32 (same thing as Word), they have identical performance. It is Int64/Word64/Int64#/Word64# that are abysmal. I will continue as time allows and make the suggested changes, but I thought that the original patch also makes sense. Compare these definitions from the original Word.hs file: (W# x#) + (W# y#) = W# (x# `plusWord#` y#) (W8# x#) + (W8# y#)= W8# (narrow8Word# (x# `plusWord#` y#)) (W16# x#) + (W16# y#) = W16# (narrow16Word# (x# `plusWord#` y#)) (W32# x#) + (W32# y#) = W32# (narrow32Word# (x# `plusWord#` y#)) (W64# x#) + (W64# y#) = W64# (int64ToWord64# (word64ToInt64# x# `plusInt64#` word64ToInt64# y#)) The definitions are those used on a 32-bit architecture. So, when it is cheap the plusWord# function is used, but when it is relatively expensive then extra conversions are added. Wouldn't it make sense to avoid the conversions in all cases, regardless of whether they are free or not? If so, then I will keep the old changes in the next patch I submit. If not, then I will discard them. -Matt or [ricebowl, wearkilts, soysauce] on #haskell on Freenode ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
[Haskell] Invitation: AICCSA '06 -- 5th International Workshop on Software Stability: Methodologies, Applications and Tools
Greetings, You are invited to submit a position paper for this workshop. Enclosed please find the call for papers. Would you please send the following announcement to all possible e-mail lists that you currently have or have access to. I appreciate your publicizing this workshop to as many people in computing as possible. Thank you. Looking forward to hearing from you soon. Cheers, M. Fayad AICCA06-WS-cfp-Oct05.pdf Description: Binary data ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] postdoc at Oxford
Samson Abramsky, Luke Ong, Tom Melham and myself have just founded the Centre for Metacomputation at Oxford. We are looking for a 4-year senior postdoc to help coordinate the activities: http://web.comlab.ox.ac.uk/oucl/jobs/platform.html Topics of interest include types for quotation, termination analysis, model checking of higher-order programs, and games semantics for aspect-orientation. Please bring this to the attention of anyone who might be interested; naturally I'd be delighted to discuss the particulars on an informal basis, especially with members of this list. Many thanks, -Oege Oege de Moor, DPhil Professor of Computer Science Fellow of Magdalen College University of Oxford http://progtools.comlab.ox.ac.uk ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] PADL 2006 Call for Participation
CALL FOR PARTICIPATION CALL FOR PARTICIPATION [ - Apologies for multiple messages; - Deadline for early registration: Dec 15th] Eighth International Symposium on Practical Aspects of Declarative Languages PADL 06 Charleston Place Hotel Charleston, South Carolina January 9-10, 2006 http://www.cs.brown.edu/people/pvh/PADL06.html Co-located with ACM's Principles of Programming Languages, (POPL Dates: January 11-13, 2006) You are cordially invited to attend the 8th Symposium on Practical Aspects of Declarative Languages to be held in Charleston, SC. PADL has a very interesting program that includes invited speakers as well contributed papers. Contributed papers range over diverse topics: from bioinformatics to music modeling to semantic web. Invited Speakers: Phil Wadler, University of Edinburgh, speaking on Links: Linking Theory to Practice for the Web David Roundy, Cornell University Implementing and verifying the darcs patch formalism Erik Meijer, Microsoft Research (title TBA) Contributed papers: Using CHRs to generate functional test cases for the Java Card Virtual Machine Sandrine-Dominique GOURAUD and Arnaud GOTLIEB. Generic Cut Actions for External Prolog Predicates Tiago Soares, Ricardo Rocha and Michel Ferreira. Controlling search space materialization in a practical declarative debugger Ian MacLarty and Zoltan Somogyi. Automatic Verification of a Model Checker by Reflection Bow-Yaw Wang. Probabilistic-logical Modeling of Music Jon Sneyers, Joost Vennekens and Danny De Schreye. Using Dominators for Solving Constrained Path Problems Luis Quesada, Peter Van Roy, Yves Deville and Raphakl Collet. JQuery: A Generic Code Browser with a Declarative Configuration Language Kris De Volder. A Hybrid BDD and SAT Finite Domain Constraint Solver Peter Hawkins and Peter Stuckey. Adding constraint solving to Mercury Ralph Becket, Maria Garcia de la Banda, Kim Marriott, Zoltan Somogyi, Peter Stuckey and Mark Wallace. Modeling Genome Evolution with a DSEL for Probabilistic Programming Martin Erwig and Steve Kollmansberger. Tabling in Mercury: Design and Implementation Zoltan Somogyi and Konstantinos Sagonas. Translating Description Logic Queries to Prolog Zsolt Nagy, Gergely Lukacsy and Piter Szeredi. Efficient top-down set-sharing analysis using cliques Jorge Navas, Francisco Bueno and Manuel Hermenegildo. Querying Complex Graphs Yanhong A. Liu and Scott D. Stoller. Incremental Evaluation of Tabled Prolog: Beyond Pure Logic Programs Diptikalyan Saha and C. R. Ramakrishnan. ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] CFP: IEEE WoWMoM 2006 (Extended Deadline)
We apologize in advance if you receive multiple copies of this CFP. - CALL FOR PAPERS (Extended Submission Deadline) IEEE WOWMOM 2006 The 7th IEEE International Symposium on a World of Wireless, Mobile and Multimedia Networks June 26-29, 2006, Niagara-Falls/Buffalo, New York, USA (Sponsored by IEEE Computer Society, IEEE TCCC and Univ. of Texas at Arlington). http://ieee-wowmom.cse.buffalo.edu/ Extended Submission Deadline - November 26, 2005 11:59 PM PST-*** *** Paper Registration Deadline - November 19, 2005 11:59 PM PST--*** (While papers may be submitted till Nov. 26, all papers MUST be registered by the original deadline of November 19, 2005. Register papers via EDAS, providing the title, abstract and author list of the paper). - The emergence of broadband wireless access standards, such as 3G/UMTS, 802.16, 802.11a/g and UWB, offers exciting new possibilities for delivering rich multimedia content over wireless networks. The delivery and transport of rich multimedia in such wireless environments, including sensor and mesh networks, requires innovation and advances in better MAC and routing protocols, session establishment and signaling architectures, QoS provisioning and adaptive transmission techniques, autonomic network management capabilities and middleware frameworks, among others. *** Topics of Interest *** The IEEE WoWMoM 2006 technical program committee is soliciting papers addressing the research challenges and advances towards a world of wireless, mobile, and multimedia pervasive communications. Papers must present original and previously unpublished work, validated by experimentation, simulation, or analysis. Practical experiences and experimental efforts, including submissions from industry, are also welcome. Topics of interest include, but are not limited to, the following: - System prototypes and experiences - QoS for voice.video in wireless networks - Middleware support for QoS provision - Differentiated services for wireless multimedia - IP-based wireless multimedia services - Multimedia session signaling in wireless environments - Networking services for pervasive systems - Multicasting and broadcasting issues - Handoff and mobility management - Seamless internetworking - Energy-efficient protocols and power management - Network management and troubleshooting- IP-based mobile networks - Context-aware wireless multimedia application - Location mechanism and services - Wireless BAN, PAN, LAN, and MAN - Ad hoc and sensor networks - Wireless mesh networks - Vehicular wireless networks - Third and fourth generation systems - Wireless security and dependability - Content Management and Distribution - Pricing and billing - Modeling and Performance evaluation Two types of papers will be considered. Full Papers must present original, previously unpublished, complete work, validated by experimentation, simulation, or analysis. Position Papers must be visionary, innovative and forward-looking, and offer new perspectives on future research directions. Only a limited number of slots will be available for position papers that will be reviewed primarily for relevance and originality. ***Submission Dates and Guidelines Submission Deadline (extended):November 26, 2005 11:59 PM PST (Papers must be registered with abstract by November 19, 2005.) Acceptance Notification: February 21, 2006 Camera Ready Due: March 17, 2006. Submitted manuscripts should adhere to the IEEE double-column standard format, except the font size, which must be Times Roman 11pt (or greater). Authors should use only standard fonts, i.e., Times Roman, Courier, Symbol, and Helvetica, or equivalent. For full papers, the maximum length of the manuscript is 12 pages. For position papers, the maximum length of the manuscript is 6 pages. This limit includes figures, appendix, bibliography, etc. Papers that will be significantly exceed this limit will be automatically rejected. **Contact Details For any questions or clarifications, please contact either of the TPC Chairs below: Marwan Krunz, Univ. of Arizona, USA ([EMAIL PROTECTED]) Archan Misra, IBM Research, USA ([EMAIL PROTECTED]) For more information, please visit http://ieee-wowmom.cse.buffalo.edu/ ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Improvements to GHC
My 2 cents: John Lask (Thu, Nov 17, 2005 at 08:57:52AM +1030): 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) 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. The macro languages tend to become more and more complex over time. Eventually, you have two complex languages. First, a Haskell Macro Language, second Haskell. Why can we not use staging like in Omega, cf. [1], or Template Haskell? Maybe Haskell itself can generate the compiler and system specific source? [1] http://www.cs.pdx.edu/~sheard/Omega/index.html Regards, -- Stefan Karrmann ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] ANNOUNCE: hmp3, an ncurses mp3 player
hmp3 0.1 : an ncurses mp3 player hmp3 is a lightweight ncurses-based mp3 player written in Haskell. It uses mpg321 or mpg123 as its decoding backend. It is designed to be simple, fast and robust. A screenshot can be found at: http://www.cse.unsw.edu.au/~dons/hmp3.html The source: darcs get http://www.cse.unsw.edu.au/~dons/code/hmp3 Thanks go to Stefan Wehr and Sam Bronson, who helped a lot with beta testing. In particular Sam, who burnt many cpu cycles. Thanks! Cheers, Don ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
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] Lazy state monads
(Moved from the libraries list to the haskell list.) I wrote: createItems :: RandomGen g = State g [Item] createItems = liftM catMaybes $ runListT $ flip evalStateT initialState $ runMaybeT $ do item - liftRandom $ repeatM randomItem updateState item needMoreItems = guard return item where liftRandom = lift . lift . lift Udo Stenzel wrote: ...but this is probably broken anyway. After (repeatM randomItem) presumably the state (the RandomGen) is _|_, but the type of createItems would suggest it is still usable. No, it works. MaybeT tells ListT when to stop its iteration. After that, the RandomGen can be used again elsewhere. I wouldn't do that. Other than that it's a bit hard to see what you're trying to accomplish here. Lazy monads are an important programming paradigm in practice. Laziness helps to completely decouple the various ingredients of the algorithm from each other. This helps in debugging, and in dividing tasks among different development teams. The monadic approach helps makes refactoring easy (a common complaint against Haskell). For example, it would be trivial to add exception handling, or logging. The algorithm is clearly specified as an iteration of a series of steps, the way most people would naturally think of it. Yet the calculation is completely pure. So a compiler is not required to follow the steps literally. It can split the calculation across different threads, processors, http connections, etc., if it is smart enough. This is the way industrial software development should be done. It is clearly far better than imperative OO. Regards, Yitz ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: Records (was Re: [Haskell] Improvements to GHC)
On Tue, Nov 22, 2005 at 02:32:47PM +, Rob Ennals wrote:
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
Looks pretty nice.
To go through Dave's issues:
1. Field namespaces: solved by using type classes
But these classes are required to be manually specified, right? This avoids
the problem of proliferation of typeclasses if one had one class per field,
but does mean that coordination is necesary in order to avoid namespace
clashes.
As far as I can tell, this means that we'd have issues with
data StupidDouble = StupidDouble { value :: Double }
data StupidInt = StupidInt { value :: Int }
unless we use multiparameter typeclasses or something. This is a stupid
example (thus the type names), but I think there are real cases where you'd
like to create constructors like this.
2. Multi-constructor getters: solved by desugaring to functions
3. Safe getters for multi-constructor data types: ditto
I think either you misunderstood my meaning by safe, or I misunderstood
your paper. I meant that if I write
data FooBar = Foo { foo :: String } | Bar { bar :: String }
there shouldn't be accessors of type
foo :: FooBar - String
bar :: FooBar - String
which die when given bad input (e.g. calling (foo $ Bar bar)). I'd
rather in this case either not have these functions generated (and require
that I use pattern matching) or have them have type
foo :: FooBar - Maybe String
bar :: FooBar - Maybe String
I just don't like bottom. Perhaps it wouldn't be so bad if we got decent
error messages, but when you call (foo $ Bar bar) you get no hint as to
where the bug actually is.
7. Unordered records: yep (if I understand the problem correctly)
I don't think you understood correctly. What I'd like (and this is another
one of those David-specific issues--I've never heard anyone else complain
about this) is to be able to create a data type that has no order. If I
write
data FooBar = FooBar { foo, bar :: String }
I can construct this (either with Haskell 98 or with your proposal, as I
understand it) with either
fb = FooBar { foo = a, bar = b }
or with
fb = FooBar a b
I'd prefer to at least optionally be able to make the second syntax fail to
compile--which is what I mean by an unordered record. The same goes for
pattern matching. This feature is orthogonal to almost all the other
record issues, and really a compiler warning would probably be enough to
satisfy me, although I'd prefer to have this in the language.
The point (in case I've been unclear again) is that I'd like to be able to
later change the definition to
data FooBar = FooBar { foo, bar :: String }
without the possibility of breaking the code. This is a silly example, and
noone would actually make this change, simply because it would be too hard
to go through the code and verify that all the patterns have been swapped
(and didn't get swapped twice).
It's something that one could implement with code policy, but on the other
hand, you could in principle say the same thing about static typing.
--
David Roundy
http://www.darcs.net
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
Re: Records (was Re: [Haskell] Improvements to GHC)
David Roundy [EMAIL PROTECTED] writes:
7. Unordered records: yep (if I understand the problem correctly)
I don't think you understood correctly. What I'd like (and this is another
one of those David-specific issues--I've never heard anyone else complain
about this) is to be able to create a data type that has no order.
FWIW, there are certainly other people out there who think the same
way. In the Blobs diagram editor for instance, there are lots of
instances of exported datatypes with exported field accessors/updaters,
but the constructors are not exported. e.g.
module M (FooBar(), emptyFooBar, getFoo, getBar, setFoo, setBar) where
data FooBar = FooBar { foo :: String, bar :: Bool }
emptyFooBar = FooBar {}
getFoo = foo
getBar = bar
setFoo f fb = fb {foo=f}
setBar b fb = fb {bar=b}
This gives you three-quarters of your desire, i.e. unordered
construction is possible, positional construction is not, and
positional de-construction (pattern-matching) is also unavailable.
The only thing lacking is the ability to do unordered pattern-matching,
which is impossible here because the accessors are pure functions,
not true field names.
Just as for you, the intent of the design pattern here is total data
encapsulation - to be able to change the internals of the FooBar type
without any of the importing modules needing to change as a result.
Regards,
Malcolm
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
Re: Records (was Re: [Haskell] Improvements to GHC)
Am Mittwoch, 23. November 2005 14:22 schrieb David Roundy:
On Tue, Nov 22, 2005 at 02:32:47PM +, Rob Ennals wrote:
[...]
7. Unordered records: yep (if I understand the problem correctly)
I don't think you understood correctly. What I'd like (and this is another
one of those David-specific issues--I've never heard anyone else complain
about this) is to be able to create a data type that has no order. If I
write
data FooBar = FooBar { foo, bar :: String }
I can construct this (either with Haskell 98 or with your proposal, as I
understand it) with either
fb = FooBar { foo = a, bar = b }
or with
fb = FooBar a b
I'd prefer to at least optionally be able to make the second syntax fail to
compile--which is what I mean by an unordered record. The same goes for
pattern matching.
You can just omit the data constructors from the module's export list.
[...]
Best wishes,
Wolfgang
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Broken monad laws
Hello, I just noticed that the GHC/Hugs standard libraries have acquired a list monad transformer, which is broken, because it does not satisfy the associativity law when applied to non-commutative monads. I am not referring to some corner-case strictness problem, but rather a fairly well known result. The associativity law is important, because without it the 'do' notation can be very confusing. Bellow is an example, for people not familiar with the porblem. -Iavor import Control.Monad.List say:: String - ListT IO () say x = lift (putStr x) one_two, ex1,ex2 :: ListT IO () one_two = say 1 `mplus` say 2 ex1 = do one_two say 3 say 4 ex2 = do do one_two say 3 say 4 main= runListT ex1 putStrLn or runListT ex2 ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re[2]: Records (was Re: [Haskell] Improvements to GHC)
Hello David, Wednesday, November 23, 2005, 4:22:47 PM, you wrote: 7. Unordered records: yep (if I understand the problem correctly) DR I don't think you understood correctly. What I'd like (and this is another DR one of those David-specific issues--I've never heard anyone else complain DR about this) is to be able to create a data type that has no order. i think that this is very good thing, especially for library writers. it's just a Good Programming Style, not for bad guys like me ;) -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Broken monad laws
On 24/11/2005, at 9:45 AM, Iavor Diatchki wrote: Hello, I just noticed that the GHC/Hugs standard libraries have acquired a list monad transformer, which is broken, because it does not satisfy the associativity law when applied to non-commutative monads. I am not referring to some corner-case strictness problem, but rather a fairly well known result. The associativity law is important, because without it the 'do' notation can be very confusing. Bellow is an example, for people not familiar with the porblem. -Iavor This seems to have been discussed already: http://haskell.cs.yale.edu/hawiki/ListTDoneRight Sean ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] ANNOUNCE: Frag: a First Person Shooting game
Mun Hon Cheong wrote: Frag is a 3D First Person Shooting game. Thanks for releasing this! It built fine for me with ghc-6.4.1 on Fedora Core 4 x86_64, but when I run it I get: frag% ./a.out leveleg : : loaded textures/egyptians/sand_egy.tga loaded textures/egyptians/leaf.tga loaded textures/egyptians/gold_trim02.tga missing texture: models/mapobjects/Skull/skull.tga missing texture: textures/common/trigger.tga loaded textures/egyptians/oldstone_ramses.tga missing texture: textures/sfx/hellfog.tga *** glibc detected *** ./a.out: malloc(): memory corruption: 0x00807f90 *** === Backtrace: = /lib64/libc.so.6[0x3d03d6b79e] /lib64/libc.so.6(malloc+0x7b)[0x3d03d6cb3b] ./a.out[0x58aa95] === Memory map: : : Minimal gdb backtrace: Program received signal SIGABRT, Aborted. [Switching to Thread 46912496296672 (LWP 20343)] 0x003d03d2f280 in raise () from /lib64/libc.so.6 (gdb) bt #0 0x003d03d2f280 in raise () from /lib64/libc.so.6 #1 0x003d03d30750 in abort () from /lib64/libc.so.6 #2 0x003d03d64a7f in __libc_message () from /lib64/libc.so.6 #3 0x003d03d6b79e in _int_malloc () from /lib64/libc.so.6 #4 0x003d03d6cb3b in malloc () from /lib64/libc.so.6 #5 0x0058aa95 in ForeignziMarshalziAlloc_zdwccall2_info () #6 0x0028 in ?? () #7 0x in ?? () Jens ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
RE: [Haskell-cafe] GHCi always optimizes?
| Anyway, it's strange that you are experiencing crashes. IIRC, there | were problems if you mixed modules compiled with different levels of | optimisation in the same program, but I am not sure it still happens. If you can make a reproducible crash, please tar it up and send it to us. It shouldn't happen. Ever. Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: Re[2]: [Haskell-cafe] using of data types as kinds
Sorry should be fixed now (or shortly when the mirror does its stuff) Simon | -Original Message- | From: Bulat Ziganshin [mailto:[EMAIL PROTECTED] | Sent: 22 November 2005 19:28 | To: Simon Peyton-Jones | Cc: haskell-cafe@haskell.org | Subject: Re[2]: [Haskell-cafe] using of data types as kinds | | Hello Simon, | | Tuesday, November 22, 2005, 8:17:38 PM, you wrote: | | SPJ I have not written anything about what I plan to do in GHC, but | SPJ basically it amounts to allowing you to use a data type as a | SPJ kind. Busy doing GADTs and impredicativity at the moment though | | Simon, i can't download file | | http://research.microsoft.com/~simonpj/papers/boxy/boxy-pldi.ps.gz | | reffered at http://research.microsoft.com/~simonpj/papers/boxy/ | | | -- | Best regards, | Bulatmailto:[EMAIL PROTECTED] | | ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] questions on lazy pattern, StateT monad
Hi Haskell gurus, I'm very puzzled on some code I saw in GHC Monad.StateT (which is about state monad transformers) source and hope you can kindly give me some insight into this. newtype StateT s m a = S (s - m (a,s)) instance MonadPlus m = MonadPlus (StateT s m) where mzero = lift mzero mplus m1 m2 = do s - peek let m1' = runState s m1 m2' = runState s m2 ??? ~(a,s') - lift (mplus m1' m2') poke s' return a To illustrate my puzzle, say m is of List type and runState s m1 = m1' = [(a1, s1)] runState s m2 = m2' = [(a2, s2)] With the definition of lift (also in the StateT.hs file) as instance Trans (StateT s) where lift m= S (\s - do x - m return (x,s)) I got lift (mplus m1' m2') = lift ([(a1,s1), (a2,s2)]) = S (\s - [ ((a1,s1),s), ((a2,s2),s)]) I'm puzzled over this line: ~(a,s') - lift (mplus m1' m2') I think ~(a,s') shall be the value of the (StateT s m a) which is generated by lift (mplus m1' m2'). My questions are - why use lazy pattern? - how is ~(a,s') extracted from (StateT s m a)? This looks like magic to me. In the example I have (a1,s1) and (a2,s2) in the lifted monad, but it seems (a,s') only represents one at a time. It looks like how data is pulled out of a List monad. Your help is highly appreciated. Thanks, Fan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Frag: a First Person Shooting game
Did you encounter any difficulties in your development because of Haskell? Well, Haskell is different compared with other languages like C. I thought collision detection would be easier if i could use some local or global variables, but i managed to get around it. Was lazy evaluation ever a problem? I found some space leaks in the game, so i had to profile and enforce strictness in some areas. Why did you choose Yampa to program the game entities? Did this give you a particular advantage? Me and Sean Seefried thought it that would be interesting to use FRP in the game. I thought the design of the Space Invaders game in the paper The Yampa Arcade would work for this game and it did. We could use Yampa's parallel switchers to simulate game entities simultaneously without much trouble. I felt that Yampa offered good encapsulation. State information could be kept inside the signal function used to define the game entity and they were updated within that function. So with a well designed interface we could add game entities without major changes to the rest of the program. Isn't your frame rate a bit low? Yeah, it does run slower than Quake 3 which would run on my Pentium II 350 and voodoo3 , currently i doubt my game could do the same. I'm sure there are optimisations that could be used to improve the games performance. On my machine with an Athlon 1900+ and a Geforce 4mx the game runs at 60fps in leveleg. If you find that the framerate doesn't go above 60fps, its because its capped at 60. HopenGL I didn't find any missing features. Perhaps a listing of functions that have changed significantly from the original API could be made? ( I've forgotten which functions that I had trouble looking for though, but it wasn't because their gl prefixes were removed) regards, Mun On Tue, 22 Nov 2005, Joel Reymont wrote: Mun, I hope this ushers the era of Haskell games! I, for one, was certainly looking for something like this. Did you encounter any difficulties in your development because of Haskell? Was lazy evaluation ever a problem? Why did you choose Yampa to program the game entities? Did this give you a particular advantage? Isn't your frame rate a bit low? Thanks, Joel On Nov 22, 2005, at 6:05 AM, Mun Hon Cheong wrote: Frag is a 3D First Person Shooting game. Features: *Yampa, a domain-specific embedded language for the programming of hybrid systems that using the concepts of Functional Reactive Programming (FRP) was used to program the game entities. -- http://wagerlabs.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Records vs HList
David Menendez wrote:
Keean Schupke writes:
David Menendez wrote:
Chris Kuklewicz writes:
Would the record system describe at
http://lambda-the-ultimate.org/node/view/1119
also be convertable into System Fw, GHC's existing, strongly-typeed
intermediate language. ?
Probably. Daan's current implementation uses MLF, which I believe is
system F implemented for ML.
(We're talking about the system in Daan Leijen's paper, Extensible
Records With Scoped Labels. Good stuff.)
You can change the project and update operators in the HList library
to behave in exactly this way. At the moment they are constrained to
not allow multiple identical labels in records. If this kind of
access is considered useful, I can add it to the HList distribution.
This is true. I've implemented a small subset of HList that's able to
emulate Daan's three record operators using only fundeps and undecidable
instances.
*Main let r = foo .=. Bar .*. emptyRecord
*Main r
Record{foo=Bar}
*Main let r2 = foo .=. () .*. r
*Main r2
Record{foo=(),foo=Bar}
*Main r2 .!. foo
()
*Main (r2 .-. foo) .!. foo
Bar
(This is actually *more* powerful than the system described in Daan's
paper, because labels are first class.)
While this is a testament to the power of Haskell's extended type-class
system, I'm not sure that it can replace a dedicated record system. In
his paper, Daan describes how to implement the records such that field
lookups take O(log n) or even O(1) time. HList can't do better than
O(n).
Of course, in the absence of a powerful record system, HList is the way
to go. Rather than decide on a new record system sight unseen, let's
implement them using HList and see how they feel.E
Exactly! I like the idea of being able to construct and modify the
semantics of a record system
(and with the stuff in the OOHaskell paper you can play with Object
systems in the same way).
The important point with HLists is not that record syntax should not be
added to Haskell, but
that we can translate it to the existing type system with no conflicts.
(ie the type system does not
need to be extended there just needs to be some syntax, with an
optimised implementation)
HList can do O(log n) by the way, if the labels have order, you can
implement a binary search
tree of labels (Of course all the accessor functions would need to be
rewritten).
I wonder if some syntactic support for label creation would make things
nicer.
Actually one really useful change I would like would be to define type
class functions over all tuples,
that way you could write O(1) accessor functions on tuples using peano
number indexes.
class TupleIdx u i t | u i - t where
idx :: u - i - t
instance (a,b) HNil a where
(a,_) _ = a
instance (a,b) (HSucc HNil) b where
(_,b) _ = b
instance (a,b,c) HNil a where
(a,_,_) = a
instance (a,b,c) (HSucc HNil) b where
(_,b,_) = b
instance (a,b,c) (HSucc (HSucc HNil)) c where
(_,_,c) = c
etc...
However I haven't thought very hard about how to represent the complete
(infinite) set
of instances, but using this you can write products of tuples, and
create records with O(1)
access times from a pair of tuples.
Keean
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Function application like a Unix pipe
Scherrer, Chad wrote: Maybe my point wasn't clear. Of course this idea of comparing lazy evaluation to Unix pipes is very old (long before July 2004, I'm sure). The point I'm making is that there is an old idea that may be underused. It is, and only because (.) is defined all wrong! The unix pipe is actually function composition. Its argument (standard input) isn't explicitly mentioned, so the analogous Haskell code should do the same. However, function composition reads backwards, which makes code quite unreadable, especially when (.), (=) and `liftM` (which also has an all wrong fixity) are mixed. Im summary, I'd define infixl 0 # infixl 1 # infixl 2 \| (#) = flip ($) (#) = flip liftM (\|) = flip (.) -- though I'm using () The unix pipe becomes (filter (foo `isPrefixOf`) \| sort \| nub) or something, which is rather neat, and (#) is used to call member functions, as in some_map # add key value # add something or_other # delete old_trash which actually gives the result one expects when reading it top to bottom. In summary, (.) is tremendously useful, but it would be even better if it had the correct argument order. Unfortunately, this cannot be corrected any more. Udo. -- God is real, unless declared as an Integer. - Unknown Source signature.asc Description: Digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Function application like a Unix pipe
On Wed, Nov 23, 2005 at 11:17:25AM +0100, Udo Stenzel wrote: infixl 2 \| (\|) = flip (.) -- though I'm using () The unix pipe becomes (filter (foo `isPrefixOf`) \| sort \| nub) or something, which is rather neat, and (#) is used to call member functions, as in Why not use Control.Arrow. ? The instance for (-) is exactly what you want, and the syntax is quite nice: (filter (foo `isPrefixOf`) sort nub) BTW, using sort before nub is a bit pointless. In fact, using nub for longer lists is a bad idea. Best regards Tomasz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Function application like a Unix pipe
On Wed, 23 Nov 2005, Udo Stenzel wrote: Scherrer, Chad wrote: Maybe my point wasn't clear. Of course this idea of comparing lazy evaluation to Unix pipes is very old (long before July 2004, I'm sure). The point I'm making is that there is an old idea that may be underused. It is, and only because (.) is defined all wrong! Since (a . b) x a $ b x a (b x) are equivalent, do you also want to reverse function and argument in order to match argument order of . and $ ? That is x (b . a) x b $ a (x b) a ? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] questions on lazy pattern, StateT monad
Am Mittwoch, 23. November 2005 10:03 schrieb Fan Wu: [...] I'm puzzled over this line: ~(a,s') - lift (mplus m1' m2') Why is this line in Monad.State.StateT? Recently, we discussed that StateT does *not* use a lazy pattern here but that it should be changed to using one. So where did you see this lazy pattern? [...] Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Spurious program crashes
On 21 November 2005 16:43, Joel Reymont wrote: I'm being quite careful with resources these days. The outstanding issues are 1) Crashes on Mac OSX that are not reproduced on Linux, Windows, etc. 2) Some kind of a problem with Chan. getChanContents retrieves things smoothly, readChan only does it for the first few lines. Simon? Anyone? After subsequent dicsussion, do you still think something strange was going on here? The code does look strange: logger :: MVar () - IO () logger die = do empty - isEmptyChan parent unless empty $ do x - readChan parent putStrLn x alive - isEmptyMVar die when (alive || not empty) $ logger die so this basically loops until there are no messages in the channel, and then exits. Is that what you wanted, or did you want it to keep reading from the channel until told to die? STM is a better solution, as already suggested. Without STM, the best way to do this is to multiplex everything into a single channel (i.e. send the die message down the channel). 3) Different performance of the logger thread on Mac OSX and Windows. I'm having thousands of threads write their trace messages to a Chan. The logger On Windows I only see the first few lines of output when using isEmptyChan/readChan to retrieve values in a loop. On Mac OSX I do see smooth output. Context switch behaviour might be different between MacOS X and Windows. With the above code, it might be that the logger thread found an empty channel at sp,e point and exited. Does that make sense? On Windows I run out of memory because all the output sent to the chan builds up and is never processed. I can process it by replacing isEmptyChan/readChan with getChanContents but then my logger thread hangs forever (right semantics) and hangs everything else that waits for the logger thread to check an MVar and exit. yes, because the logger thread has exited. Cheers, SImon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Spurious program crashes
On Nov 23, 2005, at 1:18 PM, Simon Marlow wrote: After subsequent dicsussion, do you still think something strange was going on here? Yes, but in a different thread. The Postmortem one. so this basically loops until there are no messages in the channel, and then exits. Is that what you wanted, or did you want it to keep reading from the channel until told to die? I probably made a mistake someplace as I wanted to read until told to die but ONLY if the channel was empty. I replaced that code with Tomasz's elegant solution so now I read until Nothing is read from the channel. logger :: Handle - IO () logger h = do ss - getChanContents parent logger' ss where logger' [] = return () logger' (Nothing:_) = return () logger' ((Just x):xs) = do putStrLn x hPutStrLn h x logger' xs yield For whatever reason this generates empty lines with some sort of an unprintable character at the beginning. It prints these to the screen but not to the file. Of course it also prints what it's supposed to but the garbage shows both on Windows and the Mac. STM is a better solution, as already suggested. Without STM, the best way to do this is to multiplex everything into a single channel (i.e. send the die message down the channel). Right. Thanks, Joel -- http://wagerlabs.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Spurious program crashes
On 23 November 2005 13:29, Joel Reymont wrote: On Nov 23, 2005, at 1:18 PM, Simon Marlow wrote: After subsequent dicsussion, do you still think something strange was going on here? Yes, but in a different thread. The Postmortem one. so this basically loops until there are no messages in the channel, and then exits. Is that what you wanted, or did you want it to keep reading from the channel until told to die? I probably made a mistake someplace as I wanted to read until told to die but ONLY if the channel was empty. I replaced that code with Tomasz's elegant solution so now I read until Nothing is read from the channel. logger :: Handle - IO () logger h = do ss - getChanContents parent logger' ss where logger' [] = return () logger' (Nothing:_) = return () logger' ((Just x):xs) = do putStrLn x hPutStrLn h x logger' xs yield The yield is unnecessary. Also, getChanContents is considered by some (me included) to be poor style, because it relies on lazy I/O. This should work just as well: logger h = do m - readChan parent case m of Nothing - return () Just x - do hPutStrLn h x; logger h Cheers, Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Uses forkOS all CPUS on-board?
Hello haskellers, in past few days, a lot of stuff on concurrency went through the conference. I'm trying to use posted things and my own. They work, even in a context switching regime, but I can't exploit all the CPU's on my computer. Always is active just one thread and, thus, the computation is even slower than having a sequential version. Below, you can find my code - it computes nothing useful, it's been simplified to test parallelism, nothing else. Where's my error? Regards Dusan import Control.Concurrent -- computes nothing too much useful, but takes a long time ;-) sumAllSums [] = 0 sumAllSums l@(_:xs) = sumlist 0 l + sumAllSums xs where sumlist res [] = res sumlist sr (v:vs) = sumlist (sr+v) vs main = do putStrLn Starting... mv1 - newEmptyMVar mv2 - newEmptyMVar t1 - forkOS $ mkSum1 mv1 t2 - forkOS $ mkSum2 mv2 tt mv1 mv2 forkOS $ do killThread t1 killThread t2 putStrLn Done! where mkSum1 mv = do let res = sumAllSums [1..1] let ms1 = Sum1: ++ show res seq (length ms1) (putMVar mv ms1) mkSum2 mv = do let res = sumAllSums [1..10001] let ms2 = Sum2: ++ show res seq (length ms2) (putMVar mv ms2) tt mv1 mv2 = do yield mr1 - tryTakeMVar mv1 case mr1 of Just r1 - do yield putStrLn r1 yield r2 - takeMVar mv2 putStrLn r2 Nothing - do mr2 - tryTakeMVar mv2 case mr2 of Just r2 - do yield putStrLn r2 yield r1 - takeMVar mv1 putStrLn r1 Nothing - tt mv1 mv2 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Uses forkOS all CPUS on-board?
On 11/23/05, Dusan Kolar [EMAIL PROTECTED] wrote: Hello haskellers, in past few days, a lot of stuff on concurrency went through the conference. I'm trying to use posted things and my own. They work, even in a context switching regime, but I can't exploit all the CPU's on my computer. Always is active just one thread and, thus, the computation is even slower than having a sequential version. Below, you can find my code - it computes nothing useful, it's been simplified to test parallelism, nothing else. Where's my error? Did you compile it with -threaded? -- Sebastian Sylvan +46(0)736-818655 UIN: 44640862 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Function application like a Unix pipe
Henning Thielemann [EMAIL PROTECTED] writes: Since (a . b) x a $ b x a (b x) are equivalent, do you also want to reverse function and argument in order to match argument order of . and $ ? That is x (b . a) x b $ a (x b) a ? I'm sorry, I'm not sure I understand your question. Are you asking whether one should be allowed to write x f instead of f x? I don't think anyone is advocating this, but is can be convenient to have an infix operator for this purpose. Chad Scherrer Computational Mathematics Group Pacific Northwest National Laboratory Time flies like an arrow; fruit flies like a banana. -- Groucho Marx ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Function application like a Unix pipe
On Wed, 23 Nov 2005, Scherrer, Chad wrote:
Henning Thielemann [EMAIL PROTECTED] writes:
Since
(a . b) x
a $ b x
a (b x)
are equivalent, do you also want to reverse function and
argument in order to match argument order of . and $ ?
That is
x (b . a)
x b $ a
(x b) a
?
I'm sorry, I'm not sure I understand your question. Are you asking
whether one should be allowed to write x f instead of f x? I don't think
anyone is advocating this, but is can be convenient to have an infix
operator for this purpose.
I want to say, that the order of symbols for ($), (.) and function
application is consistent. This is a fine thing. I think that shall not be
distroyed by giving ($) and (.) reversed argument order.
It's of course a good question, why () and (=) have the opposite
order of (.). Compare function application
a b
where a is applied to b with the monadic case
b = a
where a is applied to the result of b. This makes changing a non-monadic
expression to a similar monadic expression more difficult.
Why is there no () and why is (=) not the default? The order of 'do
{a;b;c}' is compatible with that of (). So we have the fundamental
conflict, that usually function application is from right to left, but
interpreting imperative statements is from left to right.
I think that's a similar conflict like that of little endian and big
endian.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Function application like a Unix pipe
Henning Thielemann [EMAIL PROTECTED] writes: I want to say, that the order of symbols for ($), (.) and function application is consistent. This is a fine thing. I think that shall not be distroyed by giving ($) and (.) reversed argument order. I see. I like the argument order also, since it so nicely reflects mathematical notation. But I do think there's a place for (flip ($)) and (flip (.)). The problem is that the assignment of fixities is much more subtle and requires a consideration of what should be considered proper style. Chad Scherrer Computational Mathematics Group Pacific Northwest National Laboratory Time flies like an arrow; fruit flies like a banana. -- Groucho Marx ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Function application like a Unix pipe
Udo Stenzel [EMAIL PROTECTED] writes: The unix pipe is actually function composition. Its argument (standard input) isn't explicitly mentioned Then it seems Unix must overload the | operator. I typically use it to do things like grep . *.hs | wc So I think of the types as being grep . *.hs :: String wc :: String - Int -- ok, not really, but it shows the point better. So we'd have to have (|) :: a - (a - b) - b And (flip ($)) is the only thing that makes sense. Is it the case that a Unix pipe is analagous to (flip ($)) or (flip (.)) depending on the context? Chad Scherrer Computational Mathematics Group Pacific Northwest National Laboratory Time flies like an arrow; fruit flies like a banana. -- Groucho Marx ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Function application like a Unix pipe
On Wed, Nov 23, 2005 at 09:01:07AM -0800, Scherrer, Chad wrote: So I think of the types as being grep . *.hs :: String wc :: String - Int -- ok, not really, but it shows the point better. Every unix program has a standard input, even if it doesn't use it, so I would rather give this type to grep . *.hs: grep . *.hs :: a - String You can run something like this p | echo bla | grep . *.hs | wc even if it seems non-sensical. Best regards Tomasz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] questions on lazy pattern, StateT monad
HI Wolfgang, The code is from GHC source ghc-6.4.1/libraries/monads/Monad/StateT.hs, am I looking at the wrong place? I found the thread discussing Monad strictness, where is your StateT defined? But it is still not clear to me why lazy pattern is used here. Any ideas? Thanks, Fan On 11/23/05, Wolfgang Jeltsch [EMAIL PROTECTED] wrote: Am Mittwoch, 23. November 2005 10:03 schrieb Fan Wu: [...] I'm puzzled over this line: ~(a,s') - lift (mplus m1' m2') Why is this line in Monad.State.StateT? Recently, we discussed that StateT does *not* use a lazy pattern here but that it should be changed to using one. So where did you see this lazy pattern? [...] Best wishes, Wolfgang ___ 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 always optimizes?
On Wed, Nov 23, 2005 at 08:48:04AM -, Simon Peyton-Jones wrote: | Anyway, it's strange that you are experiencing crashes. IIRC, there | were problems if you mixed modules compiled with different levels of | optimisation in the same program, but I am not sure it still happens. If you can make a reproducible crash, please tar it up and send it to us. It shouldn't happen. Ever. I am not sure who you are replying to - me or Dusan. If you can't remember such a problem, then it is only my memory playing tricks ;-) Best regards Tomasz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Function application like a Unix pipe
On Wed, 2005-11-23 at 08:55 -0800, Scherrer, Chad wrote: . . . I see. I like the argument order also, since it so nicely reflects mathematical notation. But I do think there's a place for (flip ($)) and (flip (.)). The problem is that the assignment of fixities is much more subtle and requires a consideration of what should be considered proper style. Interesting note: in Richard Bird and Oege de Moor, _Algebra of Programming_, pp. 2-3, the authors write As a departure from tradition, we write f : A - B rather than f : B - A to indicate the source and target types associated with a function f. ... The reason for this choice has to do with functional composition, whose definition now takes the smooth form: if f : A - B and g : B - C, then f . g : A - C is defined by (f . g) x = f(g x). Further along the same paragraph they write: In the alternative, so-called diagrammatic forms, one writes x f for application and f ; g for composition, where x (f ; g) = (x f) g. I know I've read about the latter notation as one used by some algebraists, but I can't put my hands on a source right now. I guess it's not even entirely clear what constitutes mathematical notation. :-) -- Bill Wood ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] questions on lazy pattern, StateT monad
Am Mittwoch, 23. November 2005 19:02 schrieb Fan Wu: HI Wolfgang, The code is from GHC source ghc-6.4.1/libraries/monads/Monad/StateT.hs, am I looking at the wrong place? I found the thread discussing Monad strictness, where is your StateT defined? Hello Fan, the GHC source is just where I looked, except that my GHC version is 6.2.2. Obviously they corrected the implementation of (=) for StateT to use a lazy pattern between 6.2.2 and 6.4.1. But it is still not clear to me why lazy pattern is used here. Any ideas? Let's discuss this for State instead of StateT because this makes the discussion easier. A state transformer should ideally be implemented as a kind of function which gets one argument (the initial state) and returns *two* results (the output and the final state). Of course, a real function cannot return two results, so the obvious solution is to use a function which returns a pair, consisting of the output and the final state. If we would do so, it would work. But Haskell's pairs are not real pairs but lifted pairs. There are pairs like (x,y) which are an application of the data constructor (,) to x and y, and there is the special pair _|_ which denotes undefinedness. Note that _|_ is not the same as (_|_,_|_). Pattern matching of _|_ against the pattern (_,_) will not be successful while matching (_|_,_|_) against the same pattern will. The problem now is that when using Haskell pairs for implementing state transformers, it might not immediately be clear for a given state transformer if it returns an application of (,) (i.e., a true pair) or if it returns _|_. Pattern matching of a state transformer's result against a pattern of the form (x,y) may therefore result in unnecessary evaluation of certain expressions. Let's look at an example. We have two types S and T as well as some state transformer next :: State S T. Now we want to construct a state transformer which calls next infinitely many times and returns the outputs of the next invocations as an infinite list. We would write: everything :: State S [T] everything = do x - next xs - everything return (x : xs) The do expression can be rewritten as: next = (\x - everything = \xs - return (x : xs)) If we use an implementation of State *without lazy patterns*, it becomes something like this: \s - case next s of (x,s') - case everyting s' of (xs,s'') - ((x : xs),s'') Note that I used case expressions to realize strict patterns because pattern binding in let expressions is implicitely lazy. Now lets apply the function denoted by the last code fragment to some initial state and try to extract just the first element of the output. In order to do so we have to take the result of the function and match it against ((x : _),_). Especially, we have to reduce the pair, i.e., we have to make sure that it's really an application of (,) and not _|_. In order to do so we have to first reduce next s. After this, s' has to be taken and the result of everything s' has to be reduced. We cannot tell that the result of the whole function is really a (,) application until we have reduced everything s' and made sure that its result is not bottom. The problem is that for reducing everything s', we have to start the whole procedure again. So we end up in an infinite recursion and never get any result. However, if we use lazy patterns, we don't have to reduce next s at first. We also don't have to reduce everything s'. No matter whether these two expressions are _|_ or not, we know that the whole function always has a result of the form ((x : xs),s''). The first component of the pair can be immediately extracted from the pair and so can the first element of the list. Only if we start to evaluate this first element, next s has to be reduced. But only next s! I hope, this did clarify this problem a bit. If you still have questions, feel free to ask. Thanks, Fan Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Function application like a Unix pipe
On Wed, 2005-11-23 at 17:47 +0100, Henning Thielemann wrote:
. . .
Why is there no () and why is (=) not the default? The order of 'do
{a;b;c}' is compatible with that of (). So we have the fundamental
conflict, that usually function application is from right to left, but
interpreting imperative statements is from left to right.
I think that's a similar conflict like that of little endian and big
endian.
There may be something to your functional/imperative conflict.
I had occasion to develop a computational model of a theoretical
state-transition machine that the inventors wanted to be able to
program. My model used the standard trick of construing a parameterized
operation as a function f : Arg1 - ... - Argn - State - State. By
writing the (ML) code for the instructions in the curried form and using
a reversed composition operator, I was able to provide a programmatic
interface which could be laid out one instruction per line with the
composition operators way off to the right in the comment column, just
like assembler code! The inventors thought this was just wonderful
(there's no accounting for taste, I guess :-).
-- Bill Wood
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] questions on lazy pattern, StateT monad
On Wed, Nov 23, 2005 at 02:03:22AM -0700, Fan Wu wrote: instance MonadPlus m = MonadPlus (StateT s m) where mzero = lift mzero mplus m1 m2 = do s - peek let m1' = runState s m1 m2' = runState s m2 ??? ~(a,s') - lift (mplus m1' m2') poke s' return a Perhaps you were wondering, as I did when I read this, how ~(a,s') - lift (mplus m1' m2') poke s' return a differs from lift (mplus m1' m2') It helped me to rewrite mplus: mplus m1 m2 = S (\s - let m1' = runState s m1 m2' = runState s m2 in ~(a, s') - mplus m1' m2' return (a, s')) (If you reduce the first definition to this, you can verify that the lazy pattern matches in the two correspond.) So my question boils down to, can you ever distinguish S (\s - m = ~(a, s') - return (a, s')) from S (\s - m) using only exported operators? I don't think so, because a subsequent bind will do the lazy pattern match itself. Did I miss something, or is this use of ~ (and the subsequent poke, return) superfluous? Andrew ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] questions on lazy pattern, StateT monad
Hi Wolfgang, Thanks for your response and examples! It helps a lot. From your example I can see Lazy patterns are useful in contexts where infinite data structures are being defined recursively (quote section 4.4 of Gentle Introduction to Haskell). But does it apply to the mplus case? I mean the mplus in (mplus m1 m2) and the mplus in (mplus m1' m2') are different due to the difference of Monads (one is StateT s m, the other is just m). If I change the mplus inside lift to something else like: mplus m1 m2 = do s - peek let m1' = runState s m1 m2' = runState s m2 ~(a,s') - lift (other_func m1' m2') poke s' return a Is it still required that (a,s') be lazy? I just want to see how things works in an less obvious example like this one. Thanks, Fan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] questions on lazy pattern, StateT monad
Wolfgang Jeltsch writes: If we use an implementation of State *without lazy patterns*, it becomes something like this: \s - case next s of (x,s') - case everyting s' of (xs,s'') - ((x : xs),s'') Note that I used case expressions to realize strict patterns because pattern binding in let expressions is implicitely lazy. Now lets apply the function denoted by the last code fragment to some initial state and try to extract just the first element of the output. In order to do so we have to take the result of the function and match it against ((x : _),_). Especially, we have to reduce the pair, i.e., we have to make sure that it's really an application of (,) and not _|_. Would the lazy pattern match be equivalent to using fst and snd? \s - case next s of p1 - case everything (snd p1) of p2 - (fst p1 : fst p2, snd p2) -- David Menendez [EMAIL PROTECTED] | In this house, we obey the laws http://www.eyrie.org/~zednenem |of thermodynamics! ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Problem over Context Free Grammar Transitive Closure Algorithm
Folks this is a parser for Context Free Grammars, for some reason when
I go simplify the grammar trying to remove productions that substitute
variables like in the case:
S - A, A - B, B - a, it works perfectly and returns S -
a, the problem is when the root symbol is on the listthat must be
replaced as in:
S - aXa | bXb , X - a | b | S | £(empty)
instead of returning
S - aXa | bXb, X - a | b | £ | aXa | bXb
it ruturns X as
X - a | b | £ | S - this S is wrong! it should return X - a
| b | £ | aXa | bXb! Im not sure about where is the mistake. If you can
give me hints it would be grat. I will be checking the mail and also
hanging over #haskell at freenode ifyou want to contact me directly.
Thanks in advance for the help!
Victor
module CFG where
import Text.ParserCombinators.Parsec
{--import Data.Map--}
import Control.Monad (liftM)
import Data.Map (Map)
import qualified Data.Map as Map
data CFG t nt = CFG {terminals:: [Symb t nt],
nonterminals :: [Symb t nt],
root :: Symb t nt ,
{-productions :: Map (Symb t nt) [(ProdName,[Symb t nt])]-}
productions :: Map (Symb t nt) [[Symb t nt]]}
deriving (Eq,Ord,Show)
type Prod t nt = (ProdName,[Symb t nt])
type ProdName = String
data Symb t nt = Root
| T t
| NT nt
| Empty
deriving (Eq,Ord,Show)
{-Checks if the non-terminals are oki, the restriction that each NT must consist of a single symbol is already checked by the mapping structure here the only check needed id that the terminals and nonterminals sets are disjunct-}
nonterminal :: [Char] - CharParser st (Symb Char Char)
nonterminal termchars = liftM NT (noneOf ( |\n++termchars))
{-Now I try to check if a given symbol is a terminal-}
terminal :: [Char] - CharParser st (Symb Char Char)
terminal termchars = liftM T (oneOf termchars)
{-Checks if it is a $ production, Ive used $ for empty prodution because GHC doesnt supports unicode YET :-) -}
empty :: CharParser st (Symb Char Char)
empty = do {char '$'; return Empty}
{-rhs termchars = production termchars `sepBy` string | -}
{- parseTest (rhs sz) sN | z -}
{- rhs stands for right-hand-side -}
production termchars = (do empty; return [])
| many (terminal termchars | nonterminal termchars)
rhs termchars = production termchars `sepBy` string |
rule termchars = do x - nonterminal termchars
string -
ys - rhs termchars
return (x, ys)
{-parseTest grammar (unlines [termchars sz,start N,N - sN | z])-}
grammar = do string termchars ; termchars - many (noneOf |\n); newline
string start ; root - nonterminal termchars; newline
productionsList - rule termchars `sepEndBy` newline
return (CFG { terminals = map T termchars,
nonterminals = map fst productionsList,
root = root,
productions = Map.fromList productionsList
})
{-let cfg = run grammar (unlines [termchars sz,start N,N - sN | z])-}
{-*CFG let cfg = run grammar (unlines [termchars sz,start N,N - sN | z])
Loading package parsec-1.0 ... linking ... done.
*CFG cfg
CFG {terminals = [T 's',T 'z'], nonterminals = [NT 'N'], root = NT 'N', productions = {NT 'N':=[[T 's',NT 'N'],[T 'z']]}}
*CFG start
interactive:1:0: Not in scope: `start'
*CFG cfg
CFG {terminals = [T 's',T 'z'], nonterminals = [NT 'N'], root = NT 'N', productions = {NT 'N':=[[T 's',NT 'N'],[T 'z']]}}
*CFG root cfg
NT 'N'
-}
run p name xs = case parse p name xs of
Left err - error (show err)
Right res - res
{-Finds empty productions-}
{- *CFG let cfg = run grammar (unlines [termchars ab,start S,S - aXa | bXb | $,X - a | b | Y,Y - $])
*CFG empties cfg
[NT 'S',NT 'Y'] -}
empties cfg = Map.keys (Map.filter (any (==[])) (productions cfg))
{-cleanset cfg = Map.map ((filter (/=[Empty])) (productions cfg))-}
removeEmpties1 cfg = cfg { productions = prods'' }
where
prods= productions cfg
{-prods' = Map.map (filter (/=[])) prods-}
prods' = Map.mapWithKey (\k - if k == root cfg
then id
else filter (/=[]))
prods
prods'' = Map.map (concatMap f) prods'
f [] = [[]]
f (x:xs) | x `elem` empties cfg = map (x:) (f xs) ++ f xs
| otherwise= map (x:) (f xs)
removeEmpties :: (Ord t, Ord nt) = CFG t nt - CFG t nt
removeEmpties = doToDeath removeEmpties1
doToDeath f x = findFixedPoint (iterate f x)
where
findFixedPoint (x:y:z)
| x == y= x
| otherwise = findFixedPoint (y:z)
--remove useless
{-removeUseless (removeEmpties cfg)-}
useless cfg = Map.keys (Map.delete (root cfg)
(Map.filter null (productions cfg)))
removeUseless cfg = cfg { productions = Map.map (map $ concatMap f)
Re[2]: [Haskell-cafe] Uses forkOS all CPUS on-board?
Hello Sebastian, Wednesday, November 23, 2005, 6:46:54 PM, you wrote: They work, even in a context switching regime, but I can't exploit all the CPU's on my computer. Always is active just one thread SS Did you compile it with -threaded? this will not help. multi-processing support will be added in GHC 6.6, which must roll out due 6 months, as HCAR says -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Re[2]: Uses forkOS all CPUS on-board?
Bulat Ziganshin [EMAIL PROTECTED] writes: They work, even in a context switching regime, but I can't exploit all the CPU's on my computer. Always is active just one thread this will not help. multi-processing support will be added in GHC 6.6, which must roll out due 6 months, as HCAR says In the meantime, you can try it yourself by grabbing ghc 6.5 from cvs and reading http://www.haskell.org/~simonmar/papers/multiproc.pdf -- Shae Matijs Erisson - http://www.ScannedInAvian.com/ - Sockmonster once said: You could switch out the unicycles for badgers, and the game would be the same. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Records vs HList
Keean Schupke writes: HList can do O(log n) by the way, if the labels have order, you can implement a binary search tree of labels (Of course all the accessor functions would need to be rewritten). The idea of writing a type-level balanced binary search tree fills me with an uncertain mixture of excitement and dread. Particularly if you want to be able to compare records for equality. -- David Menendez [EMAIL PROTECTED] | In this house, we obey the laws http://www.eyrie.org/~zednenem |of thermodynamics! ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Function application like a Unix pipe
On 23/11/05, Scherrer, Chad [EMAIL PROTECTED] wrote: Bill Wood [EMAIL PROTECTED] writes: Interesting note: in Richard Bird and Oege de Moor, _Algebra of Programming_, pp. 2-3, the authors write As a departure from tradition, we write f : A - B rather than f : B - A to indicate the source and target types associated with a function f. ... The reason for this choice has to do with functional composition, whose definition now takes the smooth form: if f : A - B and g : B - C, then f . g : A - C is defined by (f . g) x = f(g x). Further along the same paragraph they write: In the alternative, so-called diagrammatic forms, one writes x f for application and f ; g for composition, where x (f ; g) = (x f) g. I know I've read about the latter notation as one used by some algebraists, but I can't put my hands on a source right now. I guess it's not even entirely clear what constitutes mathematical notation. :-) -- Bill Wood Good point. One of my undergrad algebra books (Contemporary Abstract Algebra, by Gallian) actually used notation like this. Function application was written (x f). Some people even write the function as an exponential. But (f x) is still far more common. Hmm, which edition? My copy (5th ed.) uses the ordinary notation: f(x). x f does perhaps make more sense, especially with the current categorical view of functions, but there would have to be a really hugely good reason to change notation, as almost all current work puts things the other way around. - Cale ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Function application like a Unix pipe
On Wed, 2005-11-23 at 21:21 -0500, Cale Gibbard wrote: . . . Hmm, which edition? My copy (5th ed.) uses the ordinary notation: f(x). x f does perhaps make more sense, especially with the current categorical view of functions, but there would have to be a really hugely good reason to change notation, as almost all current work puts things the other way around. My copy reads First published 1997 by Prentice Hall Europe (Address lines) Copyright Prentice Hall Europe 1997 ... ISBN 0-13-507245-X It's hardcover, white cover with red around the spine (standard for this series edited by C.A.R. Hoare), black banner with 100th title in red. The lack of any edition information leads me to surmise it's a first edition. Do you (or anyone) know if the diagrammatic notation has any currency among algebraists? -- Bill Wood ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Function application like a Unix pipe
Cale Gibbard: x f does perhaps make more sense, especially with the current categorical view of functions, but there would have to be a really hugely good reason to change notation, as almost all current work puts things the other way around. Almost all? Well, excluding the Smalltalkers, people using Forth, PostScript, etc. Jerzy Karczmarczuk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Function application like a Unix pipe
On 24/11/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Cale Gibbard: x f does perhaps make more sense, especially with the current categorical view of functions, but there would have to be a really hugely good reason to change notation, as almost all current work puts things the other way around. Almost all? Well, excluding the Smalltalkers, people using Forth, PostScript, etc. Perhaps I should have qualified that: I meant in pure mathematics. - Cale ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
