Re: ghc 6.4.1 on ia64
Hi Matt, That's very interesting. Thanks for the explanation. I also sent an email on this issue to the ghc-bugs mailing list: http://www.haskell.org//pipermail/glasgow-haskell-bugs/2006-March/006352.html so I hope you don't mind if I cc this email there too. On Sun, 2006-03-26 at 21:46 +1100, Matthew Chapman wrote: Hi Duncan, The relevant regular expression in the mangler looks like this: $p =~ s/^\t\.save ar\.pfs, r\d+\n\talloc r\d+ = ar\.pfs, 0, 3[12], \d+, 0\n//; I found that eventually. The part that's failing is where it expects one of the numbers, the number of local variables allocated for the function in the register stack window, to be 31 or 32. In this case it's as big as 77! Right, because the unfolding that ghc's done has given us this one function in the assembler output with one massive section of straight line code. The reason this regex is so specific is that it acts as a sanity check. The way GHC works on IA64 is that every STG function runs in the same register stack window (this allows tailcalls to work). This register stack window has 32 locals allocated, so a function must not use any more than this. So that explains why it didn't work when I merely relaxed the regexp in the mangler. Of these 32 locals, 16-28 are used by GHC for the STG machine's registers, 29-31 are used by gcc internally, and 0-15 are used by gcc for function locals. (There are some evil assumptions made about gcc internals here :)) But architecturally IA64 allows up to 96 locals, so as it stands, there is nothing stopping gcc from allocating a frame larger than 32, and using positions at 32 and above for function locals as well, if it's compiling a complex function with a lot of register pressure... which is obviously what is happening here. Indeed. If you look briefly at the source: http://abridgegame.org/cgi-bin/darcs.cgi/darcs/SHA1.lhs?c=annotate and then note that darcs is compiling this with the flags: -O -funfolding-use-threshold20 then one can believe that it compiles to one massive unrolled function with huge register pressure. There are a few possibilities: - Make ghc pass an option like -mfixed-range=loc32-loc79 to gcc when compiling, to stop gcc using locals from 32 upwards (N.B. in gcc the locals are only numbered up to 79 and not 95.. probably because it also reserves 8 inputs and 8 outputs). This would be the easiest and most promising option, but I can't seem to get it to work on a test example, so there might be some strangeness/bug in gcc that makes it ineffective. Yes, it doesn't quite work for me either (gcc (GCC) 3.3.2 20040119 (Gentoo Linux 3.3.2-r7, propolice-3.3-7)): Prologue junk?: .proc s64t_ret# s64t_ret: .save ar.pfs, r73 alloc r73 = ar.pfs, 8, 35, 8, 0 adds r16 = -24, r12 adds r17 = -16, r12 mov r18 = ar.unat .savesp ar.unat, 24 st8 [r16] = r18, 16 .save.g 0x1 .mem.offset 16, 0 st8.spill [r17] = r4, 16 .save.g 0x2 .mem.offset 8, 0 st8.spill [r16] = r5, 16 .save.g 0x4 .mem.offset 0, 0 st8.spill [r17] = r6 .save.g 0x8 .mem.offset -8, 0 st8.spill [r16] = r7 .body So we're down to allocating only 35 locals and spilling several more, but it's not within the 31-32 limit. It also has 8 in the second argument of alloc, where the mangler regexp expects 0. I'm going to try again with a more recent version of gcc. - Increase the size of the register stack frame used in STG code, and change the allocation of locals so that gcc can allocate more function locals. This involves a change to the runtime and impacts performance in all cases, not just in the rare case that it's actually needed, so I don't think it's a particularly good solution. Indeed. - Find some other workaround that might just work for now, like the one you've found, and brush it under the carpet :D Heh, yes. Perhaps the right solution if we pick this option is to modify the mangler to give us a better error message if the locals count is not 31-32. For example it could say that register pressure is too high and try re-compiling with less aggressive optimisations/inlining. Feel free to ask if you want clarification on any of this. Thanks very much. Duncan On Sat, Mar 25, 2006 at 07:15:04PM +, Duncan Coutts wrote: On Sat, 2006-03-25 at 17:17 +, Duncan Coutts wrote: I'm now running into a problem when building darcs (version 1.0.6). I think this must be a problem with the mangler: ghc -cpp -package QuickCheck -package util -package parsec -O -funbox-strict-fields -Wall -Werror -I. -DHAVE_CURSES -DHAVE_CURL -no-auto-all -funfolding-use-threshold20 -c SHA1.lhs Prologue junk?: .proc s64t_ret# s64t_ret: .save ar.pfs, r107 alloc r107 = ar.pfs, 0, 77, 8, 0 .body Turns out this doesn't
Re: How to access hs_free_fun_ptr from a Visual Studio DLL
Am Samstag, 25. März 2006 20:00 schrieb Brian Hulley: I've found a workaround to the problem below: instead of trying to use hs_free_fun_ptr, I instead pass a FunPtr to the Haskell function freeHaskellFunPtr into my DLL, and use this to free everything, finally using it to free itself (!) which I assume should be safe. [...] It has been quite some time since I've worked on GHC's Adjustor.c and Hugs' FFI, but IIRC it is in general *not* safe to do this. On some platforms code is being generated dynamically for these kind of callbacks, which has already been freed by the time the callback returns. This might appear to work, depending on your processor architecture and dynamic memory management behaviour, but it's better not to rely on this. Perhaps the FFI spec should be clearer here. I had a similar problem in for timer callbacks in my GLUT binding. They are one-shot and have to clean themselves up after the callback executes. The solution was to register the FunPtrs to be cleaned up only and do the real work in another scavenger callback, see http://darcs.haskell.org/packages/GLUT/Graphics/UI/GLUT/Callbacks/Registration.hs Cheers, S. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Message GHC/PrimopWrappers.hs:133:29: Not in scope: `GHC.Prim.quotInteger2Exp#' building GHC with additional primitive operation
On Thursday 23 March 2006 17:51, Simon Marlow wrote: I think you probably just haven't recompiled enough stuff after adding the primop. I can't tell immediately whether it's the compiler that is out of date, or an interface file in libraries/base. To be on the safe side, you could 'make clean' in ghc/compiler and libraries/base, then rebuild both. Cheers, Simon Hello, Thanks a lot, that removed some obstacles. Unfortunately, not all. Following successful make clean and make all in ghc/compiler and libraries/base, a make all in the top-level directory reported: ../../ghc/compiler/stage1/ghc-inplace -o stage2/ghc-6.4.1 -H16m -O -istage2/utils -istage2/basicTypes -istage2/types -istage2/hsSyn -istage2/prelude -istage2/rename -istage2/typecheck -istage2/deSugar -istage2/coreSyn -istage2/specialise -istage2/simplCore -istage2/stranal -istage2/stgSyn -istage2/simplStg -istage2/codeGen -istage2/main -istage2/profiling -istage2/parser -istage2/cprAnalysis -istage2/compMan -istage2/ndpFlatten -istage2/iface -istage2/cmm -istage2/nativeGen -istage2/ghci -Istage2 -DGHCI -package template-haskell -package readline -DUSE_READLINE -cpp -fglasgow-exts -fno-generics -Rghc-timing -I. -IcodeGen -InativeGen -Iparser -package unix -package Cabal -recomp -Rghc-timing -H16M '-#include hschooks.h'-no-link-chkstage2/basicTypes/BasicTypes.o stage2/basicTypes/DataCon.o stage2/basicTypes/Demand.o stage2/basicTypes/FieldLabel.o stage2/basicTypes/Id.o stage2/basicTypes/IdInfo.o stage2/basicTypes/Literal.o stage2/basicTypes/MkId.o stage2/basicTypes/Module.o stage2/basicTypes/Name.o stage2/basicTypes/NameEnv.o stage2/basicTypes/NameSet.o stage2/basicTypes/NewDemand.o stage2/basicTypes/OccName.o stage2/basicTypes/RdrName.o stage2/basicTypes/SrcLoc.o stage2/basicTypes/UniqSupply.o stage2/basicTypes/Unique.o stage2/basicTypes/Var.o stage2/basicTypes/VarEnv.o stage2/basicTypes/VarSet.o stage2/cmm/CLabel.o stage2/cmm/Cmm.o stage2/cmm/CmmLex.o stage2/cmm/CmmLint.o stage2/cmm/CmmParse.o stage2/cmm/CmmUtils.o stage2/cmm/MachOp.o stage2/cmm/PprC.o stage2/cmm/PprCmm.o stage2/codeGen/Bitmap.o stage2/codeGen/CgBindery.o stage2/codeGen/CgCallConv.o stage2/codeGen/CgCase.o stage2/codeGen/CgClosure.o stage2/codeGen/CgCon.o stage2/codeGen/CgExpr.o stage2/codeGen/CgForeignCall.o stage2/codeGen/CgHeapery.o stage2/codeGen/CgInfoTbls.o stage2/codeGen/CgLetNoEscape.o stage2/codeGen/CgMonad.o stage2/codeGen/CgParallel.o stage2/codeGen/CgPrimOp.o stage2/codeGen/CgProf.o stage2/codeGen/CgStackery.o stage2/codeGen/CgTailCall.o stage2/codeGen/CgTicky.o stage2/codeGen/CgUtils.o stage2/codeGen/ClosureInfo.o stage2/codeGen/CodeGen.o stage2/codeGen/SMRep.o stage2/compMan/CompManager.o stage2/coreSyn/CoreFVs.o stage2/coreSyn/CoreLint.o stage2/coreSyn/CorePrep.o stage2/coreSyn/CoreSubst.o stage2/coreSyn/CoreSyn.o stage2/coreSyn/CoreTidy.o stage2/coreSyn/CoreUnfold.o stage2/coreSyn/CoreUtils.o stage2/coreSyn/ExternalCore.o stage2/coreSyn/MkExternalCore.o stage2/coreSyn/PprCore.o stage2/coreSyn/PprExternalCore.o stage2/cprAnalysis/CprAnalyse.o stage2/deSugar/Check.o stage2/deSugar/Desugar.o stage2/deSugar/DsArrows.o stage2/deSugar/DsBinds.o stage2/deSugar/DsCCall.o stage2/deSugar/DsExpr.o stage2/deSugar/DsForeign.o stage2/deSugar/DsGRHSs.o stage2/deSugar/DsListComp.o stage2/deSugar/DsMeta.o stage2/deSugar/DsMonad.o stage2/deSugar/DsUtils.o stage2/deSugar/Match.o stage2/deSugar/MatchCon.o stage2/deSugar/MatchLit.o stage2/ghci/ByteCodeAsm.o stage2/ghci/ByteCodeFFI.o stage2/ghci/ByteCodeGen.o stage2/ghci/ByteCodeInstr.o stage2/ghci/ByteCodeItbls.o stage2/ghci/ByteCodeLink.o stage2/ghci/InteractiveUI.o stage2/ghci/Linker.o stage2/ghci/ObjLink.o stage2/hsSyn/Convert.o stage2/hsSyn/HsBinds.o stage2/hsSyn/HsDecls.o stage2/hsSyn/HsExpr.o stage2/hsSyn/HsImpExp.o stage2/hsSyn/HsLit.o stage2/hsSyn/HsPat.o stage2/hsSyn/HsSyn.o stage2/hsSyn/HsTypes.o stage2/hsSyn/HsUtils.o stage2/iface/BinIface.o stage2/iface/BuildTyCl.o stage2/iface/IfaceEnv.o stage2/iface/IfaceSyn.o stage2/iface/IfaceType.o stage2/iface/LoadIface.o stage2/iface/MkIface.o stage2/iface/TcIface.o stage2/main/CmdLineOpts.o stage2/main/CodeOutput.o stage2/main/Config.o stage2/main/Constants.o stage2/main/DriverFlags.o stage2/main/DriverMkDepend.o stage2/main/DriverPhases.o stage2/main/DriverPipeline.o stage2/main/DriverState.o stage2/main/DriverUtil.o stage2/main/ErrUtils.o stage2/main/Finder.o stage2/main/GetImports.o stage2/main/HscMain.o stage2/main/HscStats.o stage2/main/HscTypes.o stage2/main/Main.o stage2/main/PackageConfig.o stage2/main/Packages.o stage2/main/ParsePkgConf.o stage2/main/SysTools.o stage2/main/TidyPgm.o stage2/nativeGen/AsmCodeGen.o stage2/nativeGen/MachCodeGen.o stage2/nativeGen/MachInstrs.o stage2/nativeGen/MachRegs.o
Still problems building ghc 6.5 with ghc 6.4
Hello *, when building ghc 6.5 with ghc 6.4 and alex 2.0.1, the build fails as follows: make -C ghc/compiler stage=2 make[2]: Entering directory `/home/marte/fptools/ghc/compiler' ../../ghc/compiler/ghc-inplace -H16m -O -istage2/utils -istage2/basicTypes -istage2/types -istage2/hsSyn -istage2/prelude -istage2/rename -istage2/typecheck -istage2/deSugar -istage2/coreSyn -istage2/specialise -istage2/simplCore -istage2/stranal -istage2/stgSyn -istage2/simplStg -istage2/codeGen -istage2/main -istage2/profiling -istage2/parser -istage2/cprAnalysis -istage2/ndpFlatten -istage2/iface -istage2/cmm -istage2/nativeGen -istage2/ghci -Istage2 -DGHCI -package template-haskell -threaded -package readline -DUSE_READLINE -cpp -fglasgow-exts -fno-generics -Rghc-timing -I. -IcodeGen -InativeGen -Iparser -package unix -package Cabal -ignore-package lang -recomp -Rghc-timing -H16M '-#include hschooks.h' -ignore-package ghc -fgenerics -funbox-strict-fields -c parser/Lexer.hs -o stage2/parser/Lexer.o -ohi stage2/parser/Lexer.hi parser/Lexer.x:578:10: lexical error in string/character literal at character '\955' ghc: 51822676 bytes, 5 GCs, 98216/98216 avg/max bytes residency (1 samples), 16M in use, 0.00 INIT (0.00 elapsed), 0.62 MUT (0.84 elapsed), 0.11 GC (0.13 elapsed) :ghc make[2]: *** [stage2/parser/Lexer.o] Error 1 make[2]: Leaving directory `/home/marte/fptools/ghc/compiler' make[1]: *** [stage2] Error 2 make[1]: Leaving directory `/home/marte/fptools' make: *** [bootstrap2] Error 2 Is this problem caused by alex? Michael ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: How to access hs_free_fun_ptr from a Visual Studio DLL
Sven Panne wrote: Am Samstag, 25. März 2006 20:00 schrieb Brian Hulley: I've found a workaround to the problem below: instead of trying to use hs_free_fun_ptr, I instead pass a FunPtr to the Haskell function freeHaskellFunPtr into my DLL, and use this to free everything, finally using it to free itself (!) which I assume should be safe. [...] It has been quite some time since I've worked on GHC's Adjustor.c and Hugs' FFI, but IIRC it is in general *not* safe to do this. On some platforms code is being generated dynamically for these kind of callbacks, which has already been freed by the time the callback returns. This might appear to work, depending on your processor architecture and dynamic memory management behaviour, but it's better not to rely on this. Perhaps the FFI spec should be clearer here. I had a similar problem in for timer callbacks in my GLUT binding. They are one-shot and have to clean themselves up after the callback executes. The solution was to register the FunPtrs to be cleaned up only and do the real work in another scavenger callback, see http://darcs.haskell.org/packages/GLUT/Graphics/UI/GLUT/Callbacks/Registration.hs Thanks Sven for saving me from a horrible bug! :-) I've changed my code so that the DLL now only uses the FunPtr to freeHaskellFunPtr to release other callbacks, then I use freeHaskellFunPtr to free the FunPtr I passed in to the DLL from the Haskell side of the API to avoid a closure freeing itself ie: foreign import ccall duma_begin :: FunPtr (FunPtr a - IO ()) - IO Bool foreign import ccall duma_run :: IO () foreign import ccall duma_end :: IO () foreign import ccall wrapper mkFreeFunPtr :: (FunPtr a - IO ()) - IO (FunPtr (FunPtr a - IO ())) run :: IO a - IO () run f = bracket (mkFreeFunPtr freeHaskellFunPtr ) (\freeFunPtrFn - do duma_end freeHaskellFunPtr freeFunPtrFn ) (\freeFunPtrFn - do initialized - duma_begin freeFunPtrFn if (initialized) then f duma_run else return () ) Thanks, Brian. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: How to access hs_free_fun_ptr from a Visual Studio DLL
Hi Brian,
The problem is that hs_free_fun_ptr is defined in a static library
(the Haskell RTS) while you have declared it with
__declspec(dllimport). In this case the compiler is tring tp optimize
the call and it is using __imp__hs_free_fun_ptr instead of
hs_free_fun_ptr. You have to remove the dllimport pragma and to link
your program with the Haskell RTS library. Unfortunatelly the the
static library format is different for VC++ and GCC and I expect that
you may have problems if you try to statically link gcc code with VC++
code.
Cheers,
Krasimir
2006/3/25, Brian Hulley [EMAIL PROTECTED]:
Hi -
I have the following declaration and code in part of a DLL I'm writing:
extern C {
typedef void (*HsFunPtr)();
extern __declspec(dllimport) void hs_free_fun_ptr(HsFunPtr fp);
}
enum ECallback { ECallback_Render, ECallback_COUNT};
HsFunPtr callback[ECallback_COUNT];
void SetCallback(ECallback c, HsFunPtr fp){
if (callback[c]){
hs_free_fun_ptr(callback[c]);
}
callback[c] = fp;
}
However when I try to build the DLL, I get the following error from Visual
Studio:
Duma.obj : error LNK2019: unresolved external symbol
__imp__hs_free_fun_ptr
So the problem is that the VS is adding __imp__ onto the function name even
though I've specified it as extern C and is moreover just ignoring the
dllimport directive and complaining that it can't find the function.
I've also tried deleting the extern before the __declspec but this
doesn't make any difference. Also, I've tried putting hs_free_fun_ptr into
the IMPORTS section of the def file but this doesn't make any difference
either (I don't even think def files have an IMPORTS section so it's
probably just being ignored).
I've got a horrible feeling that VS will need a .lib file for ghc to allow
it to link against hs_free_fun_ptr but I don't have a clue how to generate
one...
Does anyone know how I can get everything to link?
Thanks, Brian.
___
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
[Haskell] Haskell as a disruptive technology?
I'm reading Clayton Christensen's classic book The Inventor's Dilemma. The gist, for those who haven't heard of it, is that successful large companies are tuned for sustaining technology improvements: small incremental improvements. But every so often a disruptive technology comes along that leaves the incumbents flat-footed. Christensen presents a detailed case study of the hard drive industry, where at every stage in the shrinkage of disk drives (14 mainframe, 8 minicomputer, 5.25 microcomputer, 3.5 for early laptops) the incumbent companies could not see the attraction of the smaller size drives to be sold in small markets for small margins. Instead they pursued premium customers in the high end of the computer industry. Something similar happened to steam shovels. Hydraulic diggers were initially small and low value, sold to farmers and builders to dig trenches. Steam shovels were sold to quarries and big construction projects, and that was where the money was. The steam shovel companies subsequently went bust and hydraulics now rules the world. The problem for the incumbents was never the technology: both disk drive makers and steam shovel manufacturers were capable of mastering and using the new technology. The problem was identifying and targetting markets. The term disruptive market might actually be more descriptive. For example, most camera manufacturers have made the switch to digital. The technology is radically different, but the market is just the same. On the other hand the smaller disk drives were essentially the same technology, but sold to a very different market with different value networks and propositions. Which leads me to consider Haskell. Haskell has all the signs of a disruptive technology: a different value proposition which stacks up badly against current industry norms, but has attributes that are likely to be valued by someone somewhere. The question is, who? Haskell's current value proposition, relative to standard programming languages (as I see it): + Faster development (4-10 times) + More reliable software (hard to quantify, but probably a similar improvement) + Good concurrency support with STM. + Good support for loosely structured data such as XML. - Slower programs (Shootout efforts notwithstanding) - Larger memory footprint - Little integration with GUI tools. No Visual Haskell or Borland Haskell equivalents. - Little integration with databases. - Little integration with mainstream software development. No analysis or design methods or notations. Haskell development appears to be primarily a matter of paying a bunch of very bright developers to cut code. - Concerns about support and maintenance. Those bright developers may not be around in the long term. So: we seem to be looking for a market that is currently under-served by incumbent languages because its not worth bothering with. It doesn't need complex databases (although a few ODBC queries are OK) or lots of GUI dialogs. The software is likely to be run on comparitively few computers (so that development cost is more important than hardware cost), or else do something that is not very computationally intensive. It is likely to have some degree of concurrency or soft real time (to use that STM capability), and have a short lifespan so that maintenance is not too much of a concern. Bear in mind that this market may well not use software at present, or it may be using computers in a way that is not thought of as programming. For example they may be using horribly complex Excel macros to do stuff. The current pain point may actually be reliability and verification rather than development cost. They probably think that hiring programmers to solve their problems is beyond their budget, and attempts to sell them a conventional development contract will fail to even get a hearing. I don't know what this market might be. Does anyone have any ideas? Paul. ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Haskell as a disruptive technology?
Hi, - Larger memory footprint You are talking about GHC, not Haskell. Take a look at nhc98, which has a small memory footprint. - Little integration with GUI tools. No Visual Haskell or Borland Haskell equivalents. http://www.haskell.org/visualhaskell/ - indeed there is :) - Little integration with databases. There are quite a few Haskell DB programs, I've never used any, but they do exist. Thanks Neil ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Haskell as a disruptive technology?
Neil Mitchell wrote: - Larger memory footprint You are talking about GHC, not Haskell. Take a look at nhc98, which has a small memory footprint. I don't want to get into a compiler flame war. The fact is that if you want to do huge datasets or very fast computation (the two tend to go together) then Haskell is the wrong language. This isn't an attack on Haskell, its a straightforward look at the strengths and weaknesses of the language. - Little integration with GUI tools. No Visual Haskell or Borland Haskell equivalents. http://www.haskell.org/visualhaskell/ - indeed there is :) I've never used Visual Haskell, but from the web page two things stand out: 1: Its version 0.0. This is not for production use. 2: Its just a programming environment. The point I was making was about integration with GUI tools. You can't (AFAIK) draw a dialog box and then tie each button to a Haskell function in the IO monad. - Little integration with databases. There are quite a few Haskell DB programs, I've never used any, but they do exist. I have used HSQL, and it does what it does perfectly competently. But it requires a bunch of boilerplate code in the IO monad for every query. There are higher level libraries that build nice type-safe stuff on top of this, but they don't seem to be production strength yet. Remember that this is not about what Haskell could or should be in the future, its about what Haskell is right now. If you start a Haskell development project then this is the reality that you face. Now, we could try to fix these deficiencies. That means playing catch-up with the entire infrastructure that has been erected around conventional languages. We will simply never succeed. Sure, we can probably do it with a 10th the manpower of the conventional languages, but they have 100 times our manpower to throw at the problem. Or we can play to our strengths by looking for markets where the negatives don't matter, or matter less than the positives. Haskell offers a value proposition that is very different to conventional languages. There is likely to be a market out there that is poorly served by conventional languages, but where Haskell will fit very nicely. All we have to do is find it and target it. Hmmm. I wonder about simulation and testing. Some time ago I asked here about doing discrete event simulation, and I have succeeded. (Unfortunately the resulting code is owned by my employer, so I can't share it). QuickCheck has shown a new approach to testing. Testing of stateful stuff using this approach would require a simulation of the thing to be tested. This might be a winning proposition. Paul. ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Haskell as a disruptive technology?
Bear in mind that this market may well not use software at present, or it may be using computers in a way that is not thought of as programming. For example they may be using horribly complex Excel macros to do stuff. The current pain point may actually be reliability and verification rather than development cost. They probably think that hiring programmers to solve their problems is beyond their budget, and attempts to sell them a conventional development contract will fail to even get a hearing. Paul, very interesting reflections! There are a lot of small businesses that could benefit from those type of software to automate their existing workflow. Like you have pointed out, some are already utilizing excel macros and off the shelf packages, hence the popularity of microsoft access. Although this trend minimizes a business's competitive advantage, as people are now forced to work in the framework of the software instead of their more efficient natural business operation model; interestingly enough, it has the benefit of making the task performer interchangable (e.g. Hiring someone who already knows how to use QuickBooks from a previous job). Recall the earlier remark about : support and maintenance. Those bright developers may not be around in the long term? By using _generic_ software, software maintainence is transformed into staff maintainence. From a manager's perspective, this is a much much more tractable domain. Programming job postings nowadays are laden with buzzwords, a trademark of genericity, instead of simply saying, one bright developer please. It is conceivable that this cycle is self fullfilling as bright developers are far and few. In addition, even with bright developers, their software creations, no matter how provably correct, are still sub-turing. A $10/hour intern can not only correct bad user inputs but also make you coffee. Hence, I feel this is just as much a social issue as a technological one. jake ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Haskell as a disruptive technology?
On 26/03/06, Paul Johnson [EMAIL PROTECTED] wrote: + Good support for loosely structured data such as XML. http://www.fh-wedel.de/~si/HXmlToolbox/ - Slower programs (Shootout efforts notwithstanding) I'd say it depends on which Haskell implementation you're using and which other language implementation you're comparing with. Let's say you're talking about GHC. Slower than hand-tuned C or assembly? Sure, for the most part, you could usually do better. Then again, if you really want performance, you might try writing a Haskell program to write your C or assembly for you, and search through possible implementations (see FFTW for an example of this being done with O'Caml). Slower than Java or VB or Python? Probably not. Of course, it all depends on what level of tuning you want to go to, and how well you understand code performance in Haskell. - Larger memory footprint Larger than what? I haven't noticed my Haskell programs using much more memory than reasonable. Sure, if you're processing really large blocks of data in a *non-sequential* manner, and using lists to manage it, it'll be slow, but that's just an example of using the wrong data structure. You can make the same mistake in C. - Little integration with GUI tools. No Visual Haskell or Borland Haskell equivalents. As has been pointed out, Visual Haskell actually does exist. It doesn't have much to do with building GUIs, but it does have nice integration with GHC to do things like automatically highlight type errors, and provide contextual completion. One nice combination you can make with GUI tools is to use Glade to design your GUI and load the resulting XML file using Gtk2Hs. The effect is not unlike that of using VB to design your GUI. While as of yet, there's no direct Glade support for writing the boilerplate GUI-loading code in Haskell, it's still not so much trouble (iirc, it's only 5-10 lines of code to get something on the screen, to the point where you can start adding event hooks). I highly recommend trying it, you can get fairly complex GUIs off the ground with relatively little code. - Little integration with databases. HDBC looks rather nice, and has drivers for Sqlite v3, PostgreSQL, and ODBC, and apparently is really easy to extend to other databases. (About 1-2 days work for a new driver, from what I heard) - Little integration with mainstream software development. No analysis or design methods or notations. Haskell development appears to be primarily a matter of paying a bunch of very bright developers to cut code. Hm? I'm not exactly sure what you're after here. No analysis methods or notations? What's wrong with ordinary mathematical proofs / denotational semantics? Haskell programs usually satisfy quite a few nice properties, so it's far easier to prove them correct than your average C++ program. As for design, well, we don't have many gimmicks like UML, but English (or whatever language you like to use) is decent. You can also draw things like module dependency graphs, which occasionally help a bit. I'm not really sure what a 'design notation' would be -- Haskell is a decent enough notation for program design on its own. You can usually construct almost any abstraction you'd like to use to design your program in, along with an interpretation so that the specification actually runs. As for design methods, that's somewhat language independent, isn't it? The usual top-down and bottom-up approaches both work reasonably well. Some people also use an approach which is somewhat like 'inside-out', building a path through the main functionality of the program at every level, usually with the intent of getting the thing running, and then rounding that out with features afterward. - Concerns about support and maintenance. Those bright developers may not be around in the long term. This is a valid concern, as there aren't too many Haskell programmers, compared to, say, C++ programmers, but things are getting better here. Many universities are teaching students to use Haskell in their courses. On the topic of what applications might be good, Haskell is a really great language in which to construct domain specific languages. Because it's so easy to do, I think one area where there's a lot of potential is for people to create interesting embedded DSLs in which to express business logic, where perhaps a data entry UI, and data storage mechanism would be automatically generated from the EDSL description. SPJ described a mechanism for using Haskell in order to express and reason about business contracts. Another area which I find interesting is in code generation for modern processors. Processors are getting really complicated, and it's getting quite tricky for humans to hand-tune code to take full advantage of them. Problem-specific code generators, or even higher-level programs which make use of those in order to build provably correct high-performance software would be much nicer to write in a language like Haskell.
Re: [Haskell] Haskell as a disruptive technology?
paul: Neil Mitchell wrote: - Larger memory footprint You are talking about GHC, not Haskell. Take a look at nhc98, which has a small memory footprint. I don't want to get into a compiler flame war. The fact is that if you want to do huge datasets or very fast computation (the two tend to go together) then Haskell is the wrong language. This isn't an attack on Haskell, its a straightforward look at the strengths and weaknesses of the language. It's not always clear that it won't work for very fast computation: http://shootout.alioth.debian.org/gp4/benchmark.php?test=partialsumslang=all In general I would say GHC/Haskell was very very fast, as long as you know what you're doing. -- Don ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: Alternatives to . for composition
On Sat, 25 Mar 2006, Jon Fairbairn [EMAIL PROTECTED] wrote: For emacs, just bind a key (C-. say) to (ucs-insert #X2218). ucs-insert comes from ucs-tables. You can also activate the TeX input method using C-u C-\ TeX RET (if leim is installed). Then you can insert many characters by typing their TeX names. The character ∘ can be inserted by typing \comp, for instance. Of course, this is not very useful unless you already know some TeX. -- /NAD ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
unicode/internalization issues
Hello haskell-prime, i've planned some time ago to open unicode/internalization wiki page, what reflects current state of the art in this area. here is the information i have, please add/correct me if i don't know something or wrong. 1. Char supports full Unicode range (about million of chars) instead of just 8-bit ASCII: implemented in GHC 6.0 and Hugs 2005 (i'm not sure about exact versions) 2. Character classification/convertion routines in Data.Char: all Unicode chars managed properly starting from GHC 6.4 and Hugs 2005. Author of this update, Dmitry Golubovsky, also provides it as additional lib for ghc 6.2.2, and i think it is possible to extend his work to work with any compiler supporting wide Chars. 3. Unicode support in I/O routines, i.e. ability to read/write UTF-8 encoded files and files what use other Unicode byte encodings: not implemented in any compiler, afaik, but there are 3rd-party libs: Streams library, New I/O library, and even CharIO module from jhc sources 4. Support for UTF-8 encoded source files: implemented in ghc 6.5 and jhc. afaik, ghc's support is more advanced because it uses abovementioned routines to classify Chars, so you can use any national characters in identifiers according to their case, and all other symbols in operators. because ghc 6.5 supports ONLY utf-8 encoded source files, these creates some problems when compiling files created for previous versions of ghc (or for other compilers) and using ASCII encoding with national (chr 127) chars in comments and especially string literals. GHC team asked their users for best solution of this problem if i don't mentioned here any issues regarding unicode/internalization, please add this -- Best regards, Bulat mailto:[EMAIL PROTECTED] ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: unicode/internalization issues
On Sun, Mar 26, 2006 at 03:22:38PM +0400, Bulat Ziganshin wrote: i've planned some time ago to open unicode/internalization wiki page, what reflects current state of the art in this area. here is the information i have, please add/correct me if i don't know something or wrong. You might want to look at: http://haskell.galois.com/cgi-bin/haskell-prime/trac.cgi/wiki/CharAsUnicode http://haskell.galois.com/cgi-bin/haskell-prime/trac.cgi/wiki/UnicodeInHaskellSource ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: supertyping
Has this list yet discussed John's supertyping proposal? http://repetae.net/john/recent/out/supertyping.html Jim ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
[Haskell-cafe] The simple programming language,
if somebody can help me wid this i wil b realy thankful Finally, we come to the program. The simple programming language, which includes loops, conditionals and sequential composition will be expressed a datatype in Haskell. data Prg = Skip | PrintS String | PrintE Exp | Declare Variable | Variable := Exp | Prg : Prg | IfThenElse Exp (Prg, Prg) | While Exp Prg The program Skip does nothing. The program PrintS ‘prints’ the given string to the output. Similarly, PrintE prints the value of the given expression to the output. Declare declares a variable, assigning its initial value to 0. The := operator performs variable assignment. The : operator is sequential composition, while IfThenElse and While are conditional and while-loops respectively. The condition in both cases resolves to true if the value of the expression is not zero. A factorial program can be programmed in this small language as follows: counter = counter result = result factorial n = Declare counter : Declare result : result := Val 1 : counter := Val n : While (Var counter) ( result := (Var result) :*: (Var counter) : counter := (Var counter) :-: (Val 1) ) : PrintS (Factorial of ++show n++ is:) : PrintE (Var result) (a) The simulate function takes a Store and a program, and returns an updated store and list of output strings: simulate :: Store - Prg - (Store, [String]) Using pattern matching, define simulate for Skip, PrintS and variable declarations. (b) Add the cases for PrintE and variable assignment. (c) Sequential composition can be defined by simulating the two instructions in sequence. Complete the following case: simulate store (p1 : p2) = let (store’, outs1) = simulate store p1 (store’’,outs2) = simulate store’ p2 in ... (d) Define simulate for conditionals. (e) We can ‘cheat’ by simulating while-loops in terms of conditionals and sequential compositi simulate store (While condition program) = simulate store (IfThenElse condition ( program : While condition program , Skip ) ) Using this definition, test your program with the factorial program. -- View this message in context: http://www.nabble.com/The-simple-programming-language%2C-t1344638.html#a3596582 Sent from the Haskell - Haskell-Cafe forum at Nabble.com. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] pls fast help me with this simple question
type Data = Integer type Variable = String type Store = [(Variable, Data)] Store = [(,0)] emptystore :: Store emptystore = [(,0)] getVal :: Store - Variable - Data thats my code i just have to continue and get the value of a variable from the store but i don't know how the task is : Define a function getVal, which takes a Store and a variable name, and returns its value. You may assume that the variable is defined in the Store. getVal :: Store - Variable - Data (c) Define a function setVar, which takes a Store, a variable name and a value, and returns an updated Store with the variable value updated. setVal :: Store - (Variable, Data) - Store -- View this message in context: http://www.nabble.com/pls-fast-help-me-with-this-simple-question-t1345292.html#a3598605 Sent from the Haskell - Haskell-Cafe forum at Nabble.com. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Equirecursive types?
According to Pierce's book, O'Caml has an optional equirecursive type extension that turns off the occurs check. Is there any particular reason Haskell doesn't have that available? Here's what got me thinking about it: http://lambda-the-ultimate.org/node/1360#comment-15656 Jim ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] pls fast help me with this simple question
On 3/26/06, iliali16 [EMAIL PROTECTED] wrote: type Data = Integer type Variable = String type Store = [(Variable, Data)] Store = [(,0)] emptystore :: Store emptystore = [(,0)] getVal :: Store - Variable - Data thats my code i just have to continue and get the value of a variable from the store but i don't know how the task is : Define a function getVal, which takes a Store and a variable name, and returns its value. You may assume that the variable is defined in the Store. getVal :: Store - Variable - Data (c) Define a function setVar, which takes a Store, a variable name and a value, and returns an updated Store with the variable value updated. setVal :: Store - (Variable, Data) - Store So you have a store which is a list of (name,value) pairs. You want to write a function which takes a name, a store, and returns the value. So: getVal [(x,4),(y,5)] x should return 4 You could either use functions in the standard library (check out lookup in Data.List and fromJust in Data.Maybe), or just do the recursion yourself: getVal [] _ = error Variable wasn't in the Store, not supposed to happen! getVal ((id,val):xs) var = ... Replace the ... with your own logic. If var is equal to id then you should return val, else you need to check the rest of the store (xs). /S -- Sebastian Sylvan +46(0)736-818655 UIN: 44640862 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] A Haskell Tutorial
Hi all, I've written a Haskell tutorial that walks the reader through the implementation of a Scheme interpreter: http://halogen.note.amherst.edu/~jdtang/scheme_in_48/tutorial/overview.html Instead of focusing on small examples at the Haskell REPL, it tries to show the reader how to construct a real program with Haskell. It introduces monads and IO early, and also includes error checking, state, file I/O, and all the other hard stuff that's frequently omitted from beginner tutorials. Am looking for feedback on two main axes: 1.) Experienced Haskell users: is this more-or-less idiomatic Haskell? Did I miss any library or language features that could make the programmer's job easier? It was my first substantial Haskell program, so I worry that I may have missed some common ways of doing things. 2.) Novices: is it clear and easy to understand? I had a tough time figuring out how to do anything practical in Haskell, because most tutorials omit IO, gloss over monads, and don't pay any attention to state or error-checking. Does this rectify those shortcomings? Comments/critiques are appreciated. Regards, Jonathan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] The simple programming language,
Well, I'm sure that lots of people here would be willing to help if you'd be more specific about what you're having trouble with. Just posting an assignment problem tends not to generate much discussion until after the assignment deadline. What have you already tried? What part are you stuck on? Also, if you're interested in more immediate responses, try #haskell on irc.freenode.net. For help with asking good questions, check out http://www.haskell.org/hawiki/HomeworkHelp - Cale P.S.: (Just to let everyone know, this is an assignment problem from the CSA 1080 Declarative Programming course at the University of Malta. The relevant URL is here: http://www.cs.um.edu.mt/~gpac1/ I've gotten a few questions about it lately, and there was a post to the libraries list about another problem on it.) On 26/03/06, pinturicchio [EMAIL PROTECTED] wrote: if somebody can help me wid this i wil b realy thankful Finally, we come to the program. The simple programming language, which includes loops, conditionals and sequential composition will be expressed a datatype in Haskell. data Prg = Skip | PrintS String | PrintE Exp | Declare Variable | Variable := Exp | Prg : Prg | IfThenElse Exp (Prg, Prg) | While Exp Prg The program Skip does nothing. The program PrintS 'prints' the given string to the output. Similarly, PrintE prints the value of the given expression to the output. Declare declares a variable, assigning its initial value to 0. The := operator performs variable assignment. The : operator is sequential composition, while IfThenElse and While are conditional and while-loops respectively. The condition in both cases resolves to true if the value of the expression is not zero. A factorial program can be programmed in this small language as follows: counter = counter result = result factorial n = Declare counter : Declare result : result := Val 1 : counter := Val n : While (Var counter) ( result := (Var result) :*: (Var counter) : counter := (Var counter) :-: (Val 1) ) : PrintS (Factorial of ++show n++ is:) : PrintE (Var result) (a) The simulate function takes a Store and a program, and returns an updated store and list of output strings: simulate :: Store - Prg - (Store, [String]) Using pattern matching, define simulate for Skip, PrintS and variable declarations. (b) Add the cases for PrintE and variable assignment. (c) Sequential composition can be defined by simulating the two instructions in sequence. Complete the following case: simulate store (p1 : p2) = let (store', outs1) = simulate store p1 (store'',outs2) = simulate store' p2 in ... (d) Define simulate for conditionals. (e) We can 'cheat' by simulating while-loops in terms of conditionals and sequential compositi simulate store (While condition program) = simulate store (IfThenElse condition ( program : While condition program , Skip ) ) Using this definition, test your program with the factorial program. -- View this message in context: http://www.nabble.com/The-simple-programming-language%2C-t1344638.html#a3596582 Sent from the Haskell - Haskell-Cafe forum at Nabble.com. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Positive integers
On Friday 24 March 2006 14:37, you wrote: An additive torsor is? Surprisingly, there is a page on MathWorld about Torsors but it is empty. Google turned up the following page with a good explanation. http://math.ucr.edu/home/baez/torsors.html Nice clear explanation that. Thanks for the link Jared. I'd maintain that the difference between two lengths is an entirely different quantity from the length of a list. (Maybe this is a good example of what the term torsor captures.) Thanks to Aaron for expanding our vocabulary. Yep. Now I agree with Aaron. And now I won't get offended if someone calls me a closet torsor user! :) Jared. -- http://www.updike.org/~jared/ reverse )-: ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Positive integers
On Friday 24 March 2006 16:16, Ben Rudiak-Gould wrote: Daniel McAllansmith wrote: I can see the domain bounds check would be a problem in theory, but in practice doesn't the type enforce that? Keeping Word positive costs nothing because it just overflows. Wouldn't it be much the same? If you're planning wraparound semantics then you're better off with Int indexes. I wasn't really _planning_ wrap around semantics. More just making the point that saying the cost of using Word is greater than the cost of using Int, due to the bounds checking required, seems unfair. I see your point about quick detection of bad indices, though I'd still rather have the type document the fact that only positive integers are expected. Daniel ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Positive integers
On Friday 24 March 2006 23:29, Malcolm Wallace wrote:
Daniel McAllansmith [EMAIL PROTECTED] wrote:
Unless I've missed it, there is no typeclass for positive integers in
GHC. Is there any particular reason it doesn't exist?
Also, it seems Word would be a far better type in the likes of (!!),
length, etc. Is it just tradition that resulted in the use of Int?
There is a good argument that what you really want here is the lazy
infinite natural numbers. Think Peano:
data Natural = Zero | Succ Natural
The clear correspondance between lazy lists and the size/index of a lazy
list makes this type fairly compelling. It can be jolly useful,
particularly with infinite streams, to be able to compute
(length xs n)
without forcing the evaluation of the list to more than n places.
Of course, if the naturals were actually represented in Peano (unary)
form, that would be somewhat inefficient, but there are various
strategies that can be used to make the representation smaller whilst
retaining their nice properties.
I was thinking about several things in this thread, torsors, overflow
semantics, bounds checking...
I wonder if there would be any merit in being able to define constrained
subsets of integers and the semantics when/if they overflow.
For example, take UNIX nice levels -20 to 19. You could have
data ConstrainedInteger = CI {distToMax :: Natural, distToMin :: Natural}
this would ensure only the 40 integers can be represented.
Then you could have _something_ that defined what happened on overflow,
whether it wraps, reflects, errors, truncates or whatever.
When it comes to compile, or source preprocessing, time these numbers could be
realigned to a primitive Int or Word representation of suitable size and have
the appropriate overflow code written in. And, in the case of error or wrap
overflow semantics on a set of the right size, the overflow checks could be
disabled, like other assertions, at runtime.
Daniel
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Positive integers
G'day all. Quoting Jared Updike [EMAIL PROTECTED]: Surprisingly, there is a page on MathWorld about Torsors but it is empty. Google turned up the following page with a good explanation. http://math.ucr.edu/home/baez/torsors.html Ah, right. So torsor is just a short name for regular group action,which in turn is a short name for free transitive group action. We discussed these previously in the context of other kinds of difference types: http://www.haskell.org/pipermail/libraries/2005-May/003899.html Cheers, Andrew Bromage ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Building Monads from Monads
On Friday 24 March 2006 16:42, Cale Gibbard wrote: Excellent help thanks, Cale. A lot of my misunderstandings stemmed from not finding any 'instance MonadState ReaderT' when reading the code in Reader.hs, not realising that there was an instance defined in State.hs, and yet being able to use get on what I thought would just be a Reader. I think I will now have an enduring friendship with GHCi's ':info'. Q. 4) Is it possible to give a type to the lifted function so that the monad of the correct class _and_ type is used? E.g. dig into a String Reader rather than an Int Reader. I'm not completely sure what you're after here -- basically, you just lift things into whichever monad you're using. If you want to be polymorphic, but insist on a particular instance of MonadReader, that's easy enough, just put a constraint like (MonadReader String m) or something similar on your type. Not really a valid question now that I've cleared up my misconceptions of lifting, but... I meant something along the lines of i - ((lift get) :: Int) --dig into the nearest Int state s - ((lift get) :: String) --dig into the nearest String state Q. 6) Is it safe to always use liftIO, even in plain IO monad? It's safe, sure, though a little awkward. It's easy enough to lift whole IO computations later on anyway. The only benefit would be if you wanted to later intersperse actions into the code which came from a transformed version. Yeah, I meant being able to go back and intersperse the use of state, or whatever, in a monadic expression that had, until then, only done IO. [snip various good suggestions and improved code] Good advice, thanks. Thanks Daniel ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Equirecursive types?
On Sun, Mar 26, 2006 at 01:22:17PM -0500, Jim Apple wrote: According to Pierce's book, O'Caml has an optional equirecursive type extension that turns off the occurs check. Is there any particular reason Haskell doesn't have that available? It's certainly feasible, though turning off the occurs check doesn't do it: you need to use the unification algorithm for regular trees (see e.g. section 6.7 of the revised Dragon Book). You also need to decide what to do about type T = T I think the arguments against it are: * many common errors will lead to perfectly legal types. * it adds convenience, but not expressive power. * it only works for regular types, where the arguments of uses of the type constructor on the rhs are the same as (or a permutation of) the arguments on the lhs, so this is out: type T a = Either a (T (a,a)) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] error vs. MonadError vs. fail
Is there a consensus on how anticipatable failure situations should be handled? There was a thread, haskell programming guidelines, from 2006-02-25 where John Meacham and Cale Gibbard had a bit of back-and-forth about using Monad.fail or a purpose specific MonadFail class. I believe a consensus was reached that using error should only be for 'impossible' situations and signaling buggy code. [Apologies if I've put words in anyones mouth.] Using fail certainly seems quick and easy, but I find it a bit distasteful for a few different reasons: users of a library can't discriminate between a failure indicating they've supplied bad input and a failure indicating that teh library writer has got a bad pattern match somewhere, it doesn't seem to force the potential for failure to be explicit in the api of a library, it doesn't seem to allow distinct, and rich, failure constructs at system layer boundaries, or the containment of them. Maybe the last two aren't a problem when programming in Haskell, but by itself the first seems pretty nasty. Apparently the advantage of fail is that user of the library can choose to receive failures as eg Maybes, Eithers, [], or whatever they like. But surely a MonadFail could allow the best of both worlds, letting the library throw as detailed an error construct as it can, and letting the library user choose MonadFail instance such that error constructs are turned into Maybes, Eithers, a new construct appropriate for a higher system layer, etc? MonadError is not up to this task as far as I can tell. Has anybody whipped up an alternative, or can explain why it can't be done? Cheers Daniel ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Positive integers
On 2006-03-26, Daniel McAllansmith [EMAIL PROTECTED] wrote:
I was thinking about several things in this thread, torsors, overflow
semantics, bounds checking...
I wonder if there would be any merit in being able to define constrained
subsets of integers and the semantics when/if they overflow.
For example, take UNIX nice levels -20 to 19. You could have
data ConstrainedInteger = CI {distToMax :: Natural, distToMin :: Natural}
this would ensure only the 40 integers can be represented.
Then you could have _something_ that defined what happened on overflow,
whether it wraps, reflects, errors, truncates or whatever.
When it comes to compile, or source preprocessing, time these numbers
could be realigned to a primitive Int or Word representation of
suitable size and have the appropriate overflow code written in. And,
in the case of error or wrap overflow semantics on a set of the right
size, the overflow checks could be disabled, like other assertions, at
runtime.
Now that is an interesting idea.
--
Aaron Denney
--
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: (!!) operator usage
Tom Davies tomdavies at exemail.com.au writes: [snip] Apologies for the complete misinformation! I don't know what I was thinking! Tom ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
