Re: [Haskell-cafe] IDE?
On Mon, Jun 18, 2007 at 12:23:52PM +0800, Michael T. Richter wrote: I'm using Emacs. It gives me a text window, like any other editor window (except where it's different) when I go to the horribly kludgy, not-at-all-integrated-with-the-desktop-theme file menu. In fact it's even worse. I go File-Open File... and it gives me ... a prompt in a little command window at the bottom of the editing screen asking me for the file name. this offtopic thread is getting stale. thousands of good coders use emacs every day and are very satisfied with it. if the ui bothers you that much, initiate emacs with -nw and add these lines to your .emacs file: (if (fboundp 'scroll-bar-mode) (scroll-bar-mode -1)) (if (fboundp 'tool-bar-mode) (tool-bar-mode -1)) (if (fboundp 'menu-bar-mode) (menu-bar-mode -1)) and it will look and act like a console app. you won't be tempted to use your mouse because there will be nothing to click on. if you still don't like that, well maybe emacs is not for you. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: String Hashing
Thomas Conway wrote: I'm trying to figure out how to maximum performance out of one of my inner loops which involves string hashing. Consider the following hash function, which is a transliteration of a good one written in C: Do you need the hash function for a hash table or for fingerprints/signatures? In the former case, Tries are a much better choice. For launching your own trie, see also Ralf Hinze. Generalizing generalized tries. Journal of Functional Programming, 10(4):327-351, July 2000 http://www.informatik.uni-bonn.de/~ralf/publications/GGTries.ps.gz Currently, there's no standard Data.Trie library but it's already under consideration http://hackage.haskell.org/trac/ghc/ticket/721 Regards, apfelmus ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] yi or not to yi was: IDE?
On Sunday 17 June 2007 23:56:51 Claus Reinke wrote: i didn't know that Yi had acquired a tongue-in-cheek mode already!-) at least i hope that's what it was, because the ermacs lesson was not about contributing code or better language, but about sheer size and momentum being in favour of the weaker solution. I think that we should not underestimate the transforming power of dogged determination. Think of Linux: only a terminal idiot could have conceived the plan of writing from scratch a clone of a 20 years old operating system (Unix) when everybody knew that momentum was on the side of the weaker solution (Microsoft) in the PC market and on the many existing commercial Unix versions in the professional market. Well, we all know what that stupid idea has led to. I certainly do, as I am writing this message under Linux. Whenever we act, we do so in a context that determines the value of our actions. However, our actions also create a new context. Linux, in the context in which it was started, was an unequivocaly bad idea. However, its existence has created a new context where it has a real value. So, the idea of writing an Emacs-like system in Haskell might be ill-considered but, as you also notice in the rest of your message, that doesn't make it worthless in a long-term perspective. An even more relevant example might be Eclipse: Eclipse is very much the Java Emacs: a customisable application framework with a zillion extension. Creating it was a major effort but, thanks to that effort, Java has greatly increased its reach and credibility, in particular as a viable solution to write desktop applications. Maybe, just maybe, yi might play a similar role for Haskell. Regards, titto ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] yi or not to yi was: IDE?
On Mon, 2007-18-06 at 09:49 +0100, Pasqualino 'Titto' Assini wrote: Maybe, just maybe, yi might play a similar role for Haskell. This is what I am hoping for (and why I'm now trying to get Yi working). I just hope it doesn't become the stovepipe that emacs is. -- Michael T. Richter [EMAIL PROTECTED] (GoogleTalk: [EMAIL PROTECTED]) In his errors a man is true to type. Observe the errors and you will know the man. (孔夫子) signature.asc Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: String Hashing
On 6/18/07, apfelmus [EMAIL PROTECTED] wrote: Do you need the hash function for a hash table or for fingerprints/signatures? In the former case, Tries are a much better choice. For launching your own trie, see also I'm actually using them for bucket addressing for external indexing with a linear hash table. (Yes, the hashing does count, because buckets are cached in memory.) Actually, if one wants a concurrent dictionary, using something in the vein of type HashTable k v = TVar (Array Int (TVar [(k,v)])) has very good performance. It always seems something of a shame that if you want all the benefits of lazy functional programming, you too often have to settle for O(n log n) data structures. non-haskell-slight-rant Incidentally, while I've got your attention, I note that if you use a good quality hash function like the one I ripped off, you don't need to use [mostly] prime numbers for sizing your hash tables, and you can use powers of two instead, which simplifies a bunch of things. This is kind of obvious when you think about it, but every hash function I came across as an undergraduate or even as a post-grad, with the exception of md5 et al, was not good. The dogma was that *good* hash functions are too expensive for everyday use. So a word of advice to all you worthy tertiary educators - this is not the 1970s any more - good, cheap hash functions do exist, so update your course notes. :-) /non-haskell-slight-rant We return you now to your normal haskell programming cheers, T. -- Dr Thomas Conway [EMAIL PROTECTED] Silence is the perfectest herald of joy: I were but little happy, if I could say how much. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: Re[2]: [Haskell-cafe] IDE?
| L-System using HOpenGL), from what I've read Haskell is indeed much better than typical OO | languages... So it *deserves* an easy entry level IDE that will get many many more people started with | it. I think you are right about that. Still, I hope this problem may in time fix itself: the Haskell community will grow to the point where there enough people like you who *want* such an IDE, that among their ranks will be some who feel able to *build* it. (I quite understand that you do not.) The Haskell community has historically been somewhat oriented towards emacs and Unix, but if Haskell is to succeed in becoming more of a mainstream language, it need to jump the cultural gap over to the (much larger) IDE and Windows community. Presumably Visual Studio or Eclipse are the right places to start, and there are prototype Haskell IDEs for both, even if they are not ready for production use. plenty of opportunities here! Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] yi or not to yi was: IDE?
I think that we should not underestimate the transforming power of dogged determination. .. So, the idea of writing an Emacs-like system in Haskell might be ill-considered but, as you also notice in the rest of your message, that doesn't make it worthless in a long-term perspective. indeed. i was just asking whether you are aware of the odds. but as long as you are, it is nice to see such enthusiasm!-) claus ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] IDE? (and WHY I'm looking at Haskell)
Thanks for the nice info. I'm going to give it another try then... When I said I don't want to learn Emacs, I meant not learning its LISP architecture with the goal of creating my own custom Emacs... OT: The reasons I'm looking at Haskell are: - the object oriented approach failed for me when working on large projects in medium to large teams. OO works reasonably if you have a good design and follow some rules, but no language enforces those rules (yet), so aliasing and unwanted side effects leak all over and you spend a lot of time debugging. - I noticed I was using the immutable pattern a lot for solving problems lately... So I got steered automatically towards the FP world, which is immutable by definition. That is, excluding the IO world I guess, but as far as I understand, monadic IO is also pure, in the sense it has no aliasing, unless using unsafePerformIO. But since I'm a Haskell newbie, I'm not going to claim I understand monads! ;-) - After 20 years of hitting keyboards like a madman to reach yet another crazy deadline, I got myself RSI in both arms (Workrave helps, but it's too late :\) So I want to spend more time thinking than typing, and I certainly don't want to type boiler plate code. But most OO languages are FULL of boiler plate code, and are much more verbose than Haskell. - A last but not least, if all goes well, I will be teaching an undergrad applied mathematics for videogame development course. This will be very basic and practical mathematics. These students love games, so I want to let then *play* with the math using a mathematical programming language. If the school approves it (which is unlikely because the students will also be learning C++ = confusing), this will most likely be very basic Haskell. Being an old school C/C++ developer, I would find it unfortunate that the students don't get to see some FP, because I believe FP can play an important part in the future of videogame and even business software development (even the giants in my industry seem to believe that in some degree: see e.g. http://blogs.msdn.com/charlie/archive/2007/01/26/anders-hejlsberg-on-linq-an d-functional-programming.aspx and http://www.st.cs.uni-sb.de/edu/seminare/2005/advanced-fp/docs/sweeny.pdf) So, if I decide to use Haskell, I want my students to get playing right away using a nice IDE, because the young videogame generation is even more spoiled and impatient than I am :) Peter V No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.472 / Virus Database: 269.9.0/852 - Release Date: 17/06/2007 08:23 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: Re[2]: [Haskell-cafe] IDE?
Well, if I was 15 again and had no RSI in both arms, I certainly would create a basic IDE as my first Haskell project, it would be fun ;) I've looked at the code of Visual Haskell, but I'm not (yet/ever?) capable of enhancing it (the Haskell part, the COM/C++ part is a lot easier for me). So it's a bit of a chicken and egg problem. To adapt existing code for getting a better editor, I need to learn Haskell. To really learn Haskell, I need to start typing and doing concrete projects, but I want to type as less as possible, so I need a good IDE. Furthermore, because of my RSI, I see my future in teaching and not coding. And it will remain a hobby project, because I'm not able to convince my colleagues to switch to Haskell, mostly because it has no production-stable .NET backend and Visual Studio integration (yet, I know its work in progress) Anyway, I'll start with emacs again, maybe I see the light this time ;) Peter -Original Message- From: Simon Peyton-Jones [mailto:[EMAIL PROTECTED] Sent: Monday, June 18, 2007 11:46 To: Peter Verswyvelen; haskell-cafe@haskell.org Subject: RE: Re[2]: [Haskell-cafe] IDE? | L-System using HOpenGL), from what I've read Haskell is indeed much better than typical OO | languages... So it *deserves* an easy entry level IDE that will get many many more people started with | it. I think you are right about that. Still, I hope this problem may in time fix itself: the Haskell community will grow to the point where there enough people like you who *want* such an IDE, that among their ranks will be some who feel able to *build* it. (I quite understand that you do not.) The Haskell community has historically been somewhat oriented towards emacs and Unix, but if Haskell is to succeed in becoming more of a mainstream language, it need to jump the cultural gap over to the (much larger) IDE and Windows community. Presumably Visual Studio or Eclipse are the right places to start, and there are prototype Haskell IDEs for both, even if they are not ready for production use. plenty of opportunities here! Simon No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.472 / Virus Database: 269.9.0/852 - Release Date: 17/06/2007 08:23 No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.472 / Virus Database: 269.9.0/852 - Release Date: 17/06/2007 08:23 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] IDE?
Hallo, On 6/18/07, Michael T. Richter [EMAIL PROTECTED] wrote: Screenshots are worthless if they don't match my screen, aren't they? I guess I can open up exactly the same file that's in your screenshot and then use your screenshot as a background to my screen so I have the illusion of decent fonts, but that's not exactly a productive environment now, is it? So you'd rather use my image as background instead of compiling GTK Emacs for you? I've got another idea, why don't you use MS Word? It can save plain text files. Cheers, -- -alex http://www.ventonegro.org/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Efficient signal processing
On Sun, 17 Jun 2007, Donald Bruce Stewart wrote: simonmarhaskell: Henning Thielemann wrote: The program is compiled with GHC-6.4 and option -O2, CPU clock 1.7 GHz. ByteString is much faster with GHC 6.6, IIRC. We optimised the representation of ForeignPtr, and ByteString takes advantage of that. I recommend upgrading. Yes, a 2x speedup isn't uncommon. Indeed, in my simple example the speedup factor was 2. However this is still far from being enough for real-time signal processing. I found another problem: The rounding functions from RealFrac are much slower than GHC.Float.double2Int. I've set up a bug ticket in GHC trac. ByteString is even faster with the GHC head, branch, given the cranked up rules and constructor specialisation. Can I test them without compiling GHC myself? I.e. can I still install the FPS package separately? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: String Hashing
On Mon, 2007-06-18 at 19:35 +1000, Thomas Conway wrote: On 6/18/07, apfelmus [EMAIL PROTECTED] wrote: Do you need the hash function for a hash table or for fingerprints/signatures? In the former case, Tries are a much better choice. For launching your own trie, see also I'm actually using them for bucket addressing for external indexing with a linear hash table. (Yes, the hashing does count, because buckets are cached in memory.) Actually, if one wants a concurrent dictionary, using something in the vein of type HashTable k v = TVar (Array Int (TVar [(k,v)])) has very good performance. It always seems something of a shame that if you want all the benefits of lazy functional programming, you too often have to settle for O(n log n) data structures. non-haskell-slight-rant Incidentally, while I've got your attention, I note that if you use a good quality hash function like the one I ripped off, you don't need to use [mostly] prime numbers for sizing your hash tables, and you can use powers of two instead, which simplifies a bunch of things. This is kind of obvious when you think about it, but every hash function I came across as an undergraduate or even as a post-grad, with the exception of md5 et al, was not good. The dogma was that *good* hash functions are too expensive for everyday use. So a word of advice to all you worthy tertiary educators - this is not the 1970s any more - good, cheap hash functions do exist, so update your course notes. :-) /non-haskell-slight-rant Indeed, Performance in Practice of String Hashing Functions http://citeseer.ist.psu.edu/530453.html ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Useful IDE features - implement instance
Another feature which would be cool for an IDE is: implement instance. So
you automatically get to see all the functions of a type class you need to
implement. Using C#/Java, this is used all over the place.
sounds potentially useful, but perhaps not quite as useful as one might
expect: if you only want to see all the class methods, hugs/ghci provide
the ':info' command (and haskell modes tend to provide access to that).
$ ghc -e ':i Monad'
class Monad m where
(=) :: m a - (a - m b) - m b
() :: m a - m b - m b
return :: a - m a
fail :: String - m a
-- Defined in GHC.Base
instance Monad Maybe -- Defined in Data.Maybe
instance Monad IO -- Defined in GHC.IOBase
instance Monad [] -- Defined in GHC.Base
with a little bit of filtering and replacing, we get
$ ghc -e ':i Monad' | sed -n '/^class/,/-- Defined in/{s/class/instance/;p}'
instance Monad m where
(=) :: m a - (a - m b) - m b
() :: m a - m b - m b
return :: a - m a
fail :: String - m a
-- Defined in GHC.Base
i've used sed here, to keep it editor-independent, one can do the
equivalent within emacs/vim, without sed. now, if one wanted to
save typing, one might want to translate the type declarations into
definition templates, but the type has more information than such
template, and there are many forms of definition that fit a type, so
having to replace the type declarations with definitions is perhaps
as good as it gets?
a similarly useful code template generation transformation would
be to introduce complete case distinctions over sum types, so that
f x = undefined
would, if we knew (x::Maybe a), become
f (Just a) = undefined
f Nothing = undefined
or 'doSomething = \(x::Either l r)-body' would become
doSomething = \x-case x of {Left l-body; Right r-body}
which, of course, should rather be
doSomething = either (\l-body) (\r-body)
yes, there are many opportunities for making haskell editing
easier, and not all of them require detailed editor hacking or
haskell analysis and transformation skills (though some do).
keep the suggestions coming. perhaps summarize them on a
haskell.org wiki page, though, so they don't get lost. someone
might get round to implementing them, some of them might
already be available!-)
if someone were to put up a simple table/list of desired ide
features (with brief descriptions) on the wiki, everyone could
add links to each feature showing how their favourite ide
handles said feature.
then new users could go through that list and choose to learn
one of those ides that provides most of the features they need.
and fans of a particular ide could use the list to pick any
missing feature that they feel able to implement..
claus
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Useful IDE features - Accessibility considerations
Hi not sure if this is a real project to build a Haskell IDE ... adherence to the MS accessibility guidelines. Ironically the VS environement seems to deviate from the corporation's own advice to the rest of the world. Paul ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] IDE?
peterv wrote:
I just tried the Haskell Mode using xemacs, adjust my init.el file, loaded
my haskell file, and got great syntax highlighting! So far so good.
But people, emacs is so weird for a Windows user...
Well you're certainly quite right to observe that emacs keys are rather
different from the standard windows keys. Of course many of the emacs
keybindings were put into place long before the mac-windows key
standards started to emerge.
Then there is the different region behaviour (a region is not quite a
selection, etc etc).
You can choose to try to rebind these various things closer to windows
defaults, and some projects out there try to do this for. However to be
honest I'm not convinced this is the right way to go, because to really
use the power of emacs, you want to use various of the powerful packages
('plugins') that people have written, and they probably have keybindings
which behave like the standard ones.
But it is actually worth spending some time working out if it's the
right editor for you; because there are things about it which blow the
socks of most other packages.
To pick a couple of examples at random: having a kill-ring which stores
your last 60 copies/cuts is so much more powerful than merely having a
clipboard, and it really changes the way you can work; the amazing
'paredit-mode' which keeps your code syntactically correct at all times
by automatically balancing brackets and , and gives you high-level
syntactical commands to move or delete chunks of syntactically
wellformed code makes code entry + modification faster and safer.
Jules
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Useful IDE features - Accessibility considerations
Well, yes and no. Such an IDE does not have to follow the guidelines, because as you said, these are “flexible”. Take Microsoft Office 2007, completely new GUI, shocked the world. But take Eclipse. This is a fairly standard GUI, mostly the same on unix, mac, and Windows. IMHO, for a Windows user coming from Visual Basic, Visual Studio, Borland Delphi, etc, switching to Eclipse is much easier than switching to emacs. Or take the Concurrent Clean IDE. Totally not a windows GUI. But easy to get started with. Just install, open an example, select run and off you go. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of PR Stanley Sent: Monday, June 18, 2007 15:06 To: haskell-cafe@haskell.org Subject: Re: [Haskell-cafe] Useful IDE features - Accessibility considerations Hi not sure if this is a real project to build a Haskell IDE ... adherence to the MS accessibility guidelines. Ironically the VS environement seems to deviate from the corporation's own advice to the rest of the world. Paul No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.472 / Virus Database: 269.9.0/852 - Release Date: 17/06/2007 08:23 No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.472 / Virus Database: 269.9.0/852 - Release Date: 17/06/2007 08:23 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] drscheme as haskell IDE?
Hi, I see that drscheme has support for various dialects of lisps. It also supports algol! is it possible to add support for haskell in drscheme? or is there any IDE like drscheme for haskell? == Vikrant ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Useful IDE features - implement instance
That looks cool.
Just another wild idea which I might find useful, but is more like
refactoring, is to convert the fields of a record to get/set type-classes,
and refactor all usages of those fields.
So
---
data Person = Person { name :: String, age :: Float }
main = print $ name p ++ is ++ show (age p) ++ years old
where p = Person { name = Homer, age = 41 }
---
Would refactor into (just wild Haskell code from a newbie here)
---
data Person = Person String Float
class HasName a where
nameOf :: a - String
withName :: a - String - a
class HasAge a where
ageOf :: a - Float
withAge :: a - Float - a
instance HasName Person where
nameOf (Person name age) = name
withName (Person name age) newName = Person newName age
instance HasAge Person where
ageOf (Person name age) = age
withAge (Person name age) newAge = Person name newAge
defaultPerson = Person 0
---
main = print $ nameOf p ++ is ++ show(ageOf p) ++ years old
where p = defaultPerson `withName` Homer `withAge` 41
-- or just where p = Person Homer 41
---
Visual Studio, Eclipse, IntelliJ etc already have these kind of wizards to
encapsulate fields with setters getters for C#/Java, and also introduce
boiler plate code, although less of it. However, Haskell turns each field
into a separate type class, so this is much more reusable code than their OO
counterparts.
Peter
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Claus Reinke
Sent: Monday, June 18, 2007 14:24
To: haskell-cafe@haskell.org
Subject: Re: [Haskell-cafe] Useful IDE features - implement instance
Another feature which would be cool for an IDE is: implement instance.
So
you automatically get to see all the functions of a type class you need to
implement. Using C#/Java, this is used all over the place.
sounds potentially useful, but perhaps not quite as useful as one might
expect: if you only want to see all the class methods, hugs/ghci provide
the ':info' command (and haskell modes tend to provide access to that).
$ ghc -e ':i Monad'
class Monad m where
(=) :: m a - (a - m b) - m b
() :: m a - m b - m b
return :: a - m a
fail :: String - m a
-- Defined in GHC.Base
instance Monad Maybe -- Defined in Data.Maybe
instance Monad IO -- Defined in GHC.IOBase
instance Monad [] -- Defined in GHC.Base
with a little bit of filtering and replacing, we get
$ ghc -e ':i Monad' | sed -n '/^class/,/-- Defined
in/{s/class/instance/;p}'
instance Monad m where
(=) :: m a - (a - m b) - m b
() :: m a - m b - m b
return :: a - m a
fail :: String - m a
-- Defined in GHC.Base
i've used sed here, to keep it editor-independent, one can do the
equivalent within emacs/vim, without sed. now, if one wanted to
save typing, one might want to translate the type declarations into
definition templates, but the type has more information than such
template, and there are many forms of definition that fit a type, so
having to replace the type declarations with definitions is perhaps
as good as it gets?
a similarly useful code template generation transformation would
be to introduce complete case distinctions over sum types, so that
f x = undefined
would, if we knew (x::Maybe a), become
f (Just a) = undefined
f Nothing = undefined
or 'doSomething = \(x::Either l r)-body' would become
doSomething = \x-case x of {Left l-body; Right r-body}
which, of course, should rather be
doSomething = either (\l-body) (\r-body)
yes, there are many opportunities for making haskell editing
easier, and not all of them require detailed editor hacking or
haskell analysis and transformation skills (though some do).
keep the suggestions coming. perhaps summarize them on a
haskell.org wiki page, though, so they don't get lost. someone
might get round to implementing them, some of them might
already be available!-)
if someone were to put up a simple table/list of desired ide
features (with brief descriptions) on the wiki, everyone could
add links to each feature showing how their favourite ide
handles said feature.
then new users could go through that list and choose to learn
one of those ides that provides most of the features they need.
and fans of a particular ide could use the list to pick any
missing feature that they feel able to implement..
claus
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.472 / Virus Database: 269.9.0/852 - Release Date: 17/06/2007
08:23
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.472 / Virus Database: 269.9.0/852 - Release Date: 17/06/2007
08:23
Re: [Haskell-cafe] To yi or not to yi, is this really the question? A plea for a cooperative, ubiquitous, distributed integrated development system.
On 6/18/07, Pasqualino 'Titto' Assini [EMAIL PROTECTED] wrote: Having just presented a case for the possible rationality of the irrational decision of creating an Emacs-like IDE in Haskell, I wonder if we should not be even more irrational and contemplate the possibility of using Haskell to create a radically different kind of IDE. [...] Up to you now, what is your dream? I just did a quick read through of your dream and I'm not going to say either way with it. But I would like to point out, just to make sure you've considered it, that my dream--or maybe my reality--involves being able to code without the requirement of a network connection. Bryan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Haskell mode for emacs - some questions
I finally got emacs using Haskell-mode working. It seems that the latest version of emacs support nice font smoothing on Windows; the last time I looked it didn't. Auto indent works, inf-haskell works, really great. So far so good. But I have some questions I did not find in the wiki: - How can I just compile and run in one go without having to type ghc --make main.hs as arguments for the compile... command and then typing main.exe for shell command...? This is what you do all the time when using Visual Studio, Eclipse, etc: just hit the F5 key which builds all the dependencies and runs one or more generated executables. Easy. Visual Haskell does this (in the cases it does not hang for some unknown reason). Of course I could dig into ELISP, but somehow I feel this must be supported somehow. - There seems to be support for Haskell Font Lock Symbols, which should convert \, - and maybe other symbols to good looking Unicode fonts. I can't get the correct fonts working on Windows. Now as I understood this is not really supported because of indentation problems, as underneed the single Unicode arrow character is converted into -? This is unfortunate, because that's one of the things I really like about Sun's Fortress: the usage of Unicode symbols makes the text look much more mathematically, versus the half-century-old ASCII text. Furthermore in almost all Haskell books the richer font symbols are used for clarity. Any hints on this topic? Thanks again! Peter No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.472 / Virus Database: 269.9.0/852 - Release Date: 17/06/2007 08:23 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Building Yi (and wider Cabal stuff)
On Sunday 17 June 2007 08:26:45 Michael T. Richter wrote: I'm trying to build Yi (from the darcs repository) to take a look at it. The README that comes with it says it's a standard Cabal project so do what you normally do (paraphrased slightly). GNU autotools comes with a standard boilerplate INSTALL file to include with your projects. There is some command you run in the process of autoconfiscation that inserts it automatically. Maybe there should be a standard boilerplate INSTALL file to be included with Cabal packages. Yesterday, I wrote and uploaded a simple Cabal package called csv (mostly as an exercise, since it's only a screenful of code, really, but it is actually a somewhat useful library because it saves you the trouble of reading an RFC). I included the following INSTALL file: To install the package, use the standard Cabal incantations: runhaskell Setup.hs configure runhaskell Setup.hs build runhaskell Setup.hs install If you want to install into a nonstandard directory, do runhaskell Setup.hs configure --prefix /bla/di/bla If you want documentation, try runhaskell Setup.hs haddock I think that simply adding those instructions would probably lower the hurdle a bit. Maybe the Cabal could look into automatically inserting an instructions file like that if it doesn't exist yet. Another idea for making things more accessible is to include a shell script called configure and a Makefile called Makefile, both of which just print the above instructions when executed. /jaap ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] IDE?
On Mon, 18 Jun 2007, Jon Harrop wrote: I don't normally drag threads back on topic, but functional reactive GUIs seem to be pioneered by Haskell programmers. Can anyone explain what this idea is all about? Since I haven't seen any replies so far, could you give us a hint? I've seen some stuff that uses arrows, and then there's O'Haskell, were you looking at either of those? Something else in this category that isn't so past tense? I'm just getting acquainted with GUI programming using LablGTK in OCaml and Windows Forms in F#, so I know next to nothing about GUI programming. In particular, I'm interested in developing GUIs for languages like these. More specifically, a variation of Mathematica's notebook front-end, designed to make functional languages more accessible and useful for scientists and engineers. Donn Cave, [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] To yi or not to yi, is this really the question? A plea for a cooperative, ubiquitous, distributed integrated development system.
Having just presented a case for the possible rationality of the irrational decision of creating an Emacs-like IDE in Haskell, I wonder if we should not be even more irrational and contemplate the possibility of using Haskell to create a radically different kind of IDE.. New technologies are often used to imitate and reimplement the artefacts of previous technologies. don't underestimate those previous technologies, though. given your outline, you're almost certain to find this interesting: Croquet is a powerful open source software development environment for the creation and large-scale distributed deployment of multi-user virtual 3D applications and metaverses that are (1) persistent (2) deeply collaborative, (3) interconnected and (4) interoperable. The Croquet architecture supports synchronous communication, collaboration, resource sharing and computation among large numbers of users on multiple platforms and multiple devices. http://croquetconsortium.org the screenshots can be misleading in their simplicity, so be sure to browse some of the papers referenced on the 'about' page in the technology section http://croquetconsortium.org/index.php/About_the_Technology Up to you now, what is your dream? if you look closely, you'll see that croquet is implemented in squeak, which in turn is a re-implementation of one of the ancient smalltalks. squeak is by no means the ideal implementation language for this kind of project, nor am i completely convinced by the synchronous approach used for croquet. but while implementation of croquet in squeak is obviously doable, i see various difficulties for doing the same in haskell. where squeak is too dynamic/imperative/flexible, haskell is too static/unreflective/limited (ever tried to pass functions through haskell's i/o interface? type Dynamic and dynamic loading are still outside the language definition [hs-plugins], as are distribution [gdh], persistence [many starts, no finish, but see Clean's first class i/o], reflection/meta-programming [Data/Typeable, template haskell..; meta ml?]). one dream would be successors to haskell and croquet so that croquet' could be implemented in haskell''. claus ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] IDE?
David House wrote: Andrew Coppin writes: The only ones I managed to actually edit files with are Nano and Pico. But given the choice, I'd *much* rather use KWrite. (Or Kate if I really have to.) Despite it exhibing virtually none of your own aforementioned IDE features? KWrite and/or Kate are almost always installed when you play with somebody's Linux box. Emacs virtually never is. Emacs may be hard to get used to, but its power makes it worth it. Give it a fair try over a weekend or so, count the experience as gaining a life skill. I've heard a lot of people say that learning Lisp will make you a better programmer forever. Personally, I think Lisp is an ugly language... Much prefer Haskell. ;-) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] yi or not to yi was: IDE?
Pasqualino 'Titto' Assini wrote: I think that we should not underestimate the transforming power of dogged determination. Think of Linux: only a terminal idiot could have conceived the plan of writing from scratch a clone of a 20 years old operating system (Unix) when everybody knew that momentum was on the side of the weaker solution (Microsoft) in the PC market and on the many existing commercial Unix versions in the professional market. Well, we all know what that stupid idea has led to. I certainly do, as I am writing this message under Linux. That reminds me... Somebody should write an *OS* in Haskell! :-D If that happened, then maybe at last I'd be able to have a choice other than M$ Windows (with all it's well-documented faults), and Unix (with its legendary unfriendliness and unecessary complexity). OTOH... how the heck do you write an operating system in a language that doesn't even support I/O? :-S ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] yi or not to yi was: IDE?
Hallo, On 6/18/07, Andrew Coppin [EMAIL PROTECTED] wrote: OTOH... how the heck do you write an operating system in a language that doesn't even support I/O? :-S You can start from here: http://programatica.cs.pdx.edu/House/ Cheers, -- -alex http://www.ventonegro.org/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] yi or not to yi was: IDE?
On 6/18/07, Andrew Coppin [EMAIL PROTECTED] wrote: Pasqualino 'Titto' Assini wrote: I think that we should not underestimate the transforming power of dogged determination. Think of Linux: only a terminal idiot could have conceived the plan of writing from scratch a clone of a 20 years old operating system (Unix) when everybody knew that momentum was on the side of the weaker solution (Microsoft) in the PC market and on the many existing commercial Unix versions in the professional market. Well, we all know what that stupid idea has led to. I certainly do, as I am writing this message under Linux. That reminds me... Somebody should write an *OS* in Haskell! :-D If that happened, then maybe at last I'd be able to have a choice other than M$ Windows (with all it's well-documented faults), and Unix (with its legendary unfriendliness and unecessary complexity). OTOH... how the heck do you write an operating system in a language that doesn't even support I/O? :-S Well, there hasn't been a lot of work done on the subject but you probably should look at http://programatica.cs.pdx.edu/House/ Now if you're seriously asking how one would do it, the basic approach taken in the paper was to create a monad H that was a controlled subset of IO that did all the fundamental interactions with the the hardware. The operations of H, as with IO, have to be primitives in the runtime that you're using and probably written in C or assembly. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] IDE?
Mark T.B. Carroll wrote: Andrew Coppin [EMAIL PROTECTED] writes: (snip) KWrite and/or Kate are almost always installed when you play with somebody's Linux box. Emacs virtually never is. (snip) H. Exactly the opposite seems to be true on mine. (-: Really? Mmm... perhaps it's distro-specific or something. *shrugs* ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: String Hashing
Thomas Conway wrote:
On 6/18/07, apfelmus [EMAIL PROTECTED] wrote:
Do you need the hash function for a hash table or for
fingerprints/signatures? In the former case, Tries are a much better
choice. For launching your own trie, see also
I'm actually using them for bucket addressing for external indexing
with a linear hash table. (Yes, the hashing does count, because
buckets are cached in memory.)
It always seems something of a shame that
if you want all the benefits of lazy functional programming, you too
often have to settle for O(n log n) data structures.
Trie it is,
not balanced tree.
A logarithm in this
would be new to me. :)
As a side node, Mr. Exp says: 64 is large enough for the size needs of
any logarithm.
type HashTable k v = TVar (Array Int (TVar [(k,v)]))
Don't you want a TArray Int [(k,v)]?
In any case, you could be able to set up an infinite trie and have lazy
evaluation allocate space as needed:
type Trie a = Branch (TVar a) (Trie a) (Trie a)
-- an infinite tree with different TVars at every branch
{-# NOINLINE tree -#}
tree :: a - Trie a
tree x = Binary (unsafePerformIO $ newTVarIO x) (tree x) (tree x)
The intention is that the different threads concurrently evaluate the
suspension as far as they need to lookup/insert a key. The associated
value can be put into the fresh TVar they find there. The tree structure
itself is left untouched. Of course, it is imperative that all threads
see the same TVars. I don't know how thunk updates are handled in a
concurrent setting, but as they are write-once only and referentially
transparent, i see no major problem with them.
Regards,
apfelmus
PS: Hm, it's probably safer to code the lazy evaluation in the trie
manually. As a side effect, you are then able to garbage collect unused
but expanded parts of the trie from time to time.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] IDE?
Mark T.B. Carroll wrote: Are KWrite and Kate something to do with KDE or something? One of the first things I do with a new Linux install is to dump all the KDE and Gnome stuff on the basis that it's an enormous amount of bloatware for little gain. Others may think differently! (-: Yeah, that'll be it then. ;-) Gnome and KDE are both rather bloated... Unfortunately, nothing better exists. :-( But then, the entire Linux world is too messy for me... hence my request for a petter OS. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] IDE?
On 6/18/07, Andrew Coppin [EMAIL PROTECTED] wrote: Mark T.B. Carroll wrote: Are KWrite and Kate something to do with KDE or something? One of the first things I do with a new Linux install is to dump all the KDE and Gnome stuff on the basis that it's an enormous amount of bloatware for little gain. Others may think differently! (-: Yeah, that'll be it then. ;-) Gnome and KDE are both rather bloated... Unfortunately, nothing better exists. :-( But then, the entire Linux world is too messy for me... hence my request for a petter OS. Well, since we're on the subject and it's only the Cafe list, what is it that you find messy about Linux that you would want to be solved by some hypothetical Haskell OS? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] IDE?
On Monday 18 June 2007 17:36:25 Donn Cave wrote: On Mon, 18 Jun 2007, Jon Harrop wrote: I don't normally drag threads back on topic, but functional reactive GUIs seem to be pioneered by Haskell programmers. Can anyone explain what this idea is all about? Since I haven't seen any replies so far, could you give us a hint? Chris King's work in OCaml got me interested: http://lambda-the-ultimate.org/node/1918 and I quickly discovered that similar sounding things are being worked on in the Haskell world: http://www.haskell.org/frp/ I've seen some stuff that uses arrows, and then there's O'Haskell, I think arrows are very relevant and OOP is not. were you looking at either of those? Something else in this category that isn't so past tense? I hadn't noticed that these were done many years ago: http://haskell.org/yampa/ but I'm still clueless as to what this is all about. What problems is this trying to solve? How well did it work? What is modern style for GUI programming in Haskell? -- Dr Jon D Harrop, Flying Frog Consultancy Ltd. OCaml for Scientists http://www.ffconsultancy.com/products/ocaml_for_scientists/?e ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] IDE?
Creighton Hogg wrote: Well, since we're on the subject and it's only the Cafe list, what is it that you find messy about Linux that you would want to be solved by some hypothetical Haskell OS? This is drifting off-topic again, but here goes... There are lots of things to like about Linux. It doesn't cost money. It's fast. It's reliable. It's flexible. It's secure. However, unfortunately it's still Unix. In other words, it's a vast incoherant mess of largely incompatible ad-hoc solutions to individual problems implemented independently by unrelated hackers over the 40+ years of history that this software has been around. New software has to emulate quirks in old software, and client programs work around the emulated quirks in the new software to get the functionallity it actually wants. One vast tangled mess of complexity and disorder. Exhibit A: Package managers exist. Exhibit B: Autoconf exists. I rest my case. An operating system should have a simple, clear, consistent design. Not unlike a certain programming language named after a dead mathematition, come to think of it... (Have you ever programmed in C? You can certainly see where Unix gets its features from - terse, cryptic and messy.) Still, I don't have the skill to write a functioning operating system - much less one that's ready for the desktop - so that's that I suppose... (I did seriously investigate the task once. Indeed, I got as far as writing a bootloader. It worked too!) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] yi or not to yi was: IDE?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andrew Coppin wrote: OTOH... how the heck do you write an operating system in a language that doesn't even support I/O? :-S Back when I was first learning programming, with C, I had that exact same question: how the heck can your program DO anything, when the language consists of a bunch of functions that are executed that can only modify meaningless variables your program defines? (C standard defines modifications to volatile variables as side-effects, actually.) It's because your environment knows how to call into the kernel, the kernel knows how to make you computer do things - and that usually involves a bit of assembly, because the C language doesn't define non-program-logic for the compiler to translate. Source-language extensions to C allow inline assembly (and much more), so I'm sure something appropriate could be done for Haskell if that was judged as the best approach. Isaac -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGduIWHgcxvIWYTTURAoRQAKC6vOw01VfwaPJavhcL5YV+lKlHagCdHUjB guyrL0QcQUTfHG8PW91Wm+Q= =2Xeu -END PGP SIGNATURE- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] yi or not to yi was: IDE?
Creighton Hogg wrote: On 6/18/07, *Andrew Coppin* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: That reminds me... Somebody should write an *OS* in Haskell! :-D Well, there hasn't been a lot of work done on the subject but you probably should look at http://programatica.cs.pdx.edu/House/ Now if you're seriously asking how one would do it, the basic approach taken in the paper was to create a monad H that was a controlled subset of IO that did all the fundamental interactions with the the hardware. The operations of H, as with IO, have to be primitives in the runtime that you're using and probably written in C or assembly. I read about House once. It seemed too far-out to be true. OTOH, it's only a proof-of-concept system. I doubt it will ever become a real, usable system, sadly. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] yi or not to yi was: IDE?
On 6/18/07, Andrew Coppin [EMAIL PROTECTED] wrote: Creighton Hogg wrote: On 6/18/07, *Andrew Coppin* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: That reminds me... Somebody should write an *OS* in Haskell! :-D Well, there hasn't been a lot of work done on the subject but you probably should look at http://programatica.cs.pdx.edu/House/ Now if you're seriously asking how one would do it, the basic approach taken in the paper was to create a monad H that was a controlled subset of IO that did all the fundamental interactions with the the hardware. The operations of H, as with IO, have to be primitives in the runtime that you're using and probably written in C or assembly. I read about House once. It seemed too far-out to be true. OTOH, it's only a proof-of-concept system. I doubt it will ever become a real, usable system, sadly. Well if no one works on it, that's kind of a given. :-P But more seriously, what seems so far out about it? I'm curious. Also, if this thread of operating systems functional programming isn't interesting to other people then we should probably just take it to e-mail not the list. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] IDE?
On Monday 18 June 2007, Jon Harrop wrote: On Monday 18 June 2007 05:39:21 Derek Elkins wrote: Not directed at Michael Richter specifically: I don't normally say this stuff, but this discussion has drifted onto topics that have nothing to do with Haskell. I personally would like the parts unrelated to Haskell to be carried on off the list. I don't normally drag threads back on topic, but functional reactive GUIs seem to be pioneered by Haskell programmers. Can anyone explain what this idea is all about? I'm certainly no expert on FRP, having only read a few papers and never really used such a framework, so take what I say with a grain of salt. However, it seems to me that the main idea behind it is that you should build your GUI (or your robot controller, or whatever) by specifying relationships between various elements, rather than thinking about events and imperative happenings in your program. For instance, say you want to have a button and a label, and have the label display how many times the button's been clicked. In an average imperative toolkit these days, you might do that something like: gui = do b - newButton l - newLabel addClickCallback (updateLabel l) b ... where updateLabel l = do x - getValue l setValue (x+1) l So, you have all your individual GUI components, and you install callbacks for the events you want to know about, and mutate the state of the components accordingly. Now in FRP, you'd instead want to (in some sense) specify the relationship between the label and the button, rather than writing some low-level event-based code that results in such a relationship (I suppose it's a bit like the difference between using triggers and referrential integrity constriants in a relational database). However, when you do this, you want to move away from the view of GUI components as imperative objects with hidden state and such. So you instead think of them, abstractly, as functions Time - Value, or as streams of Values, or something like that. For the example above, you might have: type Label = Time - Int type Button = Time - Maybe () Where a label has a value at any time, and at any time, a button is either being clicked (Just ()) or it isn't (Nothing). Now, your FRP toolkit should provide you with combinators so that you can do soemthing like: label = count button Where count takes a stream of pulses and produces a stream of values corresponding to a running count of the number of pulses. Or, I suppose in the robot world, you might have something that tracks your velocity, and you'd be able to write: position = integral velocity The point being that it's much easier to figure out and write down the relationships you want between various components in your program, and build them compositionally out of various combinators, than it is to write imperative, event-driven code and polling and whatnot. At least, that's the impression I got when I read about it. I could be off. I hope that illuminates things a bit, and isn't too vague. -- Dan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] OS design FP aesthetics
On 6/18/07, Andrew Coppin [EMAIL PROTECTED] wrote: Creighton Hogg wrote: Well, since we're on the subject and it's only the Cafe list, what is it that you find messy about Linux that you would want to be solved by some hypothetical Haskell OS? This is drifting off-topic again, but here goes... Yeah, so I'll just split this off into a different thread. There are lots of things to like about Linux. It doesn't cost money. It's fast. It's reliable. It's flexible. It's secure. Okay, I'm not sure if I'd agree with the reliable secure points. I mean, relative to what could be done. I'm a rank amateur when it comes to OS work but when I've looked at recent papers Linux really isn't that cutting edge. I mean, it may be reliable in comparison to Windows 98 has less known exploits than any Windows system, but in terms of how good it *could* be I think there's an awful lot of room for growth. However, unfortunately it's still Unix. In other words, it's a vast incoherant mess of largely incompatible ad-hoc solutions to individual problems implemented independently by unrelated hackers over the 40+ years of history that this software has been around. New software has to emulate quirks in old software, and client programs work around the emulated quirks in the new software to get the functionallity it actually wants. One vast tangled mess of complexity and disorder. Exhibit A: Package managers exist. Exhibit B: Autoconf exists. I rest my case. Okay, but these don't seem to really be design flaws so much as the inevitable results of age and the need for backwards compatibility. I'm looking more for technical problems that you would want to see fixed in our magical UberOS. An operating system should have a simple, clear, consistent design. Not unlike a certain programming language named after a dead mathematition, come to think of it... (Have you ever programmed in C? You can certainly see where Unix gets its features from - terse, cryptic and messy.) This is another thing we're just going to disagree on. I think C++ is a pretty messy language, but feel that straight up C is rather simple and elegant. I had only used C++ before, but a friend rather easily convinced me that C is in fact a very sexy language when used in its intended design space. Still, I don't have the skill to write a functioning operating system - much less one that's ready for the desktop - so that's that I suppose... (I did seriously investigate the task once. Indeed, I got as far as writing a bootloader. It worked too!) Would you mind sharing the code? I'd be interested. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Can't build Lambdabot
On Mon, Jun 18, 2007 at 05:07:19PM +0200, Daniel Fischer wrote: Plugin.hs:46:7: Could not find module `Text.Regex': it is a member of package regex-compat-0.71, which is hidden which would be easy to fix if regex-compat-0.71 WERE hidden, bu it's NOT, it's definitely exposed. You need to list it in the build-depends field in the .cabal file. Thanks Ian ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] To yi or not to yi, is this really the question? A plea for a cooperative, ubiquitous, distributed integrated development system.
Hi Claus, On Monday 18 June 2007 18:14:58 Claus Reinke wrote: Having just presented a case for the possible rationality of the irrational decision of creating an Emacs-like IDE in Haskell, I wonder if we should not be even more irrational and contemplate the possibility of using Haskell to create a radically different kind of IDE.. New technologies are often used to imitate and reimplement the artefacts of previous technologies. don't underestimate those previous technologies, though. given your you're almost certain to find this interesting: Croquet is a powerful open source software development environment Thanks for the reference. I actually knew about Croquet but I thought of it mostly as an open-source second life because of its emphasys on shared 3D worlds but you are quite right, it might also be useful for cooperative software development. I must admit that my dream doesn't go so far, I was more thinking about Web/Web services kind of technology to integrate distributed traditional development text-based tools (editors, compilers, etc.) plus a configurable Web based UI. if you look closely, you'll see that croquet is implemented in squeak, which in turn is a re-implementation of one of the ancient smalltalks. squeak is by no means the ideal implementation language for this kind of project, nor am i completely convinced by the synchronous approach used for croquet. but while implementation of croquet in squeak is obviously doable, i see various difficulties for doing the same in haskell. where squeak is too dynamic/imperative/flexible, haskell is too static/unreflective/limited (ever tried to pass functions through haskell's i/o interface? Is this really a limitation of the language proper or just of its implementations? Is there any fundamental reasons why Haskell functions/closures cannot be serialised? I believe that this is precisely what the distributed version of GHC used to do. Most languages, even Java, have a reflection capability to dynamically inspect an object. It is surprising that Haskell doesn't offer it. ... persistence [many starts, no finish Have you checked the prevayler-inspired approach implemented in HAppS ? , but see Clean's first class i/o] What advantages does it provide? reflection/meta-programming [Data/Typeable, template haskell..; meta ml?]). one dream would be successors to haskell and croquet so that croquet' could be implemented in haskell''. Is just the lack of reflection in Haskell that you miss? Or there are other things as well? best, titto ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Can't build Lambdabot
On 6/18/07, Ian Lynagh [EMAIL PROTECTED] wrote: On Mon, Jun 18, 2007 at 05:07:19PM +0200, Daniel Fischer wrote: Plugin.hs:46:7: Could not find module `Text.Regex': it is a member of package regex-compat-0.71, which is hidden which would be easy to fix if regex-compat-0.71 WERE hidden, bu it's NOT, it's definitely exposed. You need to list it in the build-depends field in the .cabal file. Is it possible for cabal to catch this mistake and report a different error? I've bumped into it before as well and found the error message to be enough misleading that I went down the wrong trouble shooting path. Maybe GHC should give a better diagnostic here? Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] To yi or not to yi, is this really the question? A plea for a cooperative, ubiquitous, distributed integrated development system.
On Monday 18 June 2007 16:13:02 you wrote: I just did a quick read through of your dream and I'm not going to say either way with it. But I would like to point out, just to make sure you've considered it, that my dream--or maybe my reality--involves being able to code without the requirement of a network connection. Bryan That's a very fair point. An ubiquitous IDE should also work when disconnected. Luckily, Web applications can be designed to work offline. In effect, modern AJAX based web apps already execute most of their code on the client side, going back to the server only when absolutely necessary and there are now technologies like Google Gear to efficiently store/access information locally so further reducing dependency on remote services. Best, titto ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] String Hashing
On Jun 17, 2007, at 9:55 PM, Thomas Conway wrote: Hi All, I'm trying to figure out how to maximum performance out of one of my inner loops which involves string hashing. ... mix :: Triple - Triple This looks like a version of the Bob Jenkins hash function from burtleburtle.net. I implemented the 32-bit version of this as follows: mix :: Int32 - Int32 - Int32 - (Int32 - Int32 - Int32 - a) - a mix a0 b0 c0 k0 = let mixR k a b c = (a-b-c) `xor` (c `shiftR` k) mixL k b c a = (b-c-a) `xor` (a `shiftL` k) mix3 k1 k2 k3 k a b c = let a' = mixR k1 a b c b' = mixL k2 b c a' c' = mixR k3 c a' b' in k a' b' c' in (mix3 13 8 13 $ mix3 12 16 5 $ mix3 3 10 15 $ k0) a0 b0 c0 I mention this because your code writes the whole thing out longhand---which might be faster, or might not, but certainly misses the highest-level structural patterns in the original. Your use of a data type to represent triples is probably better nowadays than my rather quirky use of CPS (in other words, this could have been a function Triple - Triple instead of the rather odd type you see above). That said, I assume you instrumented your code and determined that hash collisions are actually a bottleneck for you, and that a hash table is the right structure to begin with? I fell back on much- simpler multiplicative hashing schemes for Data.HashTable. A multiply is much faster than vast amounts of bit-fiddling---but of course its collision behavior isn't nearly as good and this can be a problem with large data sets. And note that the multiplicative hashing currently used in Data.HashTable doesn't require prime table sizes; in fact we use powers of two and table doubling. When last I checked the result was faster than Data.Map, but not by much, and using strings probably wipes out that advantage vs. tries. -Jan-Willem Maessen smime.p7s Description: S/MIME cryptographic signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] OS design FP aesthetics
Creighton Hogg wrote: There are lots of things to like about Linux. It doesn't cost money. It's fast. It's reliable. It's flexible. It's secure. Okay, I'm not sure if I'd agree with the reliable secure points. I mean, relative to what could be done. I'm a rank amateur when it comes to OS work but when I've looked at recent papers Linux really isn't that cutting edge. I mean, it may be reliable in comparison to Windows 98 has less known exploits than any Windows system, but in terms of how good it *could* be I think there's an awful lot of room for growth. Isn't there a lot of room for improvement in *any* product? Okay, but these don't seem to really be design flaws so much as the inevitable results of age and the need for backwards compatibility. I'm looking more for technical problems that you would want to see fixed in our magical UberOS. Technically, both Windoze and Linux work. It would just be nice to have an OS with a coherent design, that's all. Nothing revolutionary (after all, it's an OS), just something done properly. (Also, have you noticed that no large Haskell applications exist? It's very hard to convince people that Haskell is not a toy language when no large applications exist. Building an entire *OS* with it would rather satisfy that requirement...!) (Have you ever programmed in C? You can certainly see where Unix gets its features from - terse, cryptic and messy.) This is another thing we're just going to disagree on. I think C++ is a pretty messy language, but feel that straight up C is rather simple and elegant. I had only used C++ before, but a friend rather easily convinced me that C is in fact a very sexy language when used in its intended design space. To me, C is the pinacle of everything that is wrong with computer programming. How does the saying go? C combines the power and flexibility of machine code with the ease of use of machine code. (Which isn't quite fair - machine code is easier to read than C.) For some reason, there is this perverse correlation... There are wonderful, beautiful languages like Haskell, that nobody uses and that you can't do anything practical with. And then there are ugly, complex, messy, flabby languages like C, C++, Perl, VisualBasic, etc. which are what everybody uses, and which have the power to actually do things. As somebody who's spent their entire life obsessively programming computers, this state of affairs makes me really sad. I really wish to God there was a language like Haskell that was useable in the real world. :-( (I did seriously investigate the task once. Indeed, I got as far as writing a bootloader. It worked too!) Would you mind sharing the code? I'd be interested. Seriously - we're talking about 1 page of assembly. That's it. Write it to the boot sector of a floppy, reboot your PC and it says Hello World on the screen. That's the sum total of how far I got. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] OS design FP aesthetics
(someone else's quotes are scattered through here, my mailer lost the nested quoting) On Jun 18, 2007, at 16:46 , Creighton Hogg wrote: There are lots of things to like about Linux. It doesn't cost money. It's fast. It's reliable. It's flexible. It's secure. As someone who was involved with early Linux development but eventually bailed to FreeBSD for personal use, and who currently supports Linux in his day job, I'm somewhat dubious about reliable and secure. One vast tangled mess of complexity and disorder. Exhibit A: Package managers exist. Exhibit B: Autoconf exists. I rest my case. Erm, package managers should exist regardless. That *multiple* incompatible package managers exist can be argued as a flaw. The real problem indicated by your exhibits (assuming the preceding adjustment) is that Unix is not a monolithic entity; it's the result of dozens of companies extending the original research OS in multiple incompatible directions, then multiple standards committees harmonizing them more or less by legitimizing every incompatible spec for which they couldn't get people to agree on a single path. The development of the pax utility by the POSIX committee is a particularly horrifying example. That said, autoconf also deals with some monstrosities nobody should have to deal with these days. (Ancient Eunice, anyone? Domain/OS?) (Have you ever programmed in C? You can certainly see where Unix gets its features from - terse, cryptic and messy.) Heh. Actually, Unix is terse because it was developed and originally used on 110-baud teletypewriters. I've *used* a KSR33; you quickly come to appreciate the fact that Unix commands are terse. C has its issues, but the original KR C was quite simple and elegant. (And IMO preferable to its predecessor BCPL.) -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon universityKF8NH ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Can't build Lambdabot
On Mon, Jun 18, 2007 at 05:07:19PM +0200, Daniel Fischer wrote: Hi all, so I got myself a brand new lambdabot-4.0 today, but failed miserably building it. First, build-depends lists fps=0.7. Now Data.ByteString(.*) is in base(since 6.6.1, I believe). Easy to fix, just delete the entry in lambdabot.cabal. After apparently successful configuration, ./build fails, because 'breakChar' is no longer present (in fps-0.8 or the 6.6.1 base). Okay, change breakChar '\n' to break (== '\n') in BotPP.hs and hope for the best. Trying ./build again, fails with Preprocessing executables for lambdabot-4.0... Building lambdabot-4.0... Plugin.hs:46:7: Could not find module `Text.Regex': it is a member of package regex-compat-0.71, which is hidden which would be easy to fix if regex-compat-0.71 WERE hidden, bu it's NOT, it's definitely exposed. So what's going on here and how can I get myself a working lambdabot? I'm on an i386-linux, if that matters. Lambdabot 4.0 is hopelessly obsolete. Use the darcs version... Stefan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] OS design FP aesthetics
On 6/18/07, Creighton Hogg [EMAIL PROTECTED] wrote: On 6/18/07, Andrew Coppin [EMAIL PROTECTED] wrote: Creighton Hogg wrote: There are lots of things to like about Linux. It doesn't cost money. It's fast. It's reliable. It's flexible. It's secure. Okay, I'm not sure if I'd agree with the reliable secure points. I mean, relative to what could be done. I'm a rank amateur when it comes to OS work but when I've looked at recent papers Linux really isn't that cutting edge. I mean, it may be reliable in comparison to Windows 98 has less known exploits than any Windows system, but in terms of how good it *could* be I think there's an awful lot of room for growth. Isn't there a lot of room for improvement in *any* product? Well, I'm not just talking about improvement. I'm talking about things like capabilities, self-healing kernels, separation kernels, exo kernels, things that may have serious advantages but can't necessarily be strapped on to a preexisting kernel such as Linux. Bah. Of course after I say this I get a bad feeling, so I checked the interwebs and found out that there has been work on incorporating self-healing into Linux. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] To yi or not to yi, is this really the question? A plea for a cooperative, ubiquitous, distributed integrated development system.
On Mon, 2007-06-18 at 22:05 +0100, Pasqualino 'Titto' Assini wrote: Hi Claus, On Monday 18 June 2007 18:14:58 Claus Reinke wrote: Having just presented a case for the possible rationality of the irrational decision of creating an Emacs-like IDE in Haskell, I wonder if we should not be even more irrational and contemplate the possibility of using Haskell to create a radically different kind of IDE.. New technologies are often used to imitate and reimplement the artefacts of previous technologies. don't underestimate those previous technologies, though. given your you're almost certain to find this interesting: Croquet is a powerful open source software development environment Thanks for the reference. I actually knew about Croquet but I thought of it mostly as an open-source second life because of its emphasys on shared 3D worlds but you are quite right, it might also be useful for cooperative software development. I must admit that my dream doesn't go so far, I was more thinking about Web/Web services kind of technology to integrate distributed traditional development text-based tools (editors, compilers, etc.) plus a configurable Web based UI. You might find this cute: https://www.youos.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell mode for emacs - some questions
peterv writes: - How can I just compile and run in one go without having to type ghc --make main.hs as arguments for the compile... command and then typing main.exe for shell command...? This is what you do all the time when using Visual Studio, Eclipse, etc: just hit the F5 key which builds all the dependencies and runs one or more generated executables. Easy. Visual Haskell does this (in the cases it does not hang for some unknown reason). Of course I could dig into ELISP, but somehow I feel this must be supported somehow. Use C-c C-l to load the file into GHCi. This is better than just compiling it: you get an interactive environment in which to play around with, test out functions, etc. You can still 'run' your program by typing 'main' in GHCi. - There seems to be support for Haskell Font Lock Symbols, which should convert \, - and maybe other symbols to good looking Unicode fonts. I can't get the correct fonts working on Windows. Now as I understood this is not really supported because of indentation problems, as underneed the single Unicode arrow character is converted into -? This is unfortunate, because that's one of the things I really like about Sun's Fortress: the usage of Unicode symbols makes the text look much more mathematically, versus the half-century-old ASCII text. Furthermore in almost all Haskell books the richer font symbols are used for clarity. Any hints on this topic? I wouldn't be surprised if this code had bit-rotted, or if there never has been Windows support. It's a corner function, used by few and therefore not that polished. By all means, try it out, and if it doesn't work, feel free to submit patches, but I doubt it'll get changed any time soon by a haskell-mode developer :) -- -David House, [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Can't build Lambdabot
Arrrgh, now I get to: [ 4 of 78] Compiling Lib.Parser ( Lib/Parser.hs, dist/build/lambdabot/lambdabot-tmp/Lib/Parser.o ) Lib/Parser.hs:7920:4: Not in scope: `as_name' Lib/Parser.hs:7926:4: Not in scope: `qualified_name' Lib/Parser.hs:7932:4: Not in scope: `hiding_name' Lib/Parser.hs:8015:4: Not in scope: `minus_name' Lib/Parser.hs:8021:4: Not in scope: `pling_name' Lib/Parser.hs:8034:4: Not in scope: `pling_name' what's happened here? How do I fix that? Am Montag, 18. Juni 2007 23:09 schrieb Jason Dagit: On 6/18/07, Ian Lynagh [EMAIL PROTECTED] wrote: On Mon, Jun 18, 2007 at 05:07:19PM +0200, Daniel Fischer wrote: Plugin.hs:46:7: Could not find module `Text.Regex': it is a member of package regex-compat-0.71, which is hidden which would be easy to fix if regex-compat-0.71 WERE hidden, but it's NOT, it's definitely exposed. You need to list it in the build-depends field in the .cabal file. Is it possible for cabal to catch this mistake and report a different error? I've bumped into it before as well and found the error message to be enough misleading that I went down the wrong trouble shooting path. Maybe GHC should give a better diagnostic here? Jason Yes, very misleading. Cheers, Daniel ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Can't build Lambdabot
On Tue, Jun 19, 2007 at 12:36:44AM +0200, Daniel Fischer wrote: Arrrgh, now I get to: [ 4 of 78] Compiling Lib.Parser ( Lib/Parser.hs, dist/build/lambdabot/lambdabot-tmp/Lib/Parser.o ) Lib/Parser.hs:7920:4: Not in scope: `as_name' Lib/Parser.hs:7926:4: Not in scope: `qualified_name' Lib/Parser.hs:7932:4: Not in scope: `hiding_name' Lib/Parser.hs:8015:4: Not in scope: `minus_name' Lib/Parser.hs:8021:4: Not in scope: `pling_name' Lib/Parser.hs:8034:4: Not in scope: `pling_name' what's happened here? How do I fix that? Your lambdabot is too old. It needed fixes to work with GHC 6.6's version of the haskell-src package. Stefan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] To yi or not to yi, is this really the question? A plea for a cooperative, ubiquitous, distributed integrated development system.
hi titto, I actually knew about Croquet but I thought of it mostly as an open-source second life because of its emphasys on shared 3D worlds but you are quite right, it might also be useful for cooperative software development. the first corporation betting its money on croquet is Qwaq: http://croquetconsortium.org/index.php/Current_Projects#Qwaq_Projects ..proprietary Croquet-based collaborative spaces enabling our customers to integrate their existing 2D media, 3D models and simulations. These spaces enable interlinked virtual conference rooms dedicated to each area of corporated interest.. cooperative software development is just one instance of that (i seem to recall a reference to ubuntu linux using croquet as a coordination tool, but my own network connection is highly uncooperative at the moment..; sorry, seems i have to send this email with without adding the necessary references/urls below; most of the keywords should show up on google, but most connections are timing out on me..). where squeak is too dynamic/imperative/flexible, haskell is too static/unreflective/limited (ever tried to pass functions through haskell's i/o interface? Is this really a limitation of the language proper or just of its implementations? both, though the/some implementations are further ahead than the language proper. but if those implementation branches are not consolidated into the main implementations and the language that is used to write the standard libraries, they will bitrot (some have). Is there any fundamental reasons why Haskell functions/closures cannot be serialised? no, and that is part of the problem: the language would need to be extended, but the academically interesting issues have been tackled, all that is left is a lot of work (that is why these things would be so valuable: complex implementation machinery, controlled by very small language extensions, sometimes even language simplifications, such as lifting existing restrictions on i/o), preferably with very good planning, so that all the work does not become useless right after it is finished. there isn't much hope that this issue is going to be settled via the usual academic funding sources. I believe that this is precisely what the distributed version of GHC used to do. yes, distributed systems have some of the same issues. but note that you said version of ghc, not ghc, not haskell. even what is there hasn't been folded back into the mainline, nor does it keep up with other mainline developments. Most languages, even Java, have a reflection capability to dynamically inspect an object. It is surprising that Haskell doesn't offer it. it has to be done with care, or it will invalidate *all* your nice reasoning about haskell programs. random example reify (f . g) == [| f . g |] =/= [| \x- f (g x) |] == reify (\x- f (g x)) reification is not a referentially transparent program context. persistence [many starts, no finish Have you checked the prevayler-inspired approach implemented in HAppS ? no, do you have a reference? but i meant orthogonal persistence, as in all program parts can persist, including functions, thunks, types,.. once you start going down that route, the rigid globally static/dynamic distinction quickly becomes meaningless (instead one has locally static/dynamic phases of evaluating program parts, ie, one does a dynamic type check in each static phase, and if that succeeds, the immediately following dynamic phase will be type correct without further runtime type checks). if you can store, retrieve, visualise and edit collections of functions, you already have first class modules (there was an early thesis on a persistent algol, with a title roughly like persistent first-class procedures are enough). and the classical distinctions between language and programming environment begin to blur considerably. , but see Clean's first class i/o] What advantages does it provide? please see their papers. but in essence, they approach the same problem from a different direction: if one doesn't limit i/o to fully evaluated non- functions, as haskell does, one can make anything persist, just by writing it to a file (which thereby becomes a typed object rather than a string of bytes), and one can distribute anything, including code, by writing it accross the network. it raises all the same issues as orthogonal persistence: type Dynamic is needed when checking that input is of the type it claims to be, types need to be stored/validated via some clearing house system (there's no guarantee that the program that reads an expression has compatible types to the program that wrote it, types and compilers evolve, ..). reflection/meta-programming [Data/Typeable, template haskell..; meta ml?]). one dream would be successors to haskell and croquet so that croquet' could be implemented in haskell''. Is just the lack of reflection in Haskell that you miss?
Re: [Haskell-cafe] String Hashing
On 6/19/07, Jan-Willem Maessen [EMAIL PROTECTED] wrote: This looks like a version of the Bob Jenkins hash function from burtleburtle.net. I implemented the 32-bit version of this as follows: Indeed. It's the 64-bit version. 32 bits is oh-so-last-century. ;-) mix :: Int32 - Int32 - Int32 - (Int32 - Int32 - Int32 - a) - a [deletia] I mention this because your code writes the whole thing out longhand---which might be faster, or might not, but certainly misses the highest-level structural patterns in the original. Your use of a data type to represent triples is probably better nowadays than my rather quirky use of CPS (in other words, this could have been a function Triple - Triple instead of the rather odd type you see above). Well, the main difference, is the CPS version just folds the uses of (.) into the individual groups of arithmetic. Actually, without knowing what GHC *actually* does, it is conceivable that a compiler could do better with the CPS version, precisely because there's one less layer of abstraction to inline/fold away. I'll have to give it a go if I get a chance (this is code for my Real Job (TM), and tuning the life out of the code isn't necessary right now, but I thought I'd float this, as much because I might learn something, as anything. The thinkon flux in this list is pretty favourable). That said, I assume you instrumented your code and determined that hash collisions are actually a bottleneck for you, and that a hash table is the right structure to begin with? I'm implementing a species of database (trade secrets, blah, blah, blah), which needs to handle *large* data sets, and actually, an external B-tree is probably better than an external hash table. I decided to do a hash table first though to iron out some of the issues to do with concurrent external structures. A linear hash table is pretty simple compared to a B-tree. The Jenkins' hash function comes into it because you really want to avoid overfull buckets. It's also one of those cases, where you'd like the compiler to do a good job. If the compiler can't do a good job of straight line operations on [essentially] built in data types, then what hope have we of convincing anyone, including ourselves, that Haskell is fit for Real Programs (TM). When last I checked the result was faster than Data.Map, but not by much, and using strings probably wipes out that advantage vs. tries. edna-e-mode-voice No Strings, darling! No Strings. /edna-e-mode-voice cheers, T. -- Dr Thomas Conway [EMAIL PROTECTED] Silence is the perfectest herald of joy: I were but little happy, if I could say how much. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: String Hashing
On 6/19/07, apfelmus [EMAIL PROTECTED] wrote: Trie it is, not balanced tree. A logarithm in this would be new to me. :) True enough, my braino. As a side node, Mr. Exp says: 64 is large enough for the size needs of any logarithm. Que? type HashTable k v = TVar (Array Int (TVar [(k,v)])) Don't you want a TArray Int [(k,v)]? Essentially the same. In any case, you could be able to set up an infinite trie and have lazy evaluation allocate space as needed: type Trie a = Branch (TVar a) (Trie a) (Trie a) Tree-like structure's are quite hostile to highly concurrent manipulation. It helps to introduce TVar indirections at each level: data Trie a = Branch (TVar a) (TVar (Trie a)) (TVar (Trie a)) Then you can update a subtree without having to modify the spine of the tree. There is some very fine work on this by Kim Larsen (and others), see for example http://citeseer.ist.psu.edu/2986.html T. -- Dr Thomas Conway [EMAIL PROTECTED] Silence is the perfectest herald of joy: I were but little happy, if I could say how much. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: OS design FP aesthetics
On 2007-06-18, Andrew Coppin [EMAIL PROTECTED] wrote: Creighton Hogg wrote: This is another thing we're just going to disagree on. I think C++ is a pretty messy language, but feel that straight up C is rather simple and elegant. I had only used C++ before, but a friend rather easily convinced me that C is in fact a very sexy language when used in its intended design space. To me, C is the pinacle of everything that is wrong with computer programming. How does the saying go? C combines the power and flexibility of machine code with the ease of use of machine code. (Which isn't quite fair - machine code is easier to read than C.) That's an utterly loony statement. If nothing else, the fact that vast, vast majority of the C code for an operating system is portable to other machine architectures indicates it is far more flexible. As for easier to read, what, you think the braces are going to poke you in the eye? Setting up arguments manually is easier to read and write than just putting them into an argument list? C is certainly no Haskell, but you're being ridiculous. -- Aaron Denney -- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] OS design FP aesthetics
Well, since we're on the subject and it's only the Cafe list, what is it that you find messy about Linux that you would want to be solved by some hypothetical Haskell OS? The hypothetical Haskell OS, especially if it were targeted toward 64 bit machines, could keep processes from messing with each other by way of language based security, and run them all in a single memory space. (The first system to do this, I believe, was the MULTIPOP timesharing system, but there are other precedents, too.) This would eliminate or simplify lots of context switches and buffer copies and memory management and other nastiness that now goes into kernels. /jaap ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] OS design FP aesthetics
On Jun 18, 2007, at 19:51 , Creighton Hogg wrote: The hypothetical Haskell OS, especially if it were targeted toward 64 bit machines, could keep processes from messing with each other by way of language based security, and run them all in a single memory space. (The first system to do this, I believe, was the MULTIPOP timesharing system, but there are other precedents, too.) This would eliminate or simplify lots of context switches and buffer copies and memory management and other nastiness that now goes into kernels. Okay, I remember seeing an example of this before , but I'm not sure if I see what language based security Haskell's type system could provide in protecting address spaces from each other. Normally I've seen capabilities used so that you can't access anything you can't name. Can you elaborate a little? He's saying that the language itself prevents programs from writing outside their address spaces or (via things like STM or runST) accessing resources they don't own. Which is a nice theory, but is dependent on the runtime not being buggy (I think some problems have been demonstrated with large arrays in GHC...). -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon universityKF8NH ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] OS design FP aesthetics
On 6/19/07, Creighton Hogg [EMAIL PROTECTED] wrote: Okay, I remember seeing an example of this before , but I'm not sure if I see what language based security Haskell's type system could provide in protecting address spaces from each other. Normally I've seen capabilities used so that you can't access anything you can't name. Can you elaborate a little? Nothing new here. Haskell might be more elegant than some of the earlier proposals, but the idea is old. FWIW, my PhD supervisor, Zoltan Somogyi did his PhD thesis on exactly such a scheme, using logic programming, rather than lazy functional programming. I'm not sure if the thesis itself is online. cheers, T. -- Dr Thomas Conway [EMAIL PROTECTED] Silence is the perfectest herald of joy: I were but little happy, if I could say how much. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] OS design FP aesthetics
On 6/18/07, Thomas Conway [EMAIL PROTECTED] wrote: On 6/19/07, Creighton Hogg [EMAIL PROTECTED] wrote: Okay, I remember seeing an example of this before , but I'm not sure if I see what language based security Haskell's type system could provide in protecting address spaces from each other. Normally I've seen capabilities used so that you can't access anything you can't name. Can you elaborate a little? Nothing new here. Haskell might be more elegant than some of the earlier proposals, but the idea is old. FWIW, my PhD supervisor, Zoltan Somogyi did his PhD thesis on exactly such a scheme, using logic programming, rather than lazy functional programming. I'm not sure if the thesis itself is online. Actually it is! Thank you for the reference. http://www.cs.mu.oz.au/~zs/papers/papers.html in case anyone else is interested ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] IDE?
Exhibit A: Package managers exist. Exhibit B: Autoconf exists. I rest my case. no. install the latest copy of ubuntu. look for the autotools. not there? thats right. somehow debian/unbuntu and derived distros are capable of installing tens of thousands of packages without nary a compiler installed. An operating system should have a simple, clear, consistent design. Not unlike a certain programming language named after a dead mathematition unix is indeed largely consistent as originally conceived and executed through most of its history. simple small tools. everything is a file. ascii config files. Still, I don't have the skill to write a functioning operating system writing an operating system in haskell would solve absolutely nothing. in the end the userland is still a much larger portion of the codebase, or should we rewrite all of that too? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [Haskell] ANN: Uniplate 1.0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Neil Mitchell wrote: Hi, I am pleased to announce Uniplate (formerly known as Play), a library for boilerplate removal requiring only Haskell 98 (for normal use) and optionally multi-parameter type classes (for more advanced features). This library has been tested with Yhc, Hugs and GHC. The Uniplate library can do some of the same things as Scrap Your Boilerplate (SYB), and has functions that can be used in a similar manner to everywhere and everything. LINKS Project home page: http://www-users.cs.york.ac.uk/~ndm/uniplate/ Hackage release: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/uniplate-1.0 Haddock docs: http://www.cs.york.ac.uk/fp/haddock/uniplate/ Short Manual: http://www.cs.york.ac.uk/fp/darcs/uniplate/uniplate.htm Draft Paper: http://www-users.cs.york.ac.uk/~ndm/downloads/draft-uniplate-15_jun_2007.pdf The manual contains a basic overview of some bits of the library, the paper goes into more detail, but is intended to still be a readable introduction to the library. The draft paper feels more readable and up-to-date than the manual. However I have one comment about it. In the section on DERIVE for Uniplate instances, the type appearing directly in one of its own constructors is demonstrated being recognized, as is the type appearing in a list in one of its own constructors. But no mention is made of just what powers the deriving has. I presume lists are a special case (how else would it be possible), but a naive reading gives no particular reason to suspect that the type in a Data.Map or Data.Set or any other collection, in one of its own constructors, would not be allowed. Also is there any restriction on the placement of lists in the constructor? I can't see how data Foo = CFoo Foo [Foo] Foo [Foo] Foo could be translated. Does putting the list somewhere other than last work? Isaac -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGdyHsHgcxvIWYTTURAiWuAKCUKf7aGf1rO58gcgxYkqbO7oKNCwCfTRpo 0UsQHx9riP+cZ/S/gloAy3g= =cAxY -END PGP SIGNATURE- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] OS design FP aesthetics
Normally I've seen capabilities used so that you can't access anything you can't name. Can you elaborate a little? He's saying that the language itself prevents programs from writing outside their address spaces Yep. Capabilities are usually not actually unforgeable, they are just picked from a largish key space. You can guess at them if you want to bother. Somewhere in the Exokernel papers, there is some discussion of this, and reference to the fact that a 64 bit capability is at least as secure as an 8 byte UNIX password, which I suppose is a fair assessment of the situation. With language based security, you can have unforgeable capabilities, though. An example of a system based on that idea, although expressed in different words, is http://mumble.net/~jar/pubs/secureos/secureos.html An alternative approach to unforgeable capabilities is to build them into the hardware using a tagged architecture. There is a paper by Tom Knight (mastermind of the original Lisp Machine) and Jeremy Brown that is relevant here, although it actually deals with the somewhat different problem of data dissemination control (think DRM but more for military applications and suchlike): http://www.ai.mit.edu/projects/aries/Documents/Memos/ARIES-15.pdf Note that earlier tagged architectures, including the Knight Machine and the K-machine, used tags mostly to speed up Lisp and not to enforce any sort of type discipline. Which is a nice theory, but is dependent on the runtime not being buggy (I think some problems have been demonstrated with large arrays in GHC...). There are three ways to deal with this. The first is the aforementioned tagged architecture in hardware. The second is running everything within a virtual machine that has a tagged architecture. In both of these cases, there would be a trusted security kernel, but you could make it pretty damn small. Unfortunately hardware is expensive and virtual machines are slow (although people keep claiming that they're getting better, and FPGAs are getting faster and cheaper all the time). The third way is to have a compiler that compiles Haskell, or any other typesafe language, into a typed assembly language with a sufficiently expressive type system. You can then feed TAL-annotated binaries to the (trusted) loader. This way, you can also support multiple programming languages while still maintaining language based security and a small trusted security kernel, viz. the TAL type checker. /jaap ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] OS design FP aesthetics
On Tue, Jun 19, 2007 at 02:36:31AM +0200, Jaap Weel wrote: Normally I've seen capabilities used so that you can't access anything you can't name. Can you elaborate a little? He's saying that the language itself prevents programs from writing outside their address spaces Yep. Capabilities are usually not actually unforgeable, they are just picked from a largish key space. You can guess at them if you want to bother. Somewhere in the Exokernel papers, there is some discussion of this, and reference to the fact that a 64 bit capability is at least as secure as an 8 byte UNIX password, which I suppose is a fair assessment of the situation. Every capability system I've seen works like Unix file descriptors. The kernel assigns capability numbers, and since the numbers are only valid in one process, and the only valid capability numbers are to capabilities your have, there is no danger caused by guessing. Stefan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] OS design FP aesthetics
Every capability system I've seen works like Unix file descriptors. The kernel assigns capability numbers, and since the numbers are only valid in one process, and the only valid capability numbers are to capabilities your have, there is no danger caused by guessing. You know, when I typed that, I knew I really ought to qualify it a bit, because the word capability is used in several ways. You are, of course, right to say that this is a common implementation of capabilities in operating systems with multiple memory spaces, but it does not work in a single memory space design without language security where user processes can access the kernel tables. /jaap ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [Haskell] ANN: Uniplate 1.0
Hi The draft paper feels more readable and up-to-date than the manual. That's very true! Originally there was a manual, now there is a paper - perhaps I should take the manual down if people think that the paper is sufficiently readable? However I have one comment about it. In the section on DERIVE for Uniplate instances, the type appearing directly in one of its own constructors is demonstrated being recognized, as is the type appearing in a list in one of its own constructors. But no mention is made of just what powers the deriving has. The scheme outlined in the paper is very powerful - it will work for all data structures which don't contain a forall in the declaration. It can only derive instances for entirely concrete data types, i.e. you can't write an instance Maybe x, but you can write one instance Maybe Bool. (PlateData/PlateTypeable do not have this restriction). I presume lists are a special case (how else would it be possible), For the implementation, Data.Derive has a special case for lists, tuples and Maybe. Its a shame that only a restricted number of types are supported - things like Data.Map/Data.Set can be supported perfectly, apart from restrictions in Template Haskell. At derivation time, if Data.Derive comes across Data.Set it cannot get at Data.Set's internal structure, so it can't figure out how the instance should look. This means that the number of data types within the constructor is fixed, but can be easily extended. I'm currently deciding what to do about this. One option is to look at using SYB's reflection capabilities which do allow this, and saving the result as an instance. Another option is to add special cases for many more data types (Set/Map are both candidates). Perhaps template haskell can even be persuaded to do some of what I want - I'm still learning its power. Also is there any restriction on the placement of lists in the constructor? I can't see how data Foo = CFoo Foo [Foo] Foo [Foo] Foo could be translated. Does putting the list somewhere other than last work? The list can come anywhere. Consider the simplest example: data Foo = CFoo [Foo] [Foo] The instance would have the same effect as: instance Uniplate Foo where uniplate (CFoo x y) = (x ++ y, \z - let (x2,y2) = splitAt (length x) z in CFoo x2 y2) (the actual instance would be a continuation passing variant of this, and be more efficient, but still have the same meaning) The key observation is that the length of the x field before and after is the same, so the multiple lists can be split back into their original sizes. Thanks Neil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Efficient signal processing
lemming: On Sun, 17 Jun 2007, Donald Bruce Stewart wrote: simonmarhaskell: Henning Thielemann wrote: The program is compiled with GHC-6.4 and option -O2, CPU clock 1.7 GHz. ByteString is much faster with GHC 6.6, IIRC. We optimised the representation of ForeignPtr, and ByteString takes advantage of that. I recommend upgrading. Yes, a 2x speedup isn't uncommon. Indeed, in my simple example the speedup factor was 2. However this is still far from being enough for real-time signal processing. I found another problem: The rounding functions from RealFrac are much slower than GHC.Float.double2Int. I've set up a bug ticket in GHC trac. if there's floating point math involved, carefully check the Core output. -ddump-simpl -O2 ByteString is even faster with the GHC head, branch, given the cranked up rules and constructor specialisation. Can I test them without compiling GHC myself? I.e. can I still install the FPS package separately? oh, i was just suggesting trying the GHC HEAD branch for its improved optimisations, not the `unstable' branch of fps. -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [Haskell] ANN: Uniplate 1.0
Hi Thinking about this slightly further... For the implementation, Data.Derive has a special case for lists, tuples and Maybe. Its a shame that only a restricted number of types are supported - things like Data.Map/Data.Set can be supported perfectly, apart from restrictions in Template Haskell. There are two cases. 1) The data structure contains values, in specific places. Lists, tuples, Either etc. are all like this. The rules in the paper cover all these situations. 2) The data structure contains values, but their place is a feature of the data structure - i.e. Map/Set. In this case the right thing to do is probably to do fromList/toList pairs on them. I'll modify the derive tool to take this into account. I've never seen any comments on the effect of using SYB with data structures containing invariants such as Map's. I guess SYB can break these invariants quite easily, so should be used with care in some places. Thanks Neil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] ANN: Uniplate 1.0
On Tue, Jun 19, 2007 at 03:11:44AM +0100, Neil Mitchell wrote: Hi Thinking about this slightly further... For the implementation, Data.Derive has a special case for lists, tuples and Maybe. Its a shame that only a restricted number of types are supported - things like Data.Map/Data.Set can be supported perfectly, apart from restrictions in Template Haskell. There are two cases. 1) The data structure contains values, in specific places. Lists, tuples, Either etc. are all like this. The rules in the paper cover all these situations. 2) The data structure contains values, but their place is a feature of the data structure - i.e. Map/Set. In this case the right thing to do is probably to do fromList/toList pairs on them. I'll modify the derive tool to take this into account. I've never seen any comments on the effect of using SYB with data structures containing invariants such as Map's. I guess SYB can break these invariants quite easily, so should be used with care in some places. No, it can't be used on Map etc in any reasonable way. You can't break the invariants because you can't do much of anything: -- This instance preserves data abstraction at the cost of inefficiency. -- We omit reflection services for the sake of data abstraction. instance (Data k, Data a, Ord k) = Data (Map k a) where gfoldl f z map = z fromList `f` (toList map) toConstr _ = error toConstr gunfold _ _= error gunfold dataTypeOf _ = mkNorepType Data.Map.Map dataCast2 f= gcast2 f Stefan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] OS design FP aesthetics
On 6/18/07, Creighton Hogg [EMAIL PROTECTED] wrote: On 6/18/07, Andrew Coppin [EMAIL PROTECTED] wrote: Creighton Hogg wrote: Well, since we're on the subject and it's only the Cafe list, what is it that you find messy about Linux that you would want to be solved by some hypothetical Haskell OS? This is drifting off-topic again, but here goes... Yeah, so I'll just split this off into a different thread. There are lots of things to like about Linux. It doesn't cost money. It's fast. It's reliable. It's flexible. It's secure. Okay, I'm not sure if I'd agree with the reliable secure points. I mean, relative to what could be done. I'm a rank amateur when it comes to OS work but when I've looked at recent papers Linux really isn't that cutting edge. I mean, it may be reliable in comparison to Windows 98 has less known exploits than any Windows system, but in terms of how good it *could* be I think there's an awful lot of room for growth. However, unfortunately it's still Unix. In other words, it's a vast incoherant mess of largely incompatible ad-hoc solutions to individual problems implemented independently by unrelated hackers over the 40+ years of history that this software has been around. New software has to emulate quirks in old software, and client programs work around the emulated quirks in the new software to get the functionallity it actually wants. One vast tangled mess of complexity and disorder. Exhibit A: Package managers exist. Exhibit B: Autoconf exists. I rest my case. Okay, but these don't seem to really be design flaws so much as the inevitable results of age and the need for backwards compatibility. I'm looking more for technical problems that you would want to see fixed in our magical UberOS. An operating system should have a simple, clear, consistent design. Not unlike a certain programming language named after a dead mathematition, come to think of it... (Have you ever programmed in C? You can certainly see where Unix gets its features from - terse, cryptic and messy.) This is another thing we're just going to disagree on. I think C++ is a pretty messy language, but feel that straight up C is rather simple and elegant. I had only used C++ before, but a friend rather easily convinced me that C is in fact a very sexy language when used in its intended design space. Still, I don't have the skill to write a functioning operating system - much less one that's ready for the desktop - so that's that I suppose... (I did seriously investigate the task once. Indeed, I got as far as writing a bootloader. It worked too!) Would you mind sharing the code? I'd be interested. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe While this isn't an operating system written in a functional programming language it is quite an important part of one. NixOS is an experiment to see if we can build an operating system in which software packages, configuration files, boot scripts and the like are all managaed in a purely functional way, that is, they are all built by deterministic functions and they never change after they have been built., from http://nix.cs.uu.nl/nixos/index.html One thing microsoft has being doing which is interesting is singularity. It is a research OS done in .NET and is completely managed. It will be interesting to see the effects of a managed runtime environment and quite possibly open the door for a functional language to target the runtime. I think operating systems, and software design in general, will be headed towards integrating functional techniques from languages like Haskell into C and C++. Google's map/reduce paper is an excellent example but so is Tim Sweeney's talk on the future of video game design. I suppose more importantly.. would haskell kernel be done as a microkernel or a monolithic kernel ;-) Marketing it would be hard. Who would want to buy a lazy os? --Ryan Dickie ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] To yi or not to yi, is this really the question? A plea for a cooperative, ubiquitous, distributed integrated development system.
On Mon, 2007-18-06 at 15:01 +0100, Pasqualino 'Titto' Assini wrote: LambdaBot, hpaste and hoogle as well as the Haskell Wiki and indeed even this mailing list can all be thought as elements of a cooperative, ubiquitous, customisable, zero-installation, distributed and integrated (that should be enough buzzwords for anybody) development system. What we need is to connect the dots and [...] Oh, good Lord! Are we going to write all of this in points-free style? :O -- Michael T. Richter [EMAIL PROTECTED] (GoogleTalk: [EMAIL PROTECTED]) I'm not schooled in the science of human factors, but I suspect surprise is not an element of a robust user interface. (Chip Rosenthal) attachment: smiley-2.png signature.asc Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] OS design FP aesthetics
software packages, configuration files, boot scripts and the like are all managaed in a purely functional way, that is, they are all built by deterministic functions and they never change after they have been built., from http://nix.cs.uu.nl/nixos/index.html One thing microsoft has being doing which is interesting is singularity. its just not clear what these projects are trying to fix. i am all for good research, indeed a lot of it manifests itself in linux, bsd etc...but chucking a decade+ of debugging, userland tools, docs, etc...its a nonstarter. who is downloading minix3? purity of design at the os level has few takers in the real world. people want high performance, small footprint, and security. linux is delivering on these as good as anything else actually in use by mass markets. there have been other softball comments here, like the offhand comment that linux is not reliable and secure, but i haven't seen any substantial commentary on why this is the case. try these comments out on the kernel mailing list if you want to be brave AND ontopic. i say all of this as a freebsd user, so don't construe my defense of linux as a political bias. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
