silly message when uninstalling GHC in Windows98
Just reporting a silly message that appears after uninstalling GHC in Windows98 (perhaps other windows platforms also): don't forget to add [ghc path]/bin to your PATH Why would it be necessary, since I am uninstalling it? Cheers, -- Andre ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: garbled error message
Thanks for the report. I'm not 100% certain why it happens in 5.04.2, but it doesn't happen in the HEAD. The error message is still not great, but at least it's not gibberish. Simon Data.hs:288: Could not deduce (ReprType r t) from the context () arising from use of `getter'' at Data.hs:288 Probable fix: Add (ReprType r t) to the expected type of an expression In the first argument of `runDR', namely `(getter' repr)' When checking the type signature of the expression: runDR (getter' repr) ... 0 rContents :: forall t. CC t In a 'do' expression: val - runDR (getter' repr) ... 0 rContents :: forall t. CC t | -Original Message- | From: Dean Herington [mailto:[EMAIL PROTECTED]] | Sent: 27 January 2003 15:41 | To: [EMAIL PROTECTED] | Subject: garbled error message | | With the attached files, I get an apparently garbled error message | during compilation. | | buzzard(105)% make | ghc --make -package data -package concurrent -package posix Data | ghc-5.04.2: chasing modules from: Data | Compiling Repr ( Repr.hs, Repr.o ) | Compiling Data ( Data.hs, ./Data.o ) | | Data.hs:288: | Could not deduce (ReprType r t) from the context () | Probable fix: | Add (ReprType r t) | to the When generalising the type of an expression | arising from use of `getter'' at Data.hs:288 | In the first argument of `runDR', namely `(getter' repr)' | When checking the type signature of the expression: | runDR (getter' repr) ... 0 rContents :: forall t. CC t | *** Error code 1 | make: Fatal error: Command failed for target `default' ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: linker error
The desugarer generates tuples when desugaring mutually-recursive functions, and I bet that is what is causing the problem. These optimiser usually gets rid of them, as you found. It's a known shortcoming which has never gotten high enough up the list to solve. Could you please keep the source code to use as a test case? Then we can check if we do fix it. Ideally just send us a .hs file whose compilation breaks. Simon | -Original Message- | From: Andres Loeh [mailto:[EMAIL PROTECTED]] | Sent: 29 January 2003 17:11 | To: [EMAIL PROTECTED] | Cc: [EMAIL PROTECTED] | Subject: linker error | | Hi there, | | while compiling the latest Generic Haskell version I got the following | linker error: | | UHA_Parser.o(.text+0x117f13): In function `r18Ks_entry': | : undefined reference to `DataziTuple_Z94T_con_info' | collect2: ld returned 1 exit status | | | The file UHA_Parser.hs is a generated parser for the language, using | Ralf Hinze's frown parser generator. | | When I first saw the error, I expected that too large tuples might be | used in that file (motivated by the undefined reference containing the | work Tuple and the number 94, which is higher than the GHC maximum | as declared in the User's guide), but browsing through the file it | does not seem to make much use of tuples at all. | | In the meantime I found out that using -O2 to compile UHA_Parser | will circumvent the bug, so it is not really a problem. | | The bug occurs with both yesterday's CVS 5.05 version and 5.04. | | I can try to produce a better bug description by cutting down the size | of the involved files at least a little bit, but I thought that maybe | you already know where to look ... | | Best, | Andres | ___ | Glasgow-haskell-bugs mailing list | [EMAIL PROTECTED] | http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-653694 ] safe calls in the threaded RTS broken
Bugs item #653694, was opened at 2002-12-14 13:04
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=108032aid=653694group_id=8032
Category: Runtime System
Group: None
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Wolfgang Thaller (wthaller)
Assigned to: Wolfgang Thaller (wthaller)
Summary: safe calls in the threaded RTS broken
Initial Comment:
When returning from a safe (non-threadsafe) call,
resumeThread uses grabCapability to grab the
capability. If another worker thread is executing
haskell code, the capability is not free, but
grabCapability succeeds anyway.
We cannot use grabReturnCapability either, because we
cannot rely on a worker thread being around to wake us.
The only solution I can think of right now is to do
away with the safe/threadsafe distinction and treat all
safe calls as threadsafe. (After all, if we don't spawn
a new worker thread in suspendThread, we will have to
spawn a new worker thread for a callback anyway [in
scheduleThread_], so we're not losing any performance).
The following code fails with various assertion
failures and segfaults. All of them are due to the fact
that the RTS accidentally runs two pieces of haskell
code at once.
This is with ghc-5.05 (CVS HEAD from 11th or 12th of
December) configured with --enable-threaded-rts.
Main.hs
module Main where
import Control.Concurrent(forkIO)
foreign import ccall safe foo foo :: IO ()
foreign export ccall bar bar :: IO ()
bar = putStrLn Hello, world.
fib 0 = 1
fib 1 = 1
fib n = fib (n-1) + fib (n-2)
doSomeWork n = do
putStrLn (fib ++ show n ++ = ++ show (fib n))
doSomeWork (n+1)
main = do
forkIO (doSomeWork 0)
foo
putStrLn foo finished
putStrLn (main says: fib 30 = ++ show (fib 30))
foo.c
extern void bar();
void foo()
{
bar();
}
--
Comment By: Wolfgang Thaller (wthaller)
Date: 2003-02-03 23:44
Message:
Logged In: YES
user_id=566359
Fixed by making safe calls behave like threadsafe calls.
Restoring the traditional behaviour of safe in the threaded RTS requires more work,
and I don't see the point (I prefer to think of the blocking behaviour of safe calls
as a bug, not a feature).
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=108032aid=653694group_id=8032
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-679876 ] multiple symbol definition in libHSbase.a
Bugs item #679876, was opened at 2003-02-03 23:56 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=679876group_id=8032 Category: Build System Group: None Status: Open Resolution: None Priority: 7 Submitted By: Wolfgang Thaller (wthaller) Assigned to: Nobody/Anonymous (nobody) Summary: multiple symbol definition in libHSbase.a Initial Comment: When building the library archive libHSbase.a, the makefile system includes not only all the split object files, but also the file PrimopWrappers.o. The split-object files for PrimopWrappers are also included, so there are multiply-defined symbols. On Mac OS X, this means that ranlib fails to generate a sorted symbol table for the library, which leads to annoying warning messages and longer link times. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=679876group_id=8032 ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-679963 ] hp2hs -c appears broken in ghc-5.04.2
Bugs item #679963, was opened at 2003-02-03 18:14 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=679963group_id=8032 Category: Profiling Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: hp2hs -c appears broken in ghc-5.04.2 Initial Comment: It generates -4.80 -4.80 -4.80 setrgbcolor in the postcript file. ghc-5.04.01 didn't do that, so I'm using the old version. Sengan -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=679963group_id=8032 ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-679966 ] ghci does not appear to restore its signal handlers
Bugs item #679966, was opened at 2003-02-03 18:19 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=679966group_id=8032 Category: Compiler Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: ghci does not appear to restore its signal handlers Initial Comment: I added my own ^C handler to my program, following ghci's code as an example. Once I have run this code, if I ^C during the next compilation, all hell breaks loose (Segmentation fault) I think you need to reset the handlers at the end of running user code: installHandler sigQUIT sig_handler Nothing installHandler sigINT sig_handler Nothing (senganb `at` ia `dot` nsc `dot` com) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=679966group_id=8032 ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-679963 ] hp2hs -c appears broken in ghc-5.04.2
Bugs item #679963, was opened at 2003-02-03 18:14 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=679963group_id=8032 Category: Profiling Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: hp2hs -c appears broken in ghc-5.04.2 Initial Comment: It generates -4.80 -4.80 -4.80 setrgbcolor in the postcript file. ghc-5.04.01 didn't do that, so I'm using the old version. Sengan -- Comment By: Nobody/Anonymous (nobody) Date: 2003-02-03 18:19 Message: Logged In: NO (senganb `at` ia `dot` nsc `dot` com) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=679963group_id=8032 ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: Modifying GHC to accept external Styx code
| I want to use GHC as a backend for my experimental compiler. | I'm trying to modify it to accept styx code from my compiler, and I'm | having some trouble working out where I need to make changes. In truth, | GHC is more haskell code than I've ever seen before in one place, and I'm | a bit lost: can anyone suggest which modules I should become familiar with | and which I should leave alone? You don't say what 'styx code' is. My advice: either translate styx to Haskell, or to External Core. (Probably the latter.) GHC can read both of these in without modification. External Core is a typed lambda calculus. Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: GHC doesn't compile under cygwin
Did you carefully follow the steps described in the Building Guide? http://haskell.cs.yale.edu/ghc/docs/latest/html/building/winbuild.html Simon | -Original Message- | From: Chris Clearwater [mailto:[EMAIL PROTECTED]] | Sent: 28 January 2003 23:36 | To: [EMAIL PROTECTED] | Subject: GHC doesn't compile under cygwin | | Hi, today I installed cygwin and downloaded the GHC source, however | during compilation I get the errors: | | test: 504: unknown operand | test: 500: unknown operand | test: 504: unknown operand | | In addition,I get many Error [127] (ignored) and Error [1] (ignored) | before finally quiting with the unknown operand errors. Attached is the | configure output, confiure log and make output. | | Thanks in advance for any help. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC and C++
Simon == Simon Peyton-Jones [EMAIL PROTECTED] writes: SimonWould either of you like Simon to write up some stand-alone notes that explain how to do Simon it, and what the pitfalls are? You can make suggestions Simon for improving GHC too! I'd be happy to take a first stab at a write-up. It's not a trivial exercise--the Microsoft, Borland, and GNU compilers do not agree on a naming scheme for symbols exported from DLL's. -- Kevin S. Millikin Architecture Technology Corporation Research Scientist Specialists in Computer Architecture (952)829-5864 x. 162 http://www.atcorp.com ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc/cygwin filename resolution issue.
Alex Ferguson [EMAIL PROTECTED] writes: (This was all motivated, btw, by trying to build HaXml under ghc/cygwin, which fell for me at the first hurdle of first catch your hmake in the recipe. I've now gotten as far as a _build_ of hmake, but it then runs into similar issues with its own use of the f/s (rc files and what-not). If anyone has this one down pat already, they might save my tired brain some pain, otherwise I'll summarise to the list if and when I get some sort of resolution myself.) I am planning to release a new version of hmake (and other tools) very soon, and would really *really* like to get these Cygwin problems licked once and for all. To this end, I have rolled a release candidate of hmake-3.07, which I would implore at least one Cygwin user, preferably a couple more, to test-drive before I make a proper release. http://haskell.org/hmake Please mail me with successes as well as failures. By the way, Claus's summary of the problem + fixes was extremely helpful, and I hope it has clarified things sufficiently for me to get it nearly right this time! Regards, Malcolm ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
ghc feature request: core notes
I'm not sure how generally useful this would be, but I would find it
useful to be able to attach notes to core expressions from the Haskell
code. The idea being something along the lines of a code annotation like
a pragma. For instance, in my Haskell program I would have something
like:
f x y =
case {-# CORE my first note #-} g x of
...
then, the core would come out with, instead of:
case g x of ...
we would have
case {note my first note} g x of ...
The reason I would find this useful is somewhat obscure, but the basic
idea is that I need to be able to both preprocess code and then change
core based on how it was preprocessed. I'd like to send annotations like
these out of the preprocessor so they can then be picked up later by my
core transformer.
If this sounds like a good enough idea to go in, but no one has time to
implement it, I could do it myself (probably), but I thought I'd ask the
experts first (or if there's anything like this in there currently)...
- Hal
--
Hal Daume III
Computer science is no more about computers| [EMAIL PROTECTED]
than astronomy is about telescopes. -Dijkstra | www.isi.edu/~hdaume
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: time since the epoch
| the haskell 98 time library is horribly broken, if you are using ghc, | you can deconstruct the time constructor which has an Integer containing | the number of seconds since epoch... otherwise you can use | ... | I dont supose this could be considered a typo in the haskell 98 report? | it is an embarasing thing for a language to not be able to do... Alas, no. CUP is, even as I type, printing the Haskell 98 Report. We'll have to think about how to accumulate further bugs/suggestions for H98. Meanwhile, I suspect there's an opportunity for someone (or a small group) to suggest a new Time library that really does the business, and provide an implementation. If it's sufficiently persuasive, all the implementations will adopt it and it can become a de-facto standard. The implementation is important because Time is a weird enough thing that only an expert can implement the spec! I think the current Time library suffered because no one who Really Cared about time was involved in its design or implementation. Simon ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: ANNOUNCE: Helium, for learning Haskell
Unfortunately, readline history and line-editing commands
do not work at the /usr/local/bin/hi prompt.
One would think they would because before I had readline-dev installed
Helium refused to build. Oh well!
This can hopefully be fixed by applying the simple patch that I
have attached.
Directly after unpacking the .tar.gz archive, say
patch -p0 helium-1.0-readline.patch
I have not thoroughly tested it, but it should work ...
Best,
Andres
diff -Naur helium-1.0.old/heliumNT/src/Makefile.in helium-1.0/heliumNT/src/Makefile.in
--- helium-1.0.old/heliumNT/src/Makefile.in 2003-01-21 16:06:01.0 +
+++ helium-1.0/heliumNT/src/Makefile.in 2003-02-03 12:37:54.0 +
@@ -181,7 +181,7 @@
hi: interpreter/Main.hs utils/OSSpecific.hs
# GHC HeliumInterpreter
- $(HC) --make -iutils -o $(HELIUMBINDIR)/hi$(EXE) interpreter/Main.hs
+ $(HC) --make -package util -iutils -o $(HELIUMBINDIR)/hi$(EXE)
+interpreter/Main.hs
$(STRIP) $(HELIUMBINDIR)/hi$(EXE)
# AG sources
diff -Naur helium-1.0.old/heliumNT/src/interpreter/Main.hs
helium-1.0/heliumNT/src/interpreter/Main.hs
--- helium-1.0.old/heliumNT/src/interpreter/Main.hs 2003-01-17 11:48:35.0
+
+++ helium-1.0/heliumNT/src/interpreter/Main.hs 2003-02-03 12:39:00.0 +
@@ -6,6 +6,7 @@
import Monad
import Char
import List
+import Readline
import OSSpecific
data State =
@@ -44,6 +45,9 @@
processSpecial (l ++ head args) initialState
else
return initialState
+
+-- Initialize readline
+initialize
-- Enter read-eval-print loop
loop stateAfterLoad
@@ -52,9 +56,9 @@
loop :: State - IO State
loop state = do
-putStr (prompt state)
-hFlush stdout
-command' - getLine
+command'' - readline (prompt state)
+let command' = maybe :q id command''
+addHistory command'
let command = trim command'
newState - case command of
(':':cmd:rest) -
Haskell Workshop 2003
ACM SIGPLAN 2003 Haskell Workshop Uppsala, Sweden, End of August 2003 pending approval http://www.functional-programming.org/HaskellWorkshop/cfp03.html Call For Papers The Haskell Workshop forms part of the PLI 2003 colloquium on Principles, Logics, and Implementations of high-level programming languages, which comprises the ICFP and PPDP conferences as well as associated workshops. Previous Haskell Workshops have been held in La Jolla (1995), Amsterdam (1997), Paris (1999), Montreal (2000), Firenze (2001), and Pittsburgh (2002). * Deadlines * Deadline for submission:May 22, 2003 Notification of acceptance: June 23, 2003 Final submission due: July 3, 2003 Haskell Workshop: End of August 2003 * Topics* The purpose of the Haskell Workshop is to discuss experience with Haskell, and possible future developments for the language. The scope of the workshop includes all aspects of the design, semantics, theory, application, implementation, and teaching of Haskell. Topics of interest include, but are not limited to, the following: Language Design with a focus on possible extensions and modifications of Haskell as well as critical discussions of the status quo; Theory in the form of a formal treatment of the semantics of the present language or future extensions, type systems, and foundations for program analysis and transformation; Implementation Techniques including program analysis and transformation, static and dynamic compilation for sequential, parallel, and distributed architectures, memory management as well as foreign function and component interfaces; Tool Support in the form of profilers, tracers, debuggers, pre-processors, and so forth; Applications, Practice, and Experience with Haskell for scientific and symbolic computing, database, multimedia and Web applications, and so forth as well as general experience with Haskell in education and industry; Functional Pearls being elegant, instructive examples of using Haskell. Following the scheme adopted by ICFP 2003, papers in the latter two categories need not necessarily report original research results; they may instead, for example, report practical experience that will be useful to others, re-usable programming idioms, or elegant new ways of approaching a problem. The key criterion for such a paper is that it makes a contribution from which other practitioners can benefit. It is not enough simply to describe a program! * Submissions * Authors should submit papers in postscript format, formatted for A4 paper, to Johan Jeuring [EMAIL PROTECTED] by 22th May 2003. The length should be restricted to the equivalent of 5000 words (which is approximately 12 pages in ACM format). Accepted papers will be available in the form of a technical report of the Utrecht University or an equivalent format in time for the workshop. In addition, the papers will be published by the ACM and will appear in the ACM Digital Library. If there is sufficient demand, we will try to organise facilities for system demonstrations during lunch and coffee breaks. If you are interested in demonstrating an application or tool written in Haskell, please contact Johan Jeuring ([EMAIL PROTECTED]). * Programme Committee * Magnus Carlsson OGI Olaf Chitil University of York Ralf Hinze University of Bonn Johan Jeuring (chair)Utrecht University Jan-Willem Maessen MIT Henrik Nilsson Yale University Simon Peyton Jones Microsoft Research Claus Reinke University of Kent ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
RE: time since the epoch
Simon PJ wrote (snipped) Meanwhile, I suspect there's an opportunity for someone (or a small group) to suggest a new Time library that really does the business, and provide an implementation. If it's sufficiently persuasive, all the implementations will adopt it and it can become a de-facto standard. I already have written a TimeExts library which is in fact bundled with GHC, namely in -package lang. What I ought to do, I suppose, is fishify the comments so Haddock can produce something useful. Basically it allows you to add a time difference to a ClockTime value to get another ClockTime value, or subtract two ClockTime values to get a time difference. The time difference can be a number of picoseconds, seconds, minutes, hours, days, months or years. For all but seconds and picoseconds, it does this by converting to CalendarTime (using toUTCTime), doing complicated Gregorian calendar calculations (I am not proud of the code here), and then converting back using toClockTime. This is probably not a very good way of doing it but at least no-one has complained about it so far. Which means either it's perfect or no-one uses it, I fear the latter. At least it might be a good idea to start with something like this code, rather than reinventing the wheel. Things you need to watch out for are (a) leap seconds; (b) time zones. I didn't really address the time zone problem, instead doing everything in UTC. For us Europeans, it doesn't normally make any difference whether you use local or UTC time when you ask for the date one month from now. ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
[OT] Teaching Haskell in High School
Hi all, Before getting in to this, let me preface my question(s) with a note that I have checked through the Haskell in Education web page and have found various links off there of interest (and I've googled, etc. In short: I've done my homework). That said, I've been in rather close correspondence with my math/computer science teacher from high school. When I first took CS there, they taught Pascal (a year early they had been teaching Scheme). They switched over to VB (alas) recently and have been teaching that for a few years now. The teacher really wants to get away from VB, but is having a somewhat difficult time deciding what to go to. The two most promising options are Haskell and Java. Aside from hype, etc., the primary advantage to Java is that the Advanced Placement (AP) tests are in Java. For those of you unfamiliar with these, high school students can take AP tests and then (typically) skip out of first semester college courses. They're essentially proficiency exams. The way the computer science curriculum is set up at my old school is essentially as either (a) an elective or (b) a replacement for senior year math. The students in the course are usually about 2/3 juniors (16 year olds) taking it as an elective and 1/3 seniors who want to get our of senior year math :). Either way, they've both taken differential calculus, algebra, etc. Note, however, that high school math in the states is very rudimentary when it comes to things like induction and proofs and things of this sort. Due to the fact that CS is essentially an alternative math course, I think it would be interesting to teach Haskell. It would enable the instruction of things the students wouldn't have come across in their ordinary math studies, etc. However, I'm also well aware that Haskell is very difficult to learn (and, I'd imagine, to teach). Given that this would in large part be a first language for them and that they won't have a college-level math background, do you think it would be too much to attempt to teach Haskell at this level, and stick with Java? I'm really interested in any comments/experience/etc. that people have that might assist the teacher (and, to some extent, me) make this decision. Thanks in advance! - Hal ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: [OT] Teaching Haskell in High School
On Tuesday, 2003-02-04, 01:01, CET, Hal Daume wrote: [...] However, I'm also well aware that Haskell is very difficult to learn (and, I'd imagine, to teach). Hi, I wouldn't claim that Haskell is very difficult to learn. I think, people often have problems with learning Haskell because they know imperative programming and try to apply their imperative thinking to programming in Haskell. Some months ago, a first year student told me that she liked Haskell very much and that she didn't find it very difficult. I asked her if she had had experiences with other programming languages before learning Haskell. She answered: No. [...] Wolfgang ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: [OT] Teaching Haskell in High School (fwd)
This matches my experience, too. When I've taught Haskell to first year college students, there have always been some hard core hackers who've been at it in C or VB or Perl or something like that for years, and they rarely take kindly to Haskell. The ones without any programming background do better. I think Haskell would be great for a high school math class. They could learn some logic and induction along with it, and get a few proofs back into the high school math curriculum. Rex Page -- Forwarded message -- Date: Tue, 04 Feb 2003 03:03:03 +0100 From: Wolfgang Jeltsch [EMAIL PROTECTED] To: The Haskell Mailing List [EMAIL PROTECTED] Subject: Re: [OT] Teaching Haskell in High School On Tuesday, 2003-02-04, 01:01, CET, Hal Daume wrote: [...] However, I'm also well aware that Haskell is very difficult to learn (and, I'd imagine, to teach). Hi, I wouldn't claim that Haskell is very difficult to learn. I think, people often have problems with learning Haskell because they know imperative programming and try to apply their imperative thinking to programming in Haskell. Some months ago, a first year student told me that she liked Haskell very much and that she didn't find it very difficult. I asked her if she had had experiences with other programming languages before learning Haskell. She answered: No. [...] Wolfgang ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
PLC 27: call for participation
Dear friends and colleagues, Please circulate this announcement and call for registration! We apologise for multiple mailings. 27th Penn Linguistics Colloquium The 27th Annual Penn Linguistics Colloquium is scheduled for Friday through Sunday, February 21 through 23, 2003 at the University of Pennsylvania campus in Philadelphia. Keynote Lecture: A Compositional Characterization of the Definiteness Effect in Existential-There Sentences Invited Speaker: Professor Edward Keenan of UCLA Panel Discussion: GoffmanÂ’s Legacy and Future Study of Language Interaction Discussants include: Deborah Shiffrin, William Labov Our program includes sessions on language acquisition, syntax, mathematical linguistics, sociolinguistics, historical linguistics, phonology, pragmatics, psycholinguistics, as well as a Special Session in formal semantics. Schedule of talks and local information are available at the conference website: http://www.ling.upenn.edu/Events/PLC/ ***Online pre-registration form is available now and until February 15th *** at http://www.ling.upenn.edu/Events/PLC/registration/register.php The pre-registration fee is $20 (students $15), on-site registration is $23 (students $18). Please pre-register! Early registration will help us estimate the number of attendees, and help you avoid paying extra $3 for on-site registration. If you have questions or concerns, please contact us at one of the following addresses: The Penn Linguistics Colloquium Committee Department of Linguistics 619 Williams Hall University of Pennsylvania Philadelphia, PA 19104-6305 [EMAIL PROTECTED] http://www.ling.upenn.edu/Events/PLC This event is supported by funding from GSAC, the Graduate Student Association Council of University of Pennsylvania. ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: [OT] Teaching Haskell in High School
I had the good fortune to teach Haskell to some thousand freshmen a few years ago, and noticed that some who did especially well had no previous programming experience. This supports Wolfgang Jeltsch's claim that Haskell is not inherently difficult to learn. I've taught similar numbers of students C++, and I find Haskell considerably easier to teach (and much easier on the conscience!). Freshmen innocent of programming experience are increasingly rare, however, so we have to deal mainly with students who've been trained to think not only imperatively but operationally. Their weak program-design skills, and their meager understanding of the excessively complicated languages they're using (C++, Java, ...), result in marathon debugging sessions, which they're been trained to accept as a normal part of software development. How such students respond to Haskell depends heavily on their attitude. Some feel lost without a debugger, and resist any nudge away from their operational thinking. The more open-minded students, on the other hand, recognize in Haskell a means of expressing computational ideas with far more economy than they are used to, and report that learning Haskell has improved their thinking about programming even if they never use Haskell again. Whether Haskell would be a good language for a high-school programming class (this thread's original question) depends on the class's goals. If it's intended as vocational training, i.e., direct preparation for employment, then some language more fashionable in industry would probably be appropriate. On the other hand, if it's intended as training in precise thinking, then Haskell can't be beat. Best, --Ham At 3:03 AM +0100 2/4/03, Wolfgang Jeltsch wrote: On Tuesday, 2003-02-04, 01:01, CET, Hal Daume wrote: [...] However, I'm also well aware that Haskell is very difficult to learn (and, I'd imagine, to teach). Hi, I wouldn't claim that Haskell is very difficult to learn. I think, people often have problems with learning Haskell because they know imperative programming and try to apply their imperative thinking to programming in Haskell. Some months ago, a first year student told me that she liked Haskell very much and that she didn't find it very difficult. I asked her if she had had experiences with other programming languages before learning Haskell. She answered: No. [...] Wolfgang -- -- Hamilton RichardsDepartment of Computer Sciences Senior Lecturer The University of Texas at Austin 512-471-9525 1 University Station C0500 Taylor Hall 5.138Austin, Texas 78712-1188 [EMAIL PROTECTED][EMAIL PROTECTED] -- ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: [OT] Teaching Haskell in High School
I've also been working high school students a bit and functional programming is a great way to teach the principals of computation. The best results come when FP is applied to domains that get kids excited. I've had very good luck with Haskore as an excellent way to bring computation to a general audience. I'm also working on a student friendly version of Pan that should be releasable in a few more weeks. The downside of Haskell is that none of the regular implementations (ghc, hugs) are really right for this level of student. Type inference is an especially nasty problem. There also a number of gotcha's lurking in the language that cause problems. But even so with a little supervision everything works quite well. I think fundamentals of computing as found in Haskell are good for a general mathematics class as opposed to a computer class where you have to deal with curriculum defined by the AP test or intertwined with some specific software environment. John ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Global variables?
Richard Uhtenwoldt [EMAIL PROTECTED] wrote: snip I do not think it is nice: I do not like any of the solutions Hughes considers in that paper because this problem can be handled much more simply with lexical scope and the IO monad. can be /= should be Just to get our bearings, let us first consider the solution that uses unsafePerformIO, which neither Hughes nor I prefer: globalVar :: IORef Int globalVar = unsafePerformIO $ newIORef 0 foo = fff aaa bbb ccc bar = ggg xxx yyy zzz main = mmm nnn ooo where the lines foo = fff aaa bbb ccc bar = ggg xxx yyy zzz stand in for a typically much larger chunk of code --the bulk of the program, let us call it. I, personally, haven't written a program whose bulk will fit in a single file in several years, and I doubt I ever will again. So, support for separate compilation is a necessity. How do you intend to handle this? snip Jon Cast ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Concurrent-Haskell in GHC
Hi guys! I'm considering doing a server project in Haskell, using GHC, and I'm having the old dilema of trying to figure out the best way of handling multiple concurrent connections: multiplexing or multithreading. I've started looking into the docs on GHC's implementation of Concurrent-Haskell, and I got confused about the architecture. Different sources seem to indicate that it either: - Uses one OS thread, and blocking IO calls will therefore block all the Haskell-threads, or - Uses one OS thread, occasionaly (50 times a second?) calling select() to simulate blocking IO calls without blocking other Haskell-threads, or - Uses a pool of OS threads so that when a blocking IO call is made, another thread takes over execution. So which is right for the current stable GHC? And how efficient/scalable is it? Thanks, -Jony __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
