- Haskell - Haskell.org

Implicit Parameter Bug?
by Ashley Yakeley 04 Feb '02

04 Feb '02

What's wrong with this? f :: ((?param :: a) => b) -> a -> b f foo a = foo with ?param=a g :: (?param :: a) => a g = ?param h :: a -> a h = f g 'ghci -fglasgow-exts' (5.02) gives this error: Could not deduce (?param :: a) from the context () Probable fix: Add (?param :: a) to the type signature(s) for h arising from use of `g' at Implicit.hs:10 In the first argument of `f', namely `g' In the definition of `h': f g 'hugs -98' (Feb 2000) gets as far as this: Reading file "/usr/share/hugs98/lib/Prelude.hs": Reading file "Implicit.hs": Type checking ...and spins there. There's a workaround for ghci, but it doesn't help hugs: h :: a -> a h = f (g with ?param = ?param) This is very odd, as surely the type of (g with ?param = ?param) is the same as the type of g? -- Ashley Yakeley, Seattle WA

1 0

Re: Compiler problem or dumb error?
by mgross＠dorsai.org 04 Feb '02

04 Feb '02

On Sun, 3 Feb 2002, Jay Cox wrote: > If checkWid is never invoked, then possibly it is never forced to begin > with, which I think means the bug is elsewhere in your code (or > elsewhere). > Which turns out to be the case, although I haven't pinned it down completely--please see my follow-up post on the same subject. > > btw, your original map function could possibly be better written as a > zipWith as in.. > > > zipWith (\w s -> checkWid ShowList w s) widNodes [0..] > > > zipWith is mentioned in the Prelude and is a fairly widely used > higher-order function. > Neater than what I have, but not quite as obvious as documentation to me (since I have not frequently used zipWith). I will probably replace my code with your suggested code when I remove the scaffolding (read crutches) from my half-built program. Thanks for the hint. Best, Murray Gross mgross(a)dorsai.org

1 0

Re: Compiler problem or dumb mistake?
by Jay Cox 03 Feb '02

03 Feb '02

> --__--__-- > > Message: 4 > Date: Sat, 2 Feb 2002 15:58:39 -0500 (EST) > From: <mgross(a)dorsai.org> > To: haskell(a)haskell.org > Subject: Compiler problem or dumb mistake? > > > Here's the problematic snippet, using GHC 5.00.2: > > mapWidList :: [(Int,Int,Bool)] -> [WidNode] -> Int-> [WidNode] > mapWidList showList > widNodes seq > --map (\x -> (checkWid showList x (widNodes!!x))) > -- [0 .. ((length widNodes) -1)] > | (length widNodes ) < seq + 1 = [] > | otherwise = (checkWid showList > seq (widNodes!!seq) ): > (mapWidList showList widNodes > (seq+1)) > > > The commented lines are what I would really like, but trace indicated > that the anonymous function is never invoked, so I wrote out explictly > recursive code. However, while trace indicates that the both alternatives > are appropriately repeatedly tested, checkWid is never invoked. I have > modified checkWid to assure that laziness is not the problem (I suffed in > code that prevents prediction of the result returned by checkWid), so > something else is going on here. Anyone care to take a shot at this one? > > Thanks in advance. > > Murray Gross > mgross(a)dorsai.org > If checkWid is never invoked, then possibly it is never forced to begin with, which I think means the bug is elsewhere in your code (or elsewhere). For instance i trace the execution of the construction of [(x+2),(x+1),x] etc (assuming absolutly no optimizations take place). taking the length of that list will not force the individual thunks representing the values of the elements of that list, even though (+) is strict. (In (x:y) the list constructor (:) is lazy on both arguments x and y.) When you mention you you stuffed code to ensure the result returned by checkWid isn't predictable you did make sure to use the pragma that says NOT to inline checkWid? btw, your original map function could possibly be better written as a zipWith as in.. zipWith (\w s -> checkWid ShowList w s) widNodes [0..] zipWith is mentioned in the Prelude and is a fairly widely used higher-order function. Jay Cox

1 0

functional dependencies
by Iavor S. Diatchki 03 Feb '02

03 Feb '02

hello, there seems to be a difference between the way superclasses are handled in GHC and Hugs, and it would be nice if one of the choices was selected (i am not sure what other implementations do). here is what i mean: class C a b | a -> b class C a b => D a vs. class C a b | a -> b class C a b => D a b Hugs accepts both of those, while GHC insists on the second. the first example is a little shorter and one might argue that if we know "a" we also know "b", because of the functional depency, so it is not really a parameter. on the other hand, i would expect writing "b" in the type signatures of any of the methods to refer to the particular "b" determined by the "a", rather than it becomeing universally quantified, and perhaps this is more explicit in the second form. bye iavor

1 0

Icsm 2002 Call for Papers: deadlines changed
by icsmif＠serg.ing.unisannio.it 03 Feb '02

03 Feb '02

Dear Colleague I would like to remind you the that IEEE International Conference on Software Maintenance, 2002, and associated workshops: SCAM, WSE, and WESS will be held next October 2002 in Montreal, Canada. Outstanding Keynotes such as Jon Pincus, Microsoft, Industrial and experience papers, reseach papers, tutorials, tool expositions, dissertation forum, workshops, panels, and other exciting activities have been planned. We hope that this "Call For Papers" will be useful for your work. Please forward the following to anybody who you think may be interested. Our apologies if you received multiple copy of this. Please notice that the conference deadlines changed: Research Papers deadline: March 18, 2002 mailto:icsm2002.full@unisannio.it Fast Track Papers deadline: May 1, 2002 mailto:icsm2002.short@unisannio.it Dissertation Forum deadline: May 1, 2002 mailto:icsm2002.thesis@unisannio.it Industrial Applications deadline: May 1, 2002 mailto:icsm2002.industry@unisannio.it Tutorials deadline: March 18, 2002 mailto:icsm2002.tutorial@unisannio.it If you would like to be removed from our list please send an email to icsm2002.info(a)unisannio.it with REMOVE in the subject. ICSM2002 Giuliano Antoniol, Program CoChair Ira D. Baxter, Program CoChair ============================================================================ IEEE International Conference on Software Maintenance 2002 Sponsored by IEEE ICSM-2002, Montreal, Canada, 3-6 October 2002 http://www.icsm2002.org icsm2002.info(a)unisannio.it Call for Papers Theme: Maintaining distributed heterogeneous systems ICSM is the major international conference in the field of software and systems maintenance, evolution, and management. This year's theme elaborates on last year's theme of "systems and software evolution in the era of the internet". Standalone legacy applications of yesterday and novel applications using today's technologies are rapidly becoming integrated as part of enterprise-wide and industry-wide systems. The need for rapid integration has led to many distributed heterogeneous systems that are very challenging to maintain and evolve. ICSM 2002 will address these new scenarios and the major challenges of maintenance and evolution. The focus of the conference will be on the new challenges that heterogeneous systems pose for software maintenance, and the new opportunities for researchers and practitioners. A main goal of ICSM is to promote interaction between researchers and practitioners. ICSM 2002 will bring together researchers, practitioners, developers and users of tools, technology transfer experts, and project managers. Jon Pincus (Microsoft) will describe how Microsoft handles software enhancements. Other outstanding Keynote speakers are being arranged. Past conferences have had Parnas, Rombach, McCabe, and Jacobson. ICSM-2002 will offer technical presentations and demonstrations from academia and industry. We are particularly interested in exchanging concepts, prototypes, research ideas, and other results that could contribute to the academic arena and also benefit business and the industrial community. ICSM 2002 will be participatory, with working collaborative sessions and presentations of industry projects. The Conference will be held in conjunction with: WESS -- Workshop on Empirical Studies of Software Maintenance. SCAM -- Source Code Analysis and Manipulation WSE -- Workshop on WEBsite Evolution Topics of interest include but are not restricted to the following aspects of maintenance and evolution: - Methods and theories - Maintenance and/or productivity metrics - Organizational frameworks - Preventive maintenance - Design for maintenance - Tools and environments - Life cycle and process control - Models/methods for error prediction - User interface evolution - Commercial off-the-shelf (COTS) - Third party maintenance - Freeware and open source applications - Program comprehension - Software and system visualisation - Knowledge based systems - Measurement of software - Formal methods - Legal aspects and standards - Software reusability - Internet and distributed systems - Empirical studies - Testing and regression testing - Remote, tele-work - Version and configuration management - Processes and strategies - Management and organisation - Co-operative applications - Source code analysis and manipulation - Processes and strategies - Impact of new software practices - Programming languages - Reengineering and reverse engineering - Multimedia systems RESEARCH PAPERS: Research papers should describe original and significant work in the research and practice of software maintenance and evolution. Case studies, empirical research, and experiments are particularly welcome. We also welcome papers that present leading edge and novel ideas in maintenance. Papers must not exceed 5000 words (10 pages IEEE style) in length, in English. To encourage strong submissions a prize will be awarded for the "Best Paper as Submitted". This Prize is offered by John Wiley & Sons, the publishers of the Journal of Software Maintenance and Evolution. The Program Committee will select the winner and a formal presentation of the Prize will be made in Montreal at ICSM 2002. FAST TRACK PAPERS: Fast Track papers should describe on-going research activities, or summarize the experience in software maintenance and evolution. Papers must not exceed 4 pages, IEEE style, in length, in English. Accepted fast-track papers will be included in a dedicated section of the conference proceedings. DISSERTATION FORUM: We welcome submissions of young researchers that have delivered their dissertation (Masters or Ph.D.) in the last three years. An award will be issued for the best submission. Four page summaries of accepted dissertations will be included in the conference proceedings and a special forum section will be organised at the conference. INDUSTRIAL APPLICATIONS: Proposals for presentations of Industrial Applications are welcome. These can be state-of-the-art descriptions, experience reports and survey reports from real projects, industrial practices and models, or tool demonstrations. A dedicated sub-committee of the program committee will review Industrial Application proposals and a 1-page summary of accepted proposals will be included in the conference proceedings. TUTORIALS: Tutorials should present software maintenance and evolution topics of interest to practitioners. Tutorials may be full day or half-day in length. SUBMISSION STYLE: PDF and/or Postscript electronic submission only. Papers longer than 15 pages or 6000 words will be returned to the authors. Acceptance notification will occur July 1, 2002. IMPORTANT DATES Research Papers deadline: 18 March 2002 mailto:icsm2002.full@unisannio.it Fast Track Papers deadline: 1 May 2002 mailto:icsm2002.short@unisannio.it Dissertation Forum deadline: 1 May 2002 mailto:icsm2002.thesis@unisannio.it Industrial Applications deadline: 1 May 2002 mailto:icsm2002.industry@unisannio.it Tutorials deadline: 18 March 2002 mailto:icsm2002.tutorial@unisannio.it

1 0

Compiler problem or dumb mistake?
by mgross＠dorsai.org 03 Feb '02

03 Feb '02

Here's the problematic snippet, using GHC 5.00.2: mapWidList :: [(Int,Int,Bool)] -> [WidNode] -> Int-> [WidNode] mapWidList showList widNodes seq --map (\x -> (checkWid showList x (widNodes!!x))) -- [0 .. ((length widNodes) -1)] | (length widNodes ) < seq + 1 = [] | otherwise = (checkWid showList seq (widNodes!!seq) ): (mapWidList showList widNodes (seq+1)) The commented lines are what I would really like, but trace indicated that the anonymous function is never invoked, so I wrote out explictly recursive code. However, while trace indicates that the both alternatives are appropriately repeatedly tested, checkWid is never invoked. I have modified checkWid to assure that laziness is not the problem (I suffed in code that prevents prediction of the result returned by checkWid), so something else is going on here. Anyone care to take a shot at this one? Thanks in advance. Murray Gross mgross(a)dorsai.org

1 1

FME 2002 Tool Demonstrations Call For Participation
by Paul Mukherjee 03 Feb '02

03 Feb '02

[Apologies if you receive multiple copies] FME 2002: Tool Demonstrations Call For Participation ===================================================== FORMAL METHODS EUROPE FME 2002: Formal Methods: Getting IT Right International Symposium 22-24 July 2002 Copenhagen, Denmark http://floc02.diku.dk/FME/ The FME 2002 International Symposium will feature tool demonstrations. Builders and vendors of tools that support the use of formal methods will be able to demonstrate these tools, both in private sessions and in more formal presentations. FME 2002 will be held as part of of the third Federated Logic Conference (FLoC'02). Tool demonstrators will therefore have an audience drawn from over 30 co-located symposia, conferences and workshops. The FME 2002 Symposium ---------------------- FME 2002 is the eleventh in a series of symposia organised by Formal Methods Europe, an independent association whose aim is to stimulate the use of, and research on, formal methods for software development. These symposia have been notably successful in bringing together a community of users, researchers, and developers of precise mathematical methods for software development. The theme of FME 2002 is Formal Methods: Getting IT Right. The double meaning is intentional. On the one hand, the theme acknowledges the significant contribution formal methods can make to Information Technology, by enabling computer systems to be described precisely and reasoned about with rigour. On the other hand, it recognises that current formal methods are not perfect, and further research and practice are required to improve their foundations, applicability and effectiveness. Facilities ---------- Demonstration stands: a limited number of monitors are available free of charge, on a first- come first-serve basis. Further equipment may be hired locally, at the expense of the exhibitor. Costs ----- Other than the normal conference registration fee, the basic cost of exhibiting at FME 2002 is free. However any special facilities used by exhibitors will be charged to the exhibitor at cost price (see Facilities). Registration & Contact ---------------------- For further information, or to register as a tool demonstrator at FME 2002, contact the tool demonstrations coordinator: Dr Paul Mukherjee Systematic Software Engineering A/S Denmark Email: pmu(a)systematic.dk The deadline for registration is **June 21st 2002**. ---- Paul Mukherjee (pmu(a)systematic.dk)

1 0

Re: using composition with multiple argument functions
by Dean Herington 03 Feb '02

03 Feb '02

On Fri, 1 Feb 2002, Ashley Yakeley wrote: > At 2002-02-01 10:45, Dean Herington wrote: > > >h1 :: (a -> a -> (a,a)) -> (a -> a -> (a,a)) -> (a -> a -> (a,a)) > >h1 = f1 # g1 > > I think you mean: > > h1 :: (a -> a -> (a,a)) -> (a -> a -> (a,a)) -> (a -> a -> (a,a)) > h1 f g = f # g Actually, I botched the type declaration. I meant: > h1 :: a -> a -> (a,a) > h1 = f1 # g1 But your suggestion, which compiles without complaint, gives me an inkling why the above doesn't work. With `h1 f g = f # g` and the type declaration for h1, the compiler sees that f1 and g1 must be used at the same type. With `h1 = f1 # g1`, that connection is missing. So I guess my `Composable` class example can't work in general. Dean

1 0

Re: syntax difference between Hugs and GHC
by Ian Lynagh 02 Feb '02

02 Feb '02

On Fri, Feb 01, 2002 at 02:32:37PM -0500, Dean Herington wrote: > GHC accepts the declaration: > > (a # b) = a ++ b > > but Hugs rejects it, saying: > > Syntax error in input (unexpected `=') > > Who's right? hugs I believe. Ian

1 0

TEST
by Mark Wogahn 02 Feb '02

02 Feb '02

This is a test Please ignore

1 0