- Haskell-Cafe - Haskell.org

��ã�
by houshen2 15 Jul '02

15 Jul '02

�װ��Ͽͻ�� ã��ʺ� ��ȸ�л��ǵĹ�ע��ҹ�˾Ϊ��ף��Ƴ��Żݲ�Ʒ�� 1��200M��HTML�ռ䣩+ ��һ��150Ԫ/�� 2��60M�ռ�+60M��ҵ�ʾ� + ֧��ASP��CGI + ��һ��236Ԫ/�� 3��100MP�ռ�+100M��ҵ�ʾ� + ֧��ASP��CGI��ACCESS + ��һ��336Ԫ/�� ҹ�˾��һ��ר��ڸ��缼��Ĺ�˾��Ŷ��ľ��飬�� ž��Ե��ƣ� ��100M�Ŀ��(��ͨ��ŵ��ն˽��˾��)�� ӵ��һ��߼��Ա��Լ��ϸ�� ۶��е��վ��Ƕ��б��ݣ��ʵʱ��ر�֤��ȶ��ԣ� ��ռ��ϣ��ѡ��--��ǵ��վ http://www.88dns.com/�˽��飬 ��ϵE-mail:webmaster@logindns.com лл!�� ף��꼪�顢��С��˳��!!! ��ӯͨԶ��ӿƼ��޹�˾ --------------------------------------------------------------- �е�Ⱥ��ʼ�,��ר��(http://www.21cmm.com) ��CMM��У(http://www.21cmm.com)��Ŀ��ר��

1 0

replacing the Prelude (again)
by Bernard James POPE 13 Jul '02

13 Jul '02

Hi all, Sorry to dig up an old topic, but I think this is an important one. (at least it is for me). I have run into a problem recently. I am writing a debugger for Haskell. It is based on a source-to-source transformation. The important bit is that the type of functions changes under the transformation. If you want to debug calls into the Standard Prelude (yes this is useful) then a transformed Prelude must be used. The idea being that a transformed program imports a transformed Prelude. That's okay, my debugger can transform all of the Standard Prelude since it is just a Haskell module (with provisions for primitive functions of course). The problem is that when I replace the Standard Prelude with a transformed Prelude the defaulting mechanism doesn't work anymore. What I would like is that the defualting rules refer to the classes in my version of the Prelude, not the Standard Prelude. I am using ghc version 5.03, and I don't think -fno-implicit-prelude can help here. I do think that this issue is independent of the Haskell environment, and more an issue of the design of the language. Now there have already been some discussions about replacing the Standard Prelude with a non-Standard Prelude. The trick being that a fair degree of the language definition makes use of things in the Standard Prelude. See for example: Dylan Thurston Replacing the Prelude http://www.haskell.org/pipermail/haskell-cafe/2002-May/003032.html Primitive types and Prelude shenanigans http://www.haskell.org/pipermail/haskell-cafe/2001-February/thread.html#1641 I'm fond of the idea proposed by Marcin 'Qrczak' Kowalczyk: May I propose an alternative way of specifying an alternative Prelude? Instead of having a command line switch, let's say that 3 always means Prelude.fromInteger 3 - for any *module Prelude* which is in scope! That is, one could say: import Prelude () import MyPrelude as Prelude IMHO it's very intuitive, contrary to -fno-implicit-prelude flag. Presuming of course that defaulting would follow this path and refer to the new Prelude. I'm wondering if any further progress has been made towards this? Or perhaps someone can think of a temporary solution to my problem? Cheers, Bernie.

2 1

what's the difference?
by Cagdas Ozgenc 12 Jul '02

12 Jul '02

Greetings. What is the difference between the following two scenarios: 1) class Eq a where (==) :: a -> a -> Bool class Eq a => Ord a where ( < ) :: a -> a -> Bool 2) class Eq a where (==) :: a -> a -> Bool class Ord a where (eq),( < ) :: a -> a -> Bool instance Ord a => Eq a where (==) = eq eq is just a rename for == to avoid the nameclash The second scenario resembles Russell's Paradox. Typeclass of a typeclass. Anyhow we are loosing orthogonality here. Thanks

2 1

Job Advertisment
by Chris Dornan 11 Jul '02

11 Jul '02

The ARM Web site is advertising a Principal Research Engineer position; see http://www.arm.com/hr.nsf/iwpList61/90A8BD2585A0CE2F80256BF10051000F?OpenDo… and the summary attached to the end of this mail message. Note that although the job is for a Principal Research Engineer with a strong emphasis on microprocessor architecture, a high degree of proficiency in programming, preferably Haskell and C, is regarded as essential. Chris Dornan Principal Research Engineer ARM R&D cdornan(a)arm.com +44 (0)1223 400498 Principal Research Engineer, Cambridge Reference: 02MKRD003 The Research and Development Division are seeking a highly motivated individual who has research experience and who's interests lie in the fields of computer languages, microprocessor architecture, and/or microprocessor simulation. The successful candidate will be involved in a team developing next generation microprocessor architectures. As well as architecture development, this role will involve developing, implementing, and integrating a range of sophisticated tools to assist in the analysis of microprocessor architectures and implementations. The successful candidate will be working in an environment which allows experimentation and provides autonomy, but expects innovation and results; hence the candidate will be of a very high caliber. This post would suit a PhD graduate or someone with a background working in research in Industry. Skills Essential * A high degree of proficiency in programming (preferably in Haskell & C). * A good understanding of microprocessor architectures. * A working understanding of computer languages. * A background in Research and innovation.

1 0

�𾴵��Ͽͻ��!
by web 11 Jul '02

11 Jul '02

��http://www.comdns.com��ʺ��л��տ��ʼ��ϵ�ϣ��ܳ�Ϊ��ڹ��Ҫ ��顣��Ϣ��ã��ɾ��ڴ��Ƕ��ʾǸ��!! �� http://www.comdns.com��һ��ר��Ϊ��ҵ��λ�ṩ��վ��衢��ƽ̨��Ϣ��… ˾��Ŀ��ǳ�Ϊ��缼��ƽ̨��֮һ��ǵķ��ɫ�ǣ�˫Ӳ��ʱ��ݣ��ʧ�� ˾�Ƴ��´��⽫��ֵ��ѡ�� 1.��200M��HTML�ռ�+1��150Ԫ/�꣨�ں��ݣ�� 2.��60Masp��վ�ռ�+60��ҵ�ʾ֣��п��䣩+1��246Ԫ/�꣨�ں��ݣ�� 3.��׼��200MASP��վ�ռ�+200��ҵ�ʾ֣��п��䣩+1��+30M Access��ݿ⣬��336Ԫ/�� ں��ݣ�� 4��ʵ��ע��ֻ��500��/�� 5.��Ż��վ��跽��ο�� Ŭ��ã��Ҳ��ʧ��ǲ��һ��Ĳ��ġ��ǳ�ŵ�� ʱ�ɰ�ʵ��˿ ��ף��ģ�˳�� webmaster of www.comdns.com webmaster(a)comdns.com ========================================================================================= ��ʼ��õ��˵��Ϣ��˵��û�ã��ֱ�Ǹ��ʼ�� Գ�ŵֻ��һ�Ρ��ϣ��Ǵ��б��ɾ��ĵ�ַ��Ÿ��ĵ�ַ��лл�� ========================================================================================== --------------------------------------------------------------- �е�Ⱥ��ʼ�,��ר��(http://www.21cmm.com) ��CMM��У(http://www.21cmm.com)��Ŀ��ר��

2 1

haskell.sty
by François Bédard 10 Jul '02

10 Jul '02

Hello, I find it interesting that Haskell should make native provision for a basic form of literate programming, and this immediately suggests, of course, the possibility of mixing code with LaTeX commands. The problem is that putting one's hand on a dedicated LaTeX extension doesn't seem so straightforward. The link to Andrew Cooke's haskell.sty is broken and I couldn't find the file at his new home (www.acooke.org/andrew/) Other possibilities such as Manuel Chakravarty's, lambdaTex and lhs2tex (which I, admittedly, have only looked at briefly) deviate from the \begin{code}...\end{code} suggested by the report and seem to require more (La)TeX proficiency on the part of the user. As my interest is to introduce the ideas of literate programming and LaTeX to people thorougly unfamiliar with such, I need to keep things as simple as possible - of special interest is the fact that a given file can be submitted as is to both hugs and latex, without the need for preprocessing. I've tried to address the question by redefining an existing environment \usepackage{moreverb} \newenvironment{code}{\begin{verbatimtab}[4]}{\end{verbatimtab}} but moreverb and the like depend on verbatim which is apparently the one environment you can't use like this and I'm no such LaTeX guru that I can come up with better alternatives. So the question is : would anyone know where to find haskell.sty (presuming that's what I need) or is there some fairly simple solution I've missed ? Thanks, François

3 4

Parsec question
by Eray Ozkural 10 Jul '02

10 Jul '02

Hi there, I'm hacking together a small parser for a subset of C++. I'm in trouble with left recursion as you may guess. What is the best way to write a parser for the part of grammar below in Parsec? Declarator -> Name -> PtrOper Declarator -> Declarator '(' ArgDeclarationList ')' [CvQualifierList] -> Declarator '[' [ConstantExp] ']' -> '(' Declarator ')' Here [X] denotes an optional non-terminal X, and all symbols starting with a capital letter are non-terminals. The remedies I thought of were using chainl or eliminating left recursion in the grammar. What do you think should be done in such a case? Regards, -- Eray Ozkural <erayo(a)bilkent.edu.tr> Comp. Sci. Dept., Bilkent University, Ankara www: http://www.cs.bilkent.edu.tr/~erayo GPG public key fingerprint: 360C 852F 88B0 A745 F31B EA0F 7C07 AE16 874D 539C

1 0

Fw: 2 Positions
by Manuel M. T. Chakravarty 06 Jul '02

06 Jul '02

Not 100% Haskell-related, but I thought some people on this list might be interested in these two open positions at UNSW. Manuel

1 0

Is there any algorithms for solving equation systems
by Daniel Andersson 04 Jul '02

04 Jul '02

Hi I looking for algorithms for solving equation systems and wonder if there is anyone that has seen an algorithm, either a numerical or an analytical, for solving equation systems in haskell. thanks Daniel _____________________________________________________ Följ VM på nära håll på Yahoo!s officielle VM-sajt www.yahoo.se/vm2002 Håll dig ajour med nyheter och resultat, med vinnare och förlorare...

1 0

Re: Writing a counter function
by Jon Cast 02 Jul '02

02 Jul '02

Mark Carroll <mark(a)chaos.x-philes.com> wrote: > On Sat, 29 Jun 2002, Samuel E. Moelius III wrote: > (snip) > > Here's another not-exactly-what-you-wanted solution. :) > (snip) > Do any of the experimental extensions to Haskell allow a > what-he-wanted solution? I couldn't arrange one in H98 without > something having an infinitely-recursive type signature. That's because the problem requires an infinitely-recursive type. > I'm sure it would have been easy in Lisp, and he already gave a Perl > equivalent, That's because both Lisp and Perl are weakly typed. Haskell is strongly typed. Consider Lisp: (defun self-apply (f) "Apply F to itself." (f f)) No problem (and I'm sure you can pull the same trick off in Perl). Consider Haskell: self-apply f = f f The *typing algorithm* (the thing that didn't complain in Lisp) proceeds roughly as follows: f is applied to at least one argument, so f must have type a -> b. Therefore, f's argument (f) must have type a. So, we conclude: f :: a -> b f :: a But f can only have one type, so we set its types equal: a = a -> b This is clearly recursive, right? > so I'm wondering if it could be at all sane for Haskell to allow > such stuff Sure. All it has to do is: 1. Create its own newtype in response to such things as `self-apply' above. 2. Ensure that self-apply f = f f and self-apply' g = g g have the same type. I would *love* to hear ideas on how to do that, but it's difficult. > and if Haskell is somehow keeping us on the straight and narrow by > disallowing the exact counter that was originally requested. Well, it's a more general problem than the `exact counter'. And, yes, Haskell is erring on the side of safety here; there's a reason it's called a ``statically typed language''. > The beauty of his request was that it was so simple and seemed to > make sense; I went ahead and tried to fulfill it before realising I > couldn't do it either. Well, it makes sense, yes. But I think learning to manually `unify' these things (add a newtype) is not hard, and probably useful --- Haskell is not the only statically-typed language out there. Learn how to solve this problem, and you understand the problem, the solution, typing, and life in general :) > -- Mark Jon Cast

3 2