- Haskell - Haskell.org

RE: foralls in class assertions
by Ashley Yakeley 02 Mar '02

02 Mar '02

At 2002-02-20 13:15, Simon Peyton-Jones wrote: >I have not implemented, yet. As always my implementation >priorities are strongly influenced by my perception of whether >some enhancement would be used. Maybe you can outline >why such a change would be useful to you? I only have the >example in our paper as motivation so far. I just came across one. I want to create a class for refs, such that they are in Eq: class (forall a. Eq (r a)) => Ref m r where { newRef :: a -> m (r a); ... etc. } -- Ashley Yakeley, Seattle WA

1 0

Re: FW: Haskell 98 lexical syntax again
by Ashley Yakeley 01 Mar '02

01 Mar '02

At 2002-02-28 07:18, Simon Peyton-Jones wrote: > whitechar -> newline | vertab | space | tab | uniWhite > newline -> return linefeed | return | linefeed | formfeed > return -> a carriage return > linefeed -> a line feed > >This means that CR, LF, or CRLF, are all valid 'newline' separators, >and the same sequence of characters should therefore work on any >Haskell implementation. Good. While you're fiddling with it, I recommend this: newline -> return linefeed | return | linefeed | formfeed | uniLineSep | uniParaSep uniLineSep -> any char of General Category Zl uniParaSep -> any char of General Category Zp Unicode defines two codepoints that unambiguously mean 'line separator' (\u2028) and 'paragraph separator' (\u2029). As it happens, they are the only codepoints in General Categories Zl and Zp. There are other paragraph separators (e.g. Georgian and Urdu), but they are actual marks rather than being whitespace and are not in GC Zp -- much like the pilcrow. uniWhite -> any UNIcode character defined as whitespace This is fine. But note that whitespace is an 'extended property', it can't be derived from General Category: <http://www.unicode.org/Public/3.1-Update1/PropList-3.1.1.html> -- Ashley Yakeley, Seattle WA

2 1

Re: H98 Report: expression syntax glitch
by cwitty＠newtonlabs.com 01 Mar '02

01 Mar '02

"Simon Peyton-Jones" <simonpj(a)microsoft.com> writes: > I didn't phrase it right. I meant that a let/lambda/if always > extends to the next relevant (not part of a smaller expression) > punctuation symbol; and if that phrase parses as an exp > that's fine, otherwise it's a parse error. So I should not really > speak in terms of 'ambiguity'. > > Perhaps we can simply say that > let .. in exp > is legal only if the phrase is followed by one of the punctuation > symbols. That's nice, because we don't need to talk of > "not part of a smaller expression". > > So (let x = 10 in x `div`) would be rejected because > x `div` > isn't a exp. If you're going to modify the syntax in the report to match what implementors actually implement, you may also want to change the "illegal lexeme" definition for closing implicit layout. I believe that do a == b == c is (according to the Standard) legal syntax that means (do {a == b}) == c but I'll bet that most if not all Haskell parsers would get it wrong. Carl Witty

1 0

who's name my name
by RONALD HASKELL 01 Mar '02

01 Mar '02

1 0

help a lost soul
by Rowan Corben 01 Mar '02

01 Mar '02

sir, i have been set an assignment by my university....we are so badly taught that i have absolutley no idea how to do it! I would be more than happy to post payment for however much you feel your time is worth... Please,please help: ex.1) Extend to the library database to include category of loan for overnight + 4 week loans-you should use the following data types.The TIME and DATE are the due time and date for books.You should provide enough data to reasonably test your code. data LoanType = Overnight Date Time | FourWeek Date deriving (Show,Read) data Time =Time (Hours,Minutes) deriving (show,Read) data Date =Date (Year,Month,DayNum) deriving (Show,Read) type Hours = Integer type Minutes =Integer type Year = Integer type DayNum =Integer data Month = January|Februrary|March|April|May|June|July|August|September|October|November|December deriving (Eq,Ord,Enum,Show,Read) overdue books are fined at the following rates: OVERNIGHT the due time is 24 hours from the time borrowed to the nearest hour above (for example,a book borrowed at 12.35 would be due back at 13.00 the next day).Overdue books are fined at 0.1p per minute rounded to the nearest penny. FOURWEEK the due date is four weeks from the borrowing date.Overdue books are fined at 10p per day ex.2) To calculate fines you will need to impliment functions over DATE and TIME.You will also need a data type to represent time periods: data TimePeriod = TimePeriod (Days,Hours,Minutes) deriving (Eq,Ord,Show,Read) type Days = Integer *afterTime which takes two times and returns True if the first is after the second. *beforeTime which takes two times and returns True if the first is before the 2nd *timeBetween which takes two times and returns the time between the first and the 2nd *timeIncr which takes a time and a time period and returns a new time (time should be represented as a 24 hour clock *timeTo24String which takes a tim eand displays it as a string in 24hr format *timeTo12String which takes a time and displays it as a string in 12 hour format ex.3) Make DATE and TIME instances of the type classes Eq and Ord ex.4) For overnight books most fines are on the same day-write a function that takes a book and a time and calculates the fine on the book (assuming it is returned on the due date but after the due time). If you could help i will be extreamly gratefull!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! haskinsgreg(a)hotmail.com

2 1

To:haskell,泛微协同商务系统简介
by contact＠weaver.com.cn 01 Mar '02

01 Mar '02

1 0

use of undefined type
by Andre W B Furtado 28 Feb '02

28 Feb '02

I'm developing a tool that will help game programmers to develop games in Haskell. To create a game object, the programmer must call the function *object* as follows: object name_of_object position_of_object speed_of_object I would like also to add another param to this function, which type would be anyone defined by the programmer. Unfortunately, as Haskell does not allow things like: type Game = (Name,Position,Speed,t) where t is an undefined type, I'm forced to add "t" to the left side of the type synonym (type Game t = ...). But this is realling doing a mess in my code, since I have to pass this "t" all around. That's why I ask if anyone knows another idea to solve this problem... Thanks a lot, -- Andre W

2 1

FW: Haskell 98 lexical syntax again
by Simon Peyton-Jones 28 Feb '02

28 Feb '02

Folks, Two small matters of lexical syntax for Haskell 98. (As ever, I'm posting this to the whole list because I feel I shouldn't fiddle with the Report without telling you all. Partly because many eyeballs is good for debugging, partly because there might be an objection in principle that I don't know of.) 1. Ian Lynagh pointed out the following problem: | The report says | | whitechar -> newline | return | linefeed | vertab | formfeed | | space | tab | uniWhite | newline -> a newline (system dependent) | return -> a carriage return | linefeed -> a line feed | | so, if your system defines a newline to be a line feed, an | implementation is free to choose whether to lex a line feed | as a whitechar or a newline, which makes quite a difference | when you consider the layout rule! I propose to solve this as follows: whitechar -> newline | vertab | space | tab | uniWhite newline -> return linefeed | return | linefeed | formfeed return -> a carriage return linefeed -> a line feed This means that CR, LF, or CRLF, are all valid 'newline' separators, and the same sequence of characters should therefore work on any Haskell implementation. 2. As a separate matter, I propose to replace the production for ANY by ANY -> graphic | whitechar This seems nicely dual to any -> graphic | space | tab The existing production for ANY is: ANY -> any | newline | vertab | formfeed | return | linefeed | uniWhite which simply repeats whitechar + space + tab. Simon

1 0

SBLP'2002 deadline extension --> March 7
by Carlos Camarao de Figueiredo 28 Feb '02

28 Feb '02

The deadline for submissions to SBLP'2002 has been extended to March 7, 2002. The full updated call for papers is included below. =============================================== SBLP'2002 VI Brazilian Symposium on Programming Languages http://www.inf.puc-rio.br/sblp Departamento de Informática PUC-Rio Rio de Janeiro, RJ, Brazil June 05-07, 2002 =============================================== Final Call for Papers --------------------- The VI Brazilian Symposium on Programming Languages (SBLP'2002) will be held at Pontifícia Universidade Católica do Rio de Janeiro (PUC-Rio) in Rio de Janeiro, Brazil, on June 05-07, 2002. The symposium is sponsored by the Brazilian Computer Society (SBC) andg aims to provide a forum where researchers, educators, and practitioners present and discuss the latest theoretical and practical work on programming languages. We invite authors to contribute to SBLP'2002 with the following kinds of submission: * Technical research papers introducing original research results on topics such as (but not limited to): - Programming language design and implementation - Formal semantics of programming languages - Domain-specific programming languages - Visual programming languages - Programming languages for mobile, WWW, and network computing - Script languages - Design and implementation of programming tools and environments - New programming models - Theoretical foundations of programming languages - Teaching programming languages * Experience reports on the use of programming languages, tools, and environments. The reports should clearly state the problems and difficulties identified on using those programming languages or technologies on projects, possibly giving solutions to those problems or hints to avoid them. * Tutorial proposals on subjects related to programming languages, APIs, tools, environments or theories. There will be also invited lectures, tutorials, panels, and working meetings to closely group together professionals interested on specific research topics. Important dates --------------- Deadline for submissions: March 7, 2002 Notification of acceptance: April 8, 2002 Camera-ready version: May 15, 2002 Conference chair ---------------- Edward Hermann Haeusler Departamento de Informática Pontifícia Universidade Católica do Rio de Janeiro Tel.: +55 (21) 3114-1500 R: 4345 email: hermann(a)inf.puc-rio.br Program Chair ------------- Carlos Camarão Departamento de Ciência da Computação Universidade Federal de Minas Gerais Tel: +55 (31) 3499 5889 email: camarao(a)dcc.ufmg.br Submission details ------------------- Contributions can be written in Portuguese, English or Spanish. Those written in English can be selected for publication elsewhere (probably Elsevier Electronic Notes in Theoretical Computer Science). All papers and experience reports will be published in the conference proceedings. Papers should have at most 14 pages and experience reports at most 8 pages. ---- Tutorials will be published in a separate proceedings. They should cover material of postgraduate level. The tutorial submission may be only a proposal, containing: - title - author names - motivation, describing the relevance of the subject in the area of programming languages - abstract - description of the presentation (optional) Tutorial proposals will be selected according to i) its technical quality and ii) expected relevance and interest from the community. The final tutorial should contain at most 30 pages. ---- Contributions should use the standard format of SBC (Brazilian Computer Society). They are available in: - LaTeX: http://www.sbc.org.br/templates/sbc-template-latex.zip - PDF/Adobe Acrobat: http://www.sbc.org.br/templates/sbc-template-pdf.zip - Word: http://www.sbc.org.br/templates/sbc-template-dot.zip Use of LaTeX is preferred. Examples of the use of the SBC format can be found in these zip files. (You can also obtain them by visiting the site http://www.sbc.org.br and following the links *eventos* and, afterwards, *Informações úteis*.) For submission of contributions, fill out the required information at http://www.dcc.ufmg.br/~camarao/sblp/forms/authpaper_reg.html ======================================================================

1 0

RE: Behavior of fromInteger on out-of-range arguments
by Simon Peyton-Jones 28 Feb '02

28 Feb '02

| By the way, the report says: "Class Enum defines operations | on sequentially | ordered types." I think the "sequentially" means that | multiple applications | of succ to a value shall not result in the same value. That's | why I think | that succ (maxBound :: Int) should be an error and not | minBound :: Int. | Because i + 1 should be equal to succ i for every Int value | i, (maxBound :: | Int) + 1 should also be an error and so should every | arithmetic operation | that overflows or underflows. The revised version of the report http://research.microsoft.com/~simonpj/haskell98-revised says that succ maxBound is an error for any Bounded type. So I think this is covered already. Simon

1 0