Re: [Haskell-cafe] Re: 1,000 packages, so let's build a few!
Hi GHC doesn't bundle with cabal-install on any system. What is needed is not for the GHC team to be doing Windows platform packages, but for the Windows Haskell devs to build their own system, as happens on all the Unices. Take GHC's release, wrap it up with native installers, throw in useful libraries and executables like cabal. Done. GHC already takes the GHC release, bundles it up with a native installer, and then throws in useful executables like gcc. It just stops one hop short of done. Windows is special, we already treat Windows special, but currently its just short of useable. Duncan: Saying cabal.exe isn't mature enough to go in 6.10 is a perfect reason, but one that you never gave at the time. If it isn't ready, then that's fine. But if thats the case, will it be in 6.12, or will the standard Windows instructions involve hunting around haskell.org for a prebuild Cabal.exe? Thanks Neil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Verifying Haskell Programs
On Mon, Feb 2, 2009 at 10:04 PM, Don Stewart d...@galois.com wrote: pocmatos: Hi all, Much is talked that Haskell, since it is purely functional is easier to be verified. However, most of the research I have seen in software verification (either through model checking or theorem proving) targets C/C++ or subsets of these. What's the state of the art of automatically verifying properties of programs written in Haskell? State of the art is translating subsets of Haskell to Isabelle, and verifying them. Using model checkers to verify subsets, or extracting Haskell from Agda or Coq. Any references to publications related to this? -- Don -- Paulo Jorge Matos - pocmatos at gmail.com Webpage: http://www.personal.soton.ac.uk/pocm ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Verifying Haskell Programs
On Tue, Feb 3, 2009 at 12:28 AM, Don Stewart d...@galois.com wrote: dbueno: On Mon, Feb 2, 2009 at 15:04, Don Stewart d...@galois.com wrote: pocmatos: Hi all, Much is talked that Haskell, since it is purely functional is easier to be verified. However, most of the research I have seen in software verification (either through model checking or theorem proving) targets C/C++ or subsets of these. What's the state of the art of automatically verifying properties of programs written in Haskell? State of the art is translating subsets of Haskell to Isabelle, and verifying them. Using model checkers to verify subsets, or extracting Haskell from Agda or Coq. Don, can you give some pointers to literature on this, if any? That is, any documentation of a verification effort of Haskell code with Isabelle, model checkers, or Coq? (It's not that I don't believe you -- I'd be really interested to read it!) All on haskell.org, http://haskell.org/haskellwiki/Research_papers/Testing_and_correctness#Verifying_Haskell_programs And there's been work since I put that list together. Opps, sorry, missed this message. Should read everything before replying! :) -- Don -- Paulo Jorge Matos - pocmatos at gmail.com Webpage: http://www.personal.soton.ac.uk/pocm ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: pure crisis :)
On Mon, 02 Feb 2009 23:43:26 +0100, Henk-Jan van Tuyl hjgt...@chello.nl wrote: On Sun, 01 Feb 2009 20:19:18 +0100, Bulat Ziganshin bulat.zigans...@gmail.com wrote: Hello haskell-cafe, pure functional denotation for crisis: (_|_) Well, some experts say, the crisis has reached it's bottom. Yet some say that the bottom of the crisis is still undefined. -- Benjamin L. Russell -- Benjamin L. Russell / DekuDekuplex at Yahoo dot com http://dekudekuplex.wordpress.com/ Translator/Interpreter / Mobile: +011 81 80-3603-6725 Furuike ya, kawazu tobikomu mizu no oto. -- Matsuo Basho^ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Why binding to existing widget toolkits doesn't make any sense
John A. De Goes wrote: The size, color, and layout of widgets has no effect on interaction semantics and is best pushed elsewhere, into a designer-friendly realm such as CSS. Yes, layout can be separated from interaction. It's just that I don't consider CSS friendly at all, I'd say it's a 0th order language. Layout combinators in the spirit of TeX or Lout are more flexible while being simpler. In any case, a simple primitive grid :: [[Rect a]] - Rect a that arranges widgets in a rectangular grid should be enough for GUIs. Regards, apfelmus -- http://apfelmus.nfshost.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: hslogger bugs or features?
Hi John,
thank you for your feedback:
I've taken the time to rewrite the example (issue1) using the python
logging system. I came up with:
import logging
logging.basicConfig(level=logging.DEBUG,
format='%(asctime)s %(levelname)s %(message)s',
filename='/tmp/myapp.log',
filemode='w')
logging.getLogger('').setLevel(logging.DEBUG)
loggerSub = logging.getLogger('A.B.C')
loggerSub.critical('CRITICAL test, should be shown and should create the
sublogger')
logging.getLogger('').setLevel(logging.WARNING)
loggerSub.debug('WARNING test, should not be shown cause we have changed to
WARNING')
which only logs the first line but not the second one
2009-02-03 11:14:52,058 CRITICAL CRITICAL test, should be shown and should
create the sublogger
hackage hslogger does clone the priority setting for A.B.C (in getLogger).
The cloned value is no longer affected by when changing the top level logging
priority.
So this example makes hackage hslogger log both lines.
So I consider this a beeing a (small) bug.
Sincerly
Marc Weber
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why binding to existing widget toolkits doesn't make any sense
You know, I read the Fudgets thesis, and threw together an experiment which used Glade for layout and Haskell for semantics [1]. As somebody else noted, this isn't really a clean division, because of things like editable flags in the layout. The darcs repository has a couple of demo applications, there's also a Bridge game that doesn't quite work (not included), and I understand that Arrows would solve all my problems, but I still don't grok them, alas. What I found was that wiring the events through the application in a nice, functional way was quite tricky, but it was unclear whether this was just an API problem, or something more fundamental. The entire state seems to turn up in every connection between widgets (which really suggests that it's imperative with a veneer of declarative style, which of course it is). For example, you need a changed flag in the state of the text editor. This is updated by a signal from the text widget, and read by the main window (because it affects the title bar text), the File/New and File/Open menu items (need to put up a Save Changes? message box) and the main window destroy handler (same thing, but it also needs some way of cancelling the action). Unfortunately, the main window is at one end of the event chain, while the menu is all the way over on the other side. This leads to tricky composition, and widgets which pass the entire state to each other because there's one little bit of information they might need. A related issue is that the application is like a river, in which events flow from one end to the other. Send events back the other way is ugly. Some sort of blackboard design might work better. This conversation made me start thinking about replacing Glade with a Haskell layout language, but I still don't know how to solve the above problems. I should read the FRP papers again. cheers, Fraser. [1] http://thewhitelion.org/darcs/barrie On Mon, Feb 2, 2009 at 8:58 PM, John A. De Goes j...@n-brain.net wrote: The actual presentation and layout of widgets would be better handled by a DSL such as CSS (which is, in fact, declarative in nature), while event logic would be best handled purely in Haskell. Regards, John A. De Goes N-BRAIN, Inc. The Evolution of Collaboration http://www.n-brain.net|877-376-2724 x 101 On Feb 2, 2009, at 12:39 PM, Creighton Hogg wrote: 2009/1/29 Conal Elliott co...@conal.net: Hi Achim, I came to the same conclusion: I want to sweep aside these OO, imperative toolkits, and replace them with something genuinely functional, which for me means having a precise simple compositional (denotational) semantics. Something meaningful, formally tractable, and powefully compositional from the ground up. As long as we build on complex legacy libraries (Gtk, wxWidgets, Qt, OpenGL/GLUT, ...), we'll be struggling against (or worse yet, drawn into) their ad hoc mental models and system designs. As Meister Eckhart said, Only the hand that erases can write the true thing. I think working on a purely functional widget toolkit would actually be a really cool project. Do you have any ideas, though, on what should be the underlying primitives? The initial gut feeling I have is that one should just ignore any notion of actually displaying widgets instead focus on a clean algebra of how to 'add' widgets that relates the concepts of inheritance relative position. What I mean by inheritance, here, is how to direct a flow of 'events'. I don't necessarily mean events in the Reactive sense, because I think it'd be important to make the model completely independent of how time actual UI actions are handled. Any thoughts to throw in, here? Cheers, C ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- http://thewhitelion.org/mysister ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Cabal and more than one version
Presumably the template-haskell-2.3 package does not build with ghc-6.8 but fails to correctly specify the version of base or ghc that it requires. If it did then we would have a better chance to get this right. Yes, this is certainly an issue in general with template-haskell-2.3. How do we fix this? Another possible workaround... If you avoid using the flag hack then the solver would not have to choose so early which version of template-haskell to commit to and it would be able to pick the right version later. Though then you need an alternative method of finding which version of template-haskell you ended up with. You could do it with some custom code in Setup.hs. I don't mind using a different approach. How do I detect which version of template-haskell I'm using in Setup.lhs that is backwords compatible to Cabal 1.2? I would like to support both template-haskell-2.2 and -2.3 by deriving EMGM type representations for it, but the later has the 'Loc' datatype. So, I'm currently using the CPP flag to determine whether 'Loc' is available or not: *#ifdef TH_LOC_DERIVEREP **-- This type is only provided in template-haskell-2.3 (included with GHC 6.10) **-- and up. *$(derive ''Loc) *#endif * Thanks, Sean ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Verifying Haskell Programs
Excerpts from Paulo J. Matos's message of Tue Feb 03 02:31:00 -0600 2009: Any references to publications related to this? While it's not Haskell, this code may be of interest to you: http://pauillac.inria.fr/~xleroy/bibrefs/Leroy-compcert-06.html This paper is about the development of a compiler backend using the Coq proof assistant, which takes Cminor (a C-like language) and outputs PowerPC assembly code. Coq is used both to program the compiler and prove it is correct. Austin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Bytestrings vs String? parameters within package names?
On Mon, Feb 02, 2009 at 10:41:57PM -0500, wren ng thornton wrote:
Marc Weber wrote:
Should there be two versions?
hslogger-bytestring and hslogger-string?
I'd just stick with one (with a module for hiding the conversions, as
desired). Duplicating the code introduces too much room for maintenance and
compatibility issues.
That's the big thing. The more people that use ByteStrings the less need
there is to convert when combining libraries. That said, ByteStrings aren't
a panacea; lists and laziness are very useful.
Hi wren,
In the second paragraph you agree that there will be less onversion when
using only one type of strings.
You're also right about encoding.
About laziness you'r partially right: There is also Bytestring.Lazy
which is a basically a list of (non lazy) Bytestring
Duplicating the code introduces too much room for maintenance and
compatibility issues.
I didn't mean duplicating the whole library. I was thinking about a
cabal flag
the cabal file:
flag bytestring
Default: False
Description: enable this to use Bytestrings everywhere instead of
strings
[... now libs and executables: ...]
if flag(bytestring)
cpp-options: -DUSE_BYTESTRING
An example module
module Example where
#ifdef Strings
import Data.List as S
#endif
#ifdef USE_BYTESTRINGS
import Data.ByteString as S
#endif
#ifdef USE_LAZY_BYTESTRINGS
import Data.ByteString.LAZY as S
#endif
#ifdef USE_UNICODE_BYTESTRING_LIKE_STRINGS
-- two bytes per char or more?
-- they can also be lazy such as Strings however one array element can
-- have more than one byte
import Data.Vector as S
#endif
Of course all four modules
import Data.List as S
import Data.ByteString as S
import Data.ByteString.LAZY as S
import Data.Vector as S
must expose the same API..
Of course cluttering up all files using those ifdefs isn't a nice option
either. But one could move this selection into the cabal file either
depending on one of those (no yet existing) packages:
string-string
string-bytestring
string-utf8-bytestring
string-bytestring
string-bytestring-lazy
Then you could replace one implementation by the other and recompile and
see wether the results differ.
Of course we must take care that we can keep laziness if required.
However using different packages exposing the same API (same modules and
same name will cause trouble if you really have to use both
implementations at some time. I only konw that there has been some
discussion about how to tell ghc to use a module from a particual
package. ..)
So I'd like to propose another way:
{-# LANGUAGE CPP #-}
import Data.STRING as S
and tell .cabal to define STRING representing either of the different
string implementations. I think this would be most portable and you can
additionally import other String modules as well.
So for now I think it would be best if you could teach cabal to change
names depending on flags:
Name: hslogger-${STRING_TYPE}
flag: use_strings
set STRING_TYPE = String
flag: use_bytestrings
set STRING_TYPE = Bytestring
.
Don't think about this issue how it is now or how much effort it would
be to rewrite everything. Think about it how you'd like to work using
haskell in about a year.
Marc
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Re: 1,000 packages, so let's build a few!
Don Stewart wrote: ganesh.sittampalam: Don Stewart wrote: So, wind...@haskell.org anyone? Get the wiki going, get the set of tasks created. Isn't the Haskell Platform going to do all this? Shouldn't interested people just help out there? The platform is a set of blessed libraries and tools. The distros will still need to package that. To do that for Windows, we're still going to need a windows packaging team, along side Debian, Arch, Gentoo, Mac etc. http://www.haskell.org/haskellwiki/Haskell_Platform section 4 talks about making distributions. So what should people be trying to do? Focus on (a) general infrastructure for packaging any Haskell library/binary on Windows (etc), or on (b) the specific task of packaging the Haskell Platform? If (b) then I don't think a whole new mailing list/wiki etc is worthwhile. (a) would obviously be nicer but is no doubt a much harder problem - I guess we'd want to start with Bamse and perhaps make use of the nestedInstalls feature somehow. Ganesh == Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html == ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Cabal and more than one version
On Tue, 2009-02-03 at 10:38 +0100, Sean Leather wrote: Presumably the template-haskell-2.3 package does not build with ghc-6.8 but fails to correctly specify the version of base or ghc that it requires. If it did then we would have a better chance to get this right. Yes, this is certainly an issue in general with template-haskell-2.3. How do we fix this? We patch the .cabal file in the current darcs version so that its fixed in the next release. Another possible workaround... If you avoid using the flag hack then the solver would not have to choose so early which version of template-haskell to commit to and it would be able to pick the right version later. Though then you need an alternative method of finding which version of template-haskell you ended up with. You could do it with some custom code in Setup.hs. I don't mind using a different approach. How do I detect which version of template-haskell I'm using in Setup.lhs that is backwords compatible to Cabal 1.2? You get access to the LocalBuildInfo which contains the packageDeps, the exact package identifiers. You can find the package you're after and find its version. Then you can do one of two things. You could generate a .h file either during post-conf or pre-build or you could add a cpp option by updating the localPkgDescr in the LocalBuildInfo to add an extra cpp option. It's not necessarily short or pretty, but it should be possible to make it work with Cabal-1.2 and 1.6. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Verifying Haskell Programs
Excerpts from Austin Seipp's message of Tue Feb 03 03:40:47 -0600 2009: ... After noticing that I didn't give a link to the code in the last message, I searched and found this more up to date page I think: http://compcert.inria.fr/doc/index.html Austin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] FP simulators for real-time systems?
On Mon, Feb 2, 2009 at 10:43 AM, Lee Pike leep...@gmail.com wrote: I'm interested to hear if anyone out there has used Haskell (or other functional languages for that matter) to build simulators for real-time systems. This is probably not exactly what you are thinking of, but there is OmegaGB, a game boy emulator written in Haskell: http://www.mutantlemon.com/omegagb/ Peace, Bit ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] type and data constructors in CT
On Mon, Feb 2, 2009 at 3:27 PM, David Menendez d...@zednenem.com wrote: Does that help at all? I think it does. But ... it gives me crazy ideas. Like: a functor is a kind of magic non-computing function! That's why they didn't call it a function? We know it maps A to FA, but we don't know how (maybe we don't care): there's no algorithm, just a functorific magic carpet that transports us across the border to FA. We couldn't compute FA even if we wanted to - different categories are like alternate universes, it would be like producing a widget in an alternate physical universe, we have no way of even thinking of how to do that. Ditto for data constructors as natural transformations: they don't compute, they just do magic. They're the CT surgeon's devious way of working on the guts of a categorical object without getting his hands dirty with mundane functions - getting from value A to (an?) image value of A under the functor F, which we cannot do directly by algorithm or computation. We do not - can not - have an actual function that computes A's image. We have to work indirectly, using non-computing magic carpets - first Id takes us to Id A, then we follow the nat trans to FA. Ok, that probably triggers the gag reflex for a real mathematician, but it sure sounds like a good story to me (remember, I'm taking notes for a guide/tutorial for newbies that may or may not ever get written.) Thanks very much for the help, -gregg ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: hslogger bugs or features?
Marc Weber wrote:
Following the advice on the hslogger wiki
(http://software.complete.org/software/wiki/hslogger)
I'm posting my thoughts about hslogger here:
Hi Marc,
Thanks for posting this.
Let's start with a big-picture architecture overview. What need does
hslogger anticipate meeting?
* Big applications have varied logging needs.
* Small applications want to keep logging simple.
* It is often desirable to enable or disable logging about certain types
of things.
* It is also often desirable to enable or disable logging above a
certain threshold of importance.
* The vast majority of apps want to set logging preferences once and
then forget about them, having decided what to do by reading a config
file, command line, or whatever.
* There can be many different ways to output logging messages: syslog,
stderr, files, etc. A given app may want to use more than one of them.
There are a lot of logging frameworks out there. Many of them fail the
keep logging simple test. Many others fail the varied needs test.
One that failed neither in my experience was the Python logging
infrastructure, so I based hslogger around its interface. hslogger has
served me pretty well since, though I wish it were a bit stronger on the
simple side.
This piece of code (src/System/Log/Logger.hs):
parentHandlers name =
let pname = (head . drop 1 . reverse . componentsOfName) name
in do
[...]
next - parentHandlers pname
return ((handlers parent) ++ next)
Why?
Because when logging to A.B.C it splits the String once to get
[A,B,C], then it drops the last part and runs the same again for
A.B and so on..
So A string is split 3 times for one logging action. I think this is a
waste of cpu cycles.. I'm going to improve this. While reading the code
i noticed two issues:
It may be, but really this is trivially tiny. The effort required to do
that is almost certainly exceptionally tiny compared just to the effort
required to actually output the log message. If you have a simple fix,
that's fine, but let's not complicate the code to save a 2 CPU cycles in
a process that can't possibly use less than 1000 :-)
==
issue 1
That's not the most awkward thing:
When logging to A.B.C hslogger does add 3 loggers to the global
logger Map:
Only if you haven't logged to it before.
A
A.B
A.B.C
all three inheriting the default priority level of the default
rootLogger
According to the docs:
First of all, whenever you first access a given logger by name, it
magically springs to life. It has a default 'Priority' of 'DEBUG'
and an empty handler list -- which means that it will inherit whatever
its parents do.
It's not setting the priority to the rootLogger default; it's setting it
to DEBUG. Your test doesn't invalidate this.
A test application illustrating this (feature ?)
module Main where
-- packages: hslogger
import System.Log.Logger as HL
import System.Log.Handler.Simple as HL
main = do
-- the default logger logs to stderr level WARNING
-- that's why the following message should be shown
-- a)
logM A.B.C HL.ALERT ALERT test, should be shown and should create the
sublogger
-- b)
updateGlobalLogger rootLoggerName (setLevel EMERGENCY)
logM A.B.C HL.ALERT ALERT test, should not be shown cause we have
changed to EMERGENCY
which prints:
tmp %./test1
/tmp nixos
ALERT test, should be shown and should create the sublogger
ALERT test, should not be shown cause we have changed to EMERGENCY
which is quite confusing because I haven't told hslogger explicitely
to use a log level printing ALERTs on A.B.C. so I'd expect that only
No, you told it that things logged to the root logger directly have a
certain preference. You have never expressed any preference whatsoever
on the A.B.C logger.
If you wish to set a global preference on the level of logging to occur,
you would be better served to do so in the configuration for the
handler. From the docs:
To give you one extra little knob to turn, 'LogHandler's can also have
importance levels ('Priority') associated with them in the same way
that 'Logger's do. They act just like the 'Priority' value in the
'Logger's -- as a filter. It's useful, for instance, to make sure
that under no circumstances will a mere 'DEBUG' message show up in
your syslog.
Since handlers are inherited down the logger chain, you can easily tweak
the priority associated with the handlers at the root logger level and
have an instant impact on all the others.
The point of the priority attached to a logger is to be able to disable
messages *about* certain things.
The point of the priority attached to a handler is to be able to disable
messages *below a certain importance level globally*.
So I think you're trying to
Re: [Haskell-cafe] hslogger bugs or features - patches
Marc Weber wrote: I've written some patches increasing speed by 30%. See the benchmark. Hi Marc, Patches are always great to see! Where is this benchmark? Can you separate out your speed changes (which I take it have no impact on functionality or API) from your other changes? I am not certain that I would want to apply the other changes. You can get them by cloning git://mawercer.de/hslogger; (branch hslogger_updates) I've replaced the internal representation (Map name Logger) by a tree. Only logging to a logger does no longer add a new node (which cloned the priority level in the past causing issue 1) As I said, I'm not really convinced this is a real issue. I'm still open to it though -- but I'm unconvinced that the change in API is worth it at this point. Also I've removed the standard setup logging to stderr. There is a setupLogging function instead.. I'm not sure what you mean the standard setup logging to stderr. Do you mean the default root handler? Why? I can think of some use cases where logging to stderr doesn't make sense and it took me too much time figuring out how to remve the old stderr logger (I didn't find a nice solution without changing the exposed API) You didn't notice setHandlers? -- | Set the 'Logger'\'s list of handlers to the list supplied. -- All existing handlers are removed first. setHandlers :: LogHandler a = [a] - Logger - Logger It is perfectly valid to set the root logger's handlers to [] if you want it to do nothing at all. I don't want to start using my personal copy of hslogger. That's why I'd like to ask you wether you consider these changes beeing improvements although they break existing code (You'll have do add that initialization line) At this point, I'm not convinced that the API changes are actual improvements. But I'm not saying never. I also wonder wether it's worth using Bytestrings instead of Strings? To what end? The only reason I can think of is UTF-8 output. (does putStr output UTF-8 these days, or still truncate the 24 bits above the low 8 like it used to? I haven't checked.) -- John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Bytestrings vs String? parameters within package names?
Marc Weber wrote: On Mon, Feb 02, 2009 at 10:41:57PM -0500, wren ng thornton wrote: Marc Weber wrote: Should there be two versions? hslogger-bytestring and hslogger-string? I'd just stick with one (with a module for hiding the conversions, as desired). Duplicating the code introduces too much room for maintenance and compatibility issues. That's the big thing. The more people that use ByteStrings the less need there is to convert when combining libraries. That said, ByteStrings aren't a panacea; lists and laziness are very useful. Hi wren, In the second paragraph you agree that there will be less onversion when using only one type of strings. Incidentally, I already wrote a library that abstracts the difference between a String and a ByteString: ListLike. I don't think anybody, including me, even uses it now. Turns out that's not all that helpful an abstraction to make ;-) -- John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Verifying Haskell Programs
State of the art is translating subsets of Haskell to Isabelle, and verifying them. Using model checkers to verify subsets, or extracting Haskell from Agda or Coq. Don, can you give some pointers to literature on this, if any? That is, any documentation of a verification effort of Haskell code with Isabelle, model checkers, or Coq? Graham Hutton's _Programming in Haskell_ has a chapter on reasoning about Haskell code: http://www.cs.nott.ac.uk/~gmh/book.html I put together some exercises of some short proofs for small Haskell functions: http://www.thenewsh.com/~newsham/formal/problems/ I have a short article that covers proofs in Haskell and Isabelle: http://users.lava.net/~newsham/formal/reverse/ The seL4 project is specifying an OS in Haskell, proving it in Isabelle and translating it to C with proofs that connect the translations: http://ertos.nicta.com.au/research/sel4/ I have an article on the curry-howard correspondence http://www.thenewsh.com/~newsham/formal/curryhoward/ In systems like Coq you can write code and proofs of the code in the same language and even at the same time. The Coq'Art book is a good reference, as are Adam Chlipala's draft book and Harvard class materials and the _Type Theory Functional Programming_ book. Full text for all but Coq'Art are online: http://www.labri.fr/perso/casteran/CoqArt/index.html http://www.cs.harvard.edu/~adamc/cpdt/ http://www.cs.harvard.edu/~adamc/cpdt/book/ http://www.cs.kent.ac.uk/people/staff/sjt/TTFP/ Denis Tim Newsham http://www.thenewsh.com/~newsham/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: hslogger bugs or features?
Marc Weber wrote: Hi John, thank you for your feedback: I've taken the time to rewrite the example (issue1) using the python logging system. I came up with: I think what you're noticing is the NOTSET level in Python. Python creates new loggers with the priority NOTSET, which means it searches up the tree for a logger with a priority /= NOTSET, and uses the first priority it finds. hslogger doesn't have NOTSET, and each logger does have a specific priority. The Python NOTSET priority does sound like a useful addition to hslogger, though. I think it would solve what you're after with minimal invasiveness. hackage hslogger does clone the priority setting for A.B.C (in getLogger). Yes, I see that; looks like the docs are incorrect on that point. But this only comes into play if you are changing the logging level on a particular subset of a running program. Does that really happen often in practice? I'd be happy to add NOTSET semantics to hslogger. -- John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: circular dependencies in cabal
On Mon, 2009-02-02 at 19:16 -0800, Valentyn Kamyshenko wrote: Hi Duncan, The major problem that I see is with # cabal update # cabal upgrade sequence of operations (that is, upgrading all installed packages). Right, that's exactly what doesn't work well and that I'm proposing to temporarily disable. I use this regularly to keep packages that I use (or are going to use) up to date. This is the functionality that, I suppose, everybody expects from the system like hackage/cabal. And, so far as I can see, the major problem is that 'cabal upgrade' will happily upgrade packages, that the core package depends on, and eventually will create configuration with circular dependencies. Can we do something simple - like, for example, forbidding updates of the packages that the core depends on (directly and indirectly)? Yes and there are a couple of additional ways we could improve it. But I'm thinking it'd be better to release before those things are done, and so in the mean time disable upgrade. In the mean time we can make it list the available packages that are newer than the installed ones and you get to pick manually which ones are sensible to install. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: 1,000 packages, so let's build a few!
On Tue, 2009-02-03 at 08:26 +, Neil Mitchell wrote: Hi GHC doesn't bundle with cabal-install on any system. What is needed is not for the GHC team to be doing Windows platform packages, but for the Windows Haskell devs to build their own system, as happens on all the Unices. Take GHC's release, wrap it up with native installers, throw in useful libraries and executables like cabal. Done. GHC already takes the GHC release, bundles it up with a native installer, and then throws in useful executables like gcc. It just stops one hop short of done. Windows is special, we already treat Windows special, but currently its just short of useable. Right, that's the job the platform will take on. Duncan: Saying cabal.exe isn't mature enough to go in 6.10 is a perfect reason, but one that you never gave at the time. If it isn't ready, then that's fine. But if thats the case, will it be in 6.12, or will the standard Windows instructions involve hunting around haskell.org for a prebuild Cabal.exe? It'll be in the first platform release which will be well before ghc 6.12. BTW, I think I've been missing your advice and cajoling about Windows platforms. It's been rather quiet recently. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] GUI semantics [was: Achim ranting]
First of all, thanks. I had almost judged the cafe to be unable to discuss any UI issue except rendering backends. Fraser Wilson blancoli...@gmail.com wrote: You know, I read the Fudgets thesis, and threw together an experiment which used Glade for layout and Haskell for semantics [1]. As somebody else noted, this isn't really a clean division, because of things like editable flags in the layout. The darcs repository has a couple of demo applications, there's also a Bridge game that doesn't quite work (not included), and I understand that Arrows would solve all my problems, but I still don't grok them, alas. It depends on what you may flag as editable. I just re-watched Conal's techtalk about TV's, which short-circuited a few neurons that were held apart by things like Functors and the ilk: Flagging an input as editable or not is OK, flagging an output is not (duh). In retrospect, TV's appear to me as being too denotationalistic[1]: From what I can tell, the way a String is displayed is _solely_ controlled by the run* functions. In a line-oriented text environment there's only one way, so it doesn't matter, but in a GUI, you might want to display it either as a label, or as an input-disabled textbox (so the user can copy the string). It might also be the text of a button, or the label of a node edge in a graph editor. Reactive gives us a way to describe the String (and other things) as a function of time, now we need to figure out how to describe the rest of its properties: A thing is not only defined by its inherent properties, but also by its interaction with the rest of the world. A hungry cat next to a mouse behaves different from a hungry cat next to a stone; how can we make a String aware of being the input of a label vs. being the input of a textbox, without shoving all knowledge of interaction into the world itself? Can we avoid specifying into textbox or into label (or in 14.5pt slanted Helvetica) if we don't care or the rendering backend just doesn't support it? Can we specify a new renderer that knows about a new attribute, and enrich our model with that attribute without changing the whole core? What I found was that wiring the events through the application in a nice, functional way was quite tricky, but it was unclear whether this was just an API problem, or something more fundamental. The entire state seems to turn up in every connection between widgets (which really suggests that it's imperative with a veneer of declarative style, which of course it is). I've also noticed this. Right now, my code would thread one event stream through everything, splitting and rejoining as necessary, but always uni-directional and staying one stream[2]. If I wanted feedback (I do, but haven't actually implemented it), I'd send an event down the stream, collect it at the end, and sink it back into the beginning (via IO, that is, threads and mvars). I bet there's a way to define fixpoints on event streams so that feedback does not have to take a full round-trip, and, most importantly, can flow on more paths than one, and I'm absolutely positive that it would break my current model (which, most likely, would be a good thing to do). I'm also not using Behaviours at all, which annoys me: I'd say textbox, change the string of that label if you're changed, not label, you form a Widget behaviour influenced by the string output of that Widget over there (which happens to be a textbox). I guess that once I understand what fixpoints mean in this context, stuff will clear up a lot. [1] TM. [2] It is modelled as a tuple of two streams of different type, one getting drained by handling functions, the other filled. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Ready for testing: Unicode support for Handle I/O
I've been working on adding proper Unicode support to Handle I/O in GHC, and I finally have something that's ready for testing. I've put a patchset here: http://www.haskell.org/~simonmar/base-unicode.tar.gz That is a set of patches against a GHC repo tree: unpack the tarball, and say 'sh apply /path/to/ghc/repo' to apply all the patches. Then clean your tree and build it from scratch (or if you're using the new GHC build system, just say 'make' ;-). It should validate, bar one or two minor failures. Oh, it doesn't work on Windows yet. That's the major thing left to do. If anyone else felt like tackling this I'd be delighted: all you have to do is implement a Win32 equivalent of the module GHC.IO.Encoding.Iconv (see below), everything else should work unchanged. Depending on whether any further changes are required, I may amend-record some of these patches, so treat them as temporary patches for testing only. Below is what will be the patch description in the patch for libraries/base. Comments/discussion please! Cheers, Simon Unicode-aware Handles ~ This is a significant restructuring of the Handle implementation with the primary goal of supporting Unicode character encodings. The only change to the existing behaviour is that by default, text IO is done in the prevailing encoding of the system. Handles created by openBinaryFile use the Latin-1 encoding, as do Handles placed in binary mode using hSetBinaryMode. We provide a way to change the encoding for an existing Handle: hSetEncoding :: Handle - TextEncoding - IO () and various encodings: latin1, utf8, utf16, utf16le, utf16be, utf32, utf32le, utf32be, localeEncoding, and a way to lookup other encodings: mkTextEncoding :: String - IO TextEncoding (it's system-dependent whether the requested encoding will be available). Currently hSetEncoding is availble from GHC.IO.Handle, and the encodings are available from GHC.IO.Encoding. We may want to export these from somewhere more permanent; that's something for a library proposal. Thanks to suggestions from Duncan Coutts, it's possible to call hSetEncoding even on buffered read Handles, and the right thing happens. So we can read from text streams that include multiple encodings, such as an HTTP response or email message, without having to turn buffering off (though there is a penalty for switching encodings on a buffered Handle, as the IO system has to do some re-decoding to figure out where it should start reading from again). If there is a decoding error, it is reported when an attempt is made to read the offending character from the Handle, as you would expect. Performance is about 30% slower on hGetContents = putStr than before. I've profiled it, and about 25% of this is in doing the actual encoding/decoding, the rest is accounted for by the fact that we're shuffling around 32-bit chars rather than bytes in the Handle buffer, so there's not much we can do to improve this. IO library restructuring The major change here is that the implementation of the Handle operations is separated from the underlying IO device, using type classes. File descriptors are just one IO provider; I have also implemented memory-mapped files (good for random-access read/write) and a Handle that pipes output to a Chan (useful for testing code that writes to a Handle). New kinds of Handle can be implemented outside the base package, for instance someone could write bytestringToHandle. A Handle is made using mkFileHandle: -- | makes a new 'Handle' mkFileHandle :: (IODevice dev, BufferedIO dev, Typeable dev) = dev -- ^ the underlying IO device, which must support -- 'IODevice', 'BufferedIO' and 'Typeable' - FilePath -- ^ a string describing the 'Handle', e.g. the file -- path for a file. Used in error messages. - IOMode -- ^ The mode in which the 'Handle' is to be used - Maybe TextEncoding -- ^ text encoding to use, if any - IO Handle This also means that someone can write a completely new IO implementation on Windows based on native Win32 HANDLEs, and distribute it as a separate package (I really hope somebody does this!). This restructuring isn't as radical as previous designs. I haven't made any attempt to make a separate binary I/O layer, for example (although hGetBuf/hPutBuf do bypass the text encoding). The main goal here was to get Unicode support in, and to allow others to experiment with making new kinds of Handle. We could split up the layers further later. API changes and Module structure NB. GHC.IOBase and GHC.Handle are now DEPRECATED (they are still present, but are just re-exporting things from other modules now). For 6.12 we'll want to bump base to version 5 and add a base4-compat. For now I'm using
Re: [Haskell-cafe] Re: Why binding to existing widget toolkits doesn't make any sense
On Feb 3, 2009, at 2:10 AM, Heinrich Apfelmus wrote: It's just that I don't consider CSS friendly at all, I'd say it's a 0th order language. I never said, CSS, I said like CSS. Layout combinators in the spirit of TeX or Lout are more flexible while being simpler. In any case, a simple primitive grid :: [[Rect a]] - Rect a that arranges widgets in a rectangular grid should be enough for GUIs. Spoken like a true programmer who knows nothing about usability. :-) Regards, John A. De Goes N-BRAIN, Inc. The Evolution of Collaboration http://www.n-brain.net|877-376-2724 x 101 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Ready for testing: Unicode support for Handle I/O
Simon Marlow wrote: I've been working on adding proper Unicode support to Handle I/O in GHC, and I finally have something that's ready for testing. I've put a patchset here: Yay! Comments below. Comments/discussion please! Do you expect Hugs will be able to pick up all of this? The only change to the existing behaviour is that by default, text IO is done in the prevailing encoding of the system. Handles created by openBinaryFile use the Latin-1 encoding, as do Handles placed in binary mode using hSetBinaryMode. Sounds very good and reasonable. We provide a way to change the encoding for an existing Handle: hSetEncoding :: Handle - TextEncoding - IO () and various encodings: latin1, utf8, utf16, utf16le, utf16be, utf32, utf32le, utf32be, localeEncoding, Will there also be something to handle the UTF-16 BOM marker? I'm not sure what the best API for that is, since it may or may not be present, but it should be considered -- and could perhaps help autodetect encoding. Thanks to suggestions from Duncan Coutts, it's possible to call hSetEncoding even on buffered read Handles, and the right thing happens. So we can read from text streams that include multiple encodings, such as an HTTP response or email message, without having to turn buffering off (though there is a penalty for switching encodings on a buffered Handle, as the IO system has to do some re-decoding to figure out where it should start reading from again). Sounds useful, but is this the bit that causes the 30% performance hit? Performance is about 30% slower on hGetContents = putStr than before. I've profiled it, and about 25% of this is in doing the actual encoding/decoding, the rest is accounted for by the fact that we're shuffling around 32-bit chars rather than bytes in the Handle buffer, so there's not much we can do to improve this. Does this mean that if we set the encoding to latin1, tat we should see performance 5% worse than present? 30% slower is a big deal, especially since we're not all that speedy now. IO library restructuring The major change here is that the implementation of the Handle operations is separated from the underlying IO device, using type classes. File descriptors are just one IO provider; I have also implemented memory-mapped files (good for random-access read/write) and a Handle that pipes output to a Chan (useful for testing code that writes to a Handle). New kinds of Handle can be implemented outside the base package, for instance someone could write bytestringToHandle. A Handle is made using mkFileHandle: Very nice. That means I can eliminate all the HVIO stuff I have in MissingH, which does roughly the same thing. with making new kinds of Handle. We could split up the layers further later. Would it now be possible to make the Socket an instance of this typeclass, so we can work with it directly rather than having to convert it to a Handle first? Thanks, -- John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why binding to existing widget toolkits doesn't make any sense
On Tue, Feb 3, 2009 at 5:49 PM, John A. De Goes j...@n-brain.net wrote: I never said, CSS, I said like CSS. Oh, I missed the like word! What do you mean with that? What aspects of CSS do you prefer to? In WPF a style is basically just a bunch of attribute key/value pairs. Layout combinators in the spirit of TeX or Lout are more flexible while being simpler. In any case, a simple primitive grid :: [[Rect a]] - Rect a that arranges widgets in a rectangular grid should be enough for GUIs. Spoken like a true programmer who knows nothing about usability. :-) Yes, layout must be very versatile and user definable. Regards, John A. De Goes N-BRAIN, Inc. The Evolution of Collaboration http://www.n-brain.net|877-376-2724 x 101 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why binding to existing widget toolkits doesn't make any sense
Thanks, Bob. On Mon, Feb 2, 2009 at 11:42 PM, Thomas Davie tom.da...@gmail.com wrote: On 3 Feb 2009, at 08:12, Achim Schneider wrote: John A. De Goes j...@n-brain.net wrote: Perhaps I should have been more precise: How do you define layout and interaction semantics in such a way that the former has a *necessarily* direct, enormous impact on the latter? HTML/CSS is a perfect example of how one can decouple a model of content from the presentation of that content. The developer writes the content model and the controller, while UX guys or designers get to decide how it looks. HTML, or rather XML, would be layout to me. GUI's usually don't serve static content, and allowing a CSS layer to position eg. a filter GUI that supports chaining up any amount of filters by slicing them apart and positioning them on top of each other (maybe because someone didn't notice that you can use more than one filter) wrecks havoc on both usability and the semantics. Wrecks havoc on the semantics in the sense of that if a thing is editable, the semantics should guarantee that it is, indeed, editable. Likewise, if something is marked as visible (and such things are explicit in the model, not defined by an outer layer), the semantics should guarantee that it is visible. I mostly don't get how a topic discussing how to do GUIs in a beautiful, consistent, composable, orthogonal, functional way got onto the topic of oh hay, you could do it with html and css. Sure, those two may be declarative languages, but that doesn't make either of them fill the list of features required above! Bob ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] hslogger bugs or features - patches
Hi John, Yes, a NotSet corresponds to my new Nothing setting. Proably you're right that adding that would have been enogh. API changes: Probably you're talking about the introduction of those classes? The idea was to not have to split that String over and over again. This way I thought you could pass over the logger path (LoggerName [A,B,C]) directly.. Where do I find the benchmark? Look it up in tests/Benchmark.hs and the .cabal file. I've added the benchmark first before having done most updates so that it's easier to compare the results. About the Bytestring thing I won't bother you until I'm sure it's worth it. You're right: in a ready to go application you always keep the default logger. But I want to use hslogger also to verify that my application does what I think it should be doing .. And while learning about hslogger you will do things in different order. Maybe its just that the most important parts about hslogger didn't came through to my mind. Maybe one can shorten that all to this. At least that's how my change are supposed to work: The logging sytem is based on a tree. To each tree node you can attach handlers. When a loogging action is performed the tree is traversed from the logger name up to the root. The first node having attached an logging priority will be used to decide wether the message gets logged at all. If its logged all the handlers having been attached to the visited nodes will be called. Conclusions: having this setup: A.B.C log priority EMERGENCY log priority DEBUG the handlers atteched to won't get debug messages send to the A.B.C logger. So there is no way to trace all messages without knowing about all sub logger level settings. Something like this would have been enough give me an idea what the library really does. Anyway the least thing I need is the NOTSET logger level setting. Wether we call it Nothing or NOTSET doesn't matter. Sincerly Marc Weber ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Why binding to existing widget toolkits doesn't make any sense
John A. De Goes wrote: Layout combinators in the spirit of TeX or Lout are more flexible while being simpler. In any case, a simple primitive grid :: [[Rect a]] - Rect a that arranges widgets in a rectangular grid should be enough for GUIs. Spoken like a true programmer who knows nothing about usability. :-) Hehe, well given that CSS doesn't even have such a primitive... :) Regards, apfelmus -- http://apfelmus.nfshost.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Colin Paul Adams] Re: [Haskell-cafe] Ready for testing: Unicode support for Handle I/O
John == John Goerzen jgoer...@complete.org writes: latin1, utf8, utf16, utf16le, utf16be, utf32, utf32le, utf32be, localeEncoding, John Will there also be something to handle the UTF-16 BOM John marker? I'm not sure what the best API for that is, since John it may or may not be present, but it should be considered -- John and could perhaps help autodetect encoding. Not really. The UTF-16 BOM is only allowed for utf16. Utf16le and utf16be do not have a BOM. What it does is alloww you to auto-detect the endianness if utf16 has been requested as the encoding (if it is not present the big-endian is assumed). Ditto for utf32/utf32be/utf32le. A BOM is thesedays allowed (but deprecated - it should never have been allowed and originally wasn't) for utf8 also. But it has no value other than to introduce ambiguity. :-( -- Colin Adams Preston Lancashire ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Colin Paul Adams] Re: [Haskell-cafe] Ready for testing: Unicode support for Handle I/O
Colin, I really don't see the point of putting your own name at the front of the subject line. It is redundant because it's already in the email headers. Perhaps this was a technical glitch? -- Robin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Colin Paul Adams] Re: [Haskell-cafe] Ready for testing: Unicode support for Handle I/O
Robin == Robin Green gree...@greenrd.org writes: Robin Colin, I really don't see the point of putting your own Robin name at the front of the subject line. It is redundant Robin because it's already in the email headers. Perhaps this was Robin a technical glitch? I guess so - certainly I didn't type it. -- Colin Adams Preston Lancashire ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Elegant powerful replacement for CSS
[Spin-off from the haskell-cafe discussion on functional/denotational GUI toolkits] I've been wondering for a while now what a well-designed alternative to CSS could be, where well-designed would mean consistent, composable, orthogonal, functional, based on an elegantly compelling semantic model (denotational). - Conal ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Elegant powerful replacement for CSS
Similarly, I've been wondering what's at the core of a GUI? It seems in recent years that more people have been moving towards web-based applications, and away from traditional GUIs, so the meaning of them may be changing. The old question seemed to be Page vs. Control-Board, but that seems like implementation, when the real essence of a GUI is taking in common kinds of user input and displaying output in a sensible way. Similarly, there are more ways to interact with a computer than ever before, from simple keyboard up through multitouch interfaces like the iPhone. It would be cool to me to see a semantic model that captures this. 2009/2/3 Conal Elliott co...@conal.net: [Spin-off from the haskell-cafe discussion on functional/denotational GUI toolkits] I've been wondering for a while now what a well-designed alternative to CSS could be, where well-designed would mean consistent, composable, orthogonal, functional, based on an elegantly compelling semantic model (denotational). - Conal ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Elegant powerful replacement for CSS
Isn't CSS about giving a style to the views in the model-view-controller paradigm? So basically it is a way to change the look of a user interface, without having to change the user interface definition itself. But isn't this just an environment monad that has functions to convert a model into a view (= geometry = render function + picking function)? Plugin a different environment and voila, the widgets are painted and maybe even layed differently, but you don't have to change any code or data Of course what a model really is, is not fully clear: http://blogs.msdn.com/johngossman/archive/2005/10/08/478683.aspx On Tue, Feb 3, 2009 at 8:50 PM, Jeff Heard jefferson.r.he...@gmail.comwrote: Similarly, I've been wondering what's at the core of a GUI? It seems in recent years that more people have been moving towards web-based applications, and away from traditional GUIs, so the meaning of them may be changing. The old question seemed to be Page vs. Control-Board, but that seems like implementation, when the real essence of a GUI is taking in common kinds of user input and displaying output in a sensible way. Similarly, there are more ways to interact with a computer than ever before, from simple keyboard up through multitouch interfaces like the iPhone. It would be cool to me to see a semantic model that captures this. 2009/2/3 Conal Elliott co...@conal.net: [Spin-off from the haskell-cafe discussion on functional/denotational GUI toolkits] I've been wondering for a while now what a well-designed alternative to CSS could be, where well-designed would mean consistent, composable, orthogonal, functional, based on an elegantly compelling semantic model (denotational). - Conal ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why binding to existing widget toolkits doesn't make any sense
On Tue, 2009-02-03 at 13:18 -0700, John A. De Goes wrote: Nor does it need one: http://www.csszengarden.com/ Can I write one if I really, really want to? I don't think excluding programmers from control over layout is much better than excluding non-programmers, really. jcc ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] hslogger bugs or features - patches
Hi Marc, I have pushed to my hslogger repo the optional priority for a logger support that we talked about, which is the Haskell version of Python's NOTSET. It is currently untested and represents only a minor API change. Please take a look and let me know your thoughts. It adds one new function to the API (clearLevel) and changes the return type of getLevel. Other than that, the changes are pretty much hidden from the public interface. I looked at your git repo, but I'm not going to pull anything from it right this minute. I would consider your performance change, but it was wrapped up with half a dozen other things in a single commit so I couldn't extract just it. If you would split up your changes into small bite-sized diffs, where each one makes exactly one change and is documented, I would be happy to take another look. As it is, each patch is touching too many unrelated areas for me to really bring them in. (I don't want API changes just for a performance improvement.) hslogger is used by a bunch of code all over the place, so I want to be very careful about what I do to it to avoid causing a lot of hassle for a lot of people. -- John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Elegant powerful replacement for CSS
I've been wondering for a while now what a well-designed alternative to CSS could be, where well-designed would mean consistent, composable, orthogonal, functional, based on an elegantly compelling semantic model (denotational). Well, if you think about CSS as in webpage styling, it's simply a way to override some attributes in the DOM tree. If you will, you can easily relate CSS selectors to your semantic editor combinators, since a concrete stylesheet makes explicit references to the structure of the document/interface it is associated with. One important difference is that in the case of CSS you don't need to mention all the intermediate nodes explicitly, which can make selectors shorter as well as non-deterministic, i.e. they can match different structural patterns at the same time. Also, you can perform a kind of pattern matching (filtering by class/id names) besides just blindly walking down the tree along the type structure. I'd say these two features make it a direct generalisation of the SEC concept. Gergely -- http://www.fastmail.fm - The way an email service should be ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] hslogger bugs or features - patches
On Tue, Feb 03, 2009 at 02:55:15PM -0600, John Goerzen wrote: I looked at your git repo, but I'm not going to pull anything from it right this minute. I would consider your performance change, but it was wrapped up with half a dozen other things in a single commit so I couldn't extract just it. Also, there is *no way* I will apply any patch that removes my copyright notices, as your git branch does. -- John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Elegant powerful replacement for CSS
On 3 Feb 2009, at 20:39, Conal Elliott wrote: [Spin-off from the haskell-cafe discussion on functional/ denotational GUI toolkits] I've been wondering for a while now what a well-designed alternative to CSS could be, where well-designed would mean consistent, composable, orthogonal, functional, based on an elegantly compelling semantic model (denotational). Can I start by replacing html please :) I'd like to separate the document in roughly the same way as html and css attempt to, meaning I'd like a document description language, and a styling description language. I can imagine the styling language having the meaning function from documents onto geometry, but the document description language is harder. Ideally what I'd like to do with it is to make it describe *only* the logical structure of the information being conveyed – sections, text, figures, tables (no, not for layout, for tabular data) etc. I can't though come up with a nice simple solution to that that (a) restricts users to really describing documents, not layout (b) still allows for composability in any sensible kind of way. Bob___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Elegant powerful replacement for CSS
Thomas Davie wrote: I can imagine the styling language having the meaning function from documents onto geometry, but the document description language is harder. Ideally what I'd like to do with it is to make it describe *only* the logical structure of the information being conveyed – sections, text, figures, tables (no, not for layout, for tabular data) etc. I can't though come up with a nice simple solution to that that (a) restricts users to really describing documents, not layout (b) still allows for composability in any sensible kind of way. I can see LaTeX as demonstrating that there is no such (single) language. It seems to me that the elementary units (chapters, sections, paragraphs,...) depend almost entirely on the domain of the document (a book, an article,...). In a similar way, many of the most painful examples of HTML come from people bludgeoning the elementary units into misservice. XML escapes from this by only providing a syntax/ontology rather than a language per se. So it seems to me that a general document framework should be an ontology of what primitives could exist, rather than a set of actual primitives. Of course, an ontological framework is no good without some collection of example languages it describes. One of the big tricks here is not in what languages look like in isolation, but in how languages can be combined or extended. -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Purely funcional LU decomposition
Hello folks
After a discussion on whether is possible to compile hmatrix in
Windows, I decided to go crazy and do a LU decomposition entirely in
Haskell...
At first I thought it would be necessary to use a mutable or
monadic version of Array, but then I figured out it is a purely interactive
process.
I am releasing this code fragment as LGPL.
{-
This program is free software: you can redistribute it and/or modify
it under the terms of the GNU Lesser General Public License as published
by
the Free Software Foundation, either version 3 of the License, or
(at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program. If not, see http://www.gnu.org/licenses/.
-}
import Data.Array.IArray
type Dim=(Int,Int)
lu::Array Dim Double - (Array Dim Double,Array Dim Double)
lu a = (aa l,aa u)
where
(l,u)=lu' a [] []
aa = accumArray (+) 0 (bounds a)
lu'::(Floating e) = Array Dim e - [(Dim,e)] - [(Dim,e)] -
([(Dim,e)],[(Dim,e)])
lu' a l u=if (ui==li) then (
((ui,uj),1.0):l,((ui,uj),a!(ui,uj)):u) else (lu' an (l++ln) (u++un))
where
k=li
((li,lj),(ui,uj))=bounds a
lik i=(a!(i,k)/a!(k,k))
un=[((k,j),a!(k,j)) | j-[lj..uj]]
ln=((lj,lj),1.0):[((i,k),lik i) | i-[li+1..ui]]
an=array ((li+1,lj+1),(ui,uj)) [((i,j),e_an i j) |
i-[li+1..ui],j-[lj+1..uj]]
e_an i j=a!(i,j)-(lik i)*a!(k,j)
Still needed:
1) Partial pivoting
2) Profiling... Lots!
3) Parallelize
--
Rafael Gustavo da Cunha Pereira Pinto
Electronic Engineer, MSc.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Elegant powerful replacement for CSS
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Patai Gergely wrote: | Well, if you think about CSS as in webpage styling, it's simply a way to | override some attributes in the DOM tree. If you will, you can easily | relate CSS selectors to your semantic editor combinators, since a | concrete stylesheet makes explicit references to the structure of the | document/interface it is associated with. One important difference is | that in the case of CSS you don't need to mention all the intermediate | nodes explicitly, which can make selectors shorter as well as | non-deterministic, i.e. they can match different structural patterns | at the same time. Also, you can perform a kind of pattern matching | (filtering by class/id names) besides just blindly walking down the tree | along the type structure. I'd say these two features make it a direct | generalisation of the SEC concept. This reminds me of Scrap Your Boilerplate. Perhaps looking at SYB would be a reasonable start to generalizing SECs in this context? - - Jake -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmIukAACgkQye5hVyvIUKkkrwCfaDJxjumLR92aIiGIvXtXH20G XiwAniEslqswXJYdeRW2hx2a6rdf3cdj =y/g1 -END PGP SIGNATURE- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Elegant powerful replacement for CSS
Jeff Heard wrote: Similarly, I've been wondering what's at the core of a GUI? It seems in recent years that more people have been moving towards web-based applications, and away from traditional GUIs, so the meaning of them may be changing. The old question seemed to be Page vs. Control-Board, but that seems like implementation, when the real essence of a GUI is taking in common kinds of user input and displaying output in a sensible way. I would go with Bret Victor's argument (http://worrydream.com/ MagicInk/) that the concept of user interface as primarily _interaction_ is misguided. What GUIs are really about is visual _presentation_ of information. The semantic questions are about what it means graphically to compose information sources. We spend more time reading, viewing, and absorbing that information, than rearranging it, or adding to it. Interaction changes the sources, or the way they compose, but is (or should be) fundamentally an infrequent activity. The better the visual presentation, the less you need to interact with it. Regards, Malcolm ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Elegant powerful replacement for CSS
2009/2/3 Peter Verswyvelen bugf...@gmail.com: Isn't CSS about giving a style to the views in the model-view-controller paradigm? So basically it is a way to change the look of a user interface, without having to change the user interface definition itself. In theory CSS separates content from presentation. In reality it looks like it isn't really powerful enough. Serendipitously, this rant popped up on reddit recently: http://www.flownet.com/ron/css-rant.html Summary: CSS's failures mean that the rendering of a page depends on the order of elements in the content. We have CleverCSS: a little less ambitious than Conal and Jeff imagined, I think, but still an improvement over raw CSS: http://sandbox.pocoo.org/clevercss-hs/ Alistair ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Elegant powerful replacement for CSS
Bret's argument, though, only applies to Information Software. Which... hey, if you want to go with describing fundamentally different approaches to GUIs based on the classifications he uses in his arguments, I think that's a better place to start than trying to figure out how to make a new denotationally-semantic GUI toolkit that works for everyone everywhere. On Tue, Feb 3, 2009 at 4:48 PM, Malcolm Wallace malcolm.wall...@cs.york.ac.uk wrote: Jeff Heard wrote: Similarly, I've been wondering what's at the core of a GUI? It seems in recent years that more people have been moving towards web-based applications, and away from traditional GUIs, so the meaning of them may be changing. The old question seemed to be Page vs. Control-Board, but that seems like implementation, when the real essence of a GUI is taking in common kinds of user input and displaying output in a sensible way. I would go with Bret Victor's argument (http://worrydream.com/MagicInk/) that the concept of user interface as primarily _interaction_ is misguided. What GUIs are really about is visual _presentation_ of information. The semantic questions are about what it means graphically to compose information sources. We spend more time reading, viewing, and absorbing that information, than rearranging it, or adding to it. Interaction changes the sources, or the way they compose, but is (or should be) fundamentally an infrequent activity. The better the visual presentation, the less you need to interact with it. Regards, Malcolm ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Converting Lists to Sets
Hi all,
I'm trying to use the Funsat library. One of its data types is CNF:
data CNF = CNF {
numVars :: Int
numClauses :: Int
clauses :: Set Clause
}
I have a list of clauses, but I'm getting an error when converting such a list
to a Set. Using the fromList function, the ghc compiler reports that the
fromList function is not applicable to literals.
type Clause = [Lit]
newtype Lit = L {
unLit :: Int
}
So, my question is: How can I solve this problem?
Thanks in advance,
Rodrigo.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Elegant powerful replacement for CSS
wren ng thornton w...@freegeek.org wrote: I can see LaTeX as demonstrating that there is no such (single) language. It seems to me that the elementary units (chapters, sections, paragraphs,...) depend almost entirely on the domain of the document (a book, an article,...). This is what I had in mind while I tried to write the plumbing to agar objects: Defining your own widgets. A library to do this, it seems would consist of things like ActionProducers instead of Buttons, and TextInput instead of TextBoxen and ListBoxen... that is, of Event ()'s and Behaviour/Event String's, alongside with high-level renderers, coupled with a feedback mechanism, that'll then be called Button and TextBox. A Listbox is already made out of such primitives, but this should be transparent to the developer. Another most important thing that I really want to have, is to enable the end-user to edit presentation, in a sensible way, like re-specifying the width of textboxen, add additional hiding panes etc. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Elegant powerful replacement for CSS
Malcolm Wallace malcolm.wall...@cs.york.ac.uk wrote: I would go with Bret Victor's argument (http://worrydream.com/ MagicInk/) that the concept of user interface as primarily _interaction_ is misguided. I tend to disagree. But then I'm a game developer, not an HTML monk... what definitely makes sense, though, is to divide the gui visually along presentation of the world vs. presentation of your interface to the world. presentation of your interface to the world subsumes such things as the marker on the minimap that shows which part you are looking at, and what tool you selected to interact with it (say zoom, smudge, paintbrush) -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Converting Lists to Sets
On Tue, 3 Feb 2009 19:58:51 -0200
rodrigo.bonifacio rodrigo.bonifa...@uol.com.br wrote:
Hi all,
I'm trying to use the Funsat library. One of its data types is CNF:
data CNF = CNF {
numVars :: Int
numClauses :: Int
clauses :: Set Clause
}
I have a list of clauses, but I'm getting an error when converting
such a list to a Set. Using the fromList function, the ghc compiler
reports that the fromList function is not applicable to literals.
type Clause = [Lit]
newtype Lit = L {
unLit :: Int
}
You don't provide your code or the exact error message, which makes
it harder to diagnose - but I'd guess you are mistakenly trying to apply
fromList to a *single* literal, rather than a *list* of literals.
--
Robin
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Converting Lists to Sets
Actually, a list of list of literals is needed, since it's a Set Clause, and
a Clause is a [Literal].
On Tue, Feb 3, 2009 at 5:24 PM, Robin Green gree...@greenrd.org wrote:
On Tue, 3 Feb 2009 19:58:51 -0200
rodrigo.bonifacio rodrigo.bonifa...@uol.com.br wrote:
Hi all,
I'm trying to use the Funsat library. One of its data types is CNF:
data CNF = CNF {
numVars :: Int
numClauses :: Int
clauses :: Set Clause
}
I have a list of clauses, but I'm getting an error when converting
such a list to a Set. Using the fromList function, the ghc compiler
reports that the fromList function is not applicable to literals.
type Clause = [Lit]
newtype Lit = L {
unLit :: Int
}
You don't provide your code or the exact error message, which makes
it harder to diagnose - but I'd guess you are mistakenly trying to apply
fromList to a *single* literal, rather than a *list* of literals.
--
Robin
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Ready for testing: Unicode support for Handle I/O
On Tue, Feb 03, 2009 at 10:56:13PM +, Duncan Coutts wrote: Thanks to suggestions from Duncan Coutts, it's possible to call hSetEncoding even on buffered read Handles, and the right thing happens. So we can read from text streams that include multiple encodings, such as an HTTP response or email message, without having to turn buffering off (though there is a penalty for switching encodings on a buffered Handle, as the IO system has to do some re-decoding to figure out where it should start reading from again). Sounds useful, but is this the bit that causes the 30% performance hit? No. You only pay that penalty if you switch encoding. The standard case has no extra cost. I'm confused. I thought the standard case was conversion to the system's local encoding? How is that different than selecting the same encoding manually? There always has to be *some* conversion from a 32-bit Char to the system's selection, right? What exactly do we have to do to avoid the penalty? No, I think that's 30% for latin1. The cost is not really the character conversion but the copying from a byte buffer via iconv to a char buffer. Don't we already have to copy between a byte buffer and a char buffer, since read() and write() use a byte buffer? 30% slower is a big deal, especially since we're not all that speedy now. Bear in mind that's talking about the [Char] interface, and nobody using that is expecting great performance. We already have an API for getting Yes, I know, but it's still the most convenient interface, and making it suck more isn't cool -- though there are certainly big wins here. -- John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Ready for testing: Unicode support for Handle I/O
On Tue, 2009-02-03 at 11:03 -0600, John Goerzen wrote: Will there also be something to handle the UTF-16 BOM marker? I'm not sure what the best API for that is, since it may or may not be present, but it should be considered -- and could perhaps help autodetect encoding. I think someone else mentioned this already, but utf16 (as opposed to utf16be/le) will use the BOM if its present. I'm not quite sure what happens when you switch encoding, presumably it'll accept and consider a BOM at that point. Thanks to suggestions from Duncan Coutts, it's possible to call hSetEncoding even on buffered read Handles, and the right thing happens. So we can read from text streams that include multiple encodings, such as an HTTP response or email message, without having to turn buffering off (though there is a penalty for switching encodings on a buffered Handle, as the IO system has to do some re-decoding to figure out where it should start reading from again). Sounds useful, but is this the bit that causes the 30% performance hit? No. You only pay that penalty if you switch encoding. The standard case has no extra cost. Performance is about 30% slower on hGetContents = putStr than before. I've profiled it, and about 25% of this is in doing the actual encoding/decoding, the rest is accounted for by the fact that we're shuffling around 32-bit chars rather than bytes in the Handle buffer, so there's not much we can do to improve this. Does this mean that if we set the encoding to latin1, tat we should see performance 5% worse than present? No, I think that's 30% for latin1. The cost is not really the character conversion but the copying from a byte buffer via iconv to a char buffer. 30% slower is a big deal, especially since we're not all that speedy now. Bear in mind that's talking about the [Char] interface, and nobody using that is expecting great performance. We already have an API for getting big chunks of bytes out of a Handle, with the new Handle we'll also want something equivalent for a packed text representation. Hopefully we can get something nice with the new text package. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Bytestrings vs String? parameters within package names?
Marc Weber wrote: wren ng thornton wrote: I'd just stick with one (with a module for hiding the conversions, as desired). Duplicating the code introduces too much room for maintenance and compatibility issues. That's the big thing. The more people that use ByteStrings the less need there is to convert when combining libraries. That said, ByteStrings aren't a panacea; lists and laziness are very useful. Hi wren, In the second paragraph you agree that there will be less onversion when using only one type of strings. You're also right about encoding. About laziness you'r partially right: There is also Bytestring.Lazy which is a basically a list of (non lazy) Bytestring Sure, but lazy bytestrings are still chunk-wise strict. Sometimes even that isn't lazy enough (more often with non-string kinds of lists, granted). -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Why binding to existing widget toolkits doesn't make any sense
CSS is purely declarative in nature and entirely deterministic. Moreover, it's expressive power is such that you can completely and radically alter the look of a website with modifications to CSS alone (see Zen Garden). The grammar and semantics are relatively simple and can be interpreted and generated by tools, which means that a designer can work with CSS files without knowing anything about CSS. Is it perfect? No. But it's a lot better than trying to encode everything in a single language that only a software developer can safely work with. Regards, John A. De Goes N-BRAIN, Inc. The Evolution of Collaboration http://www.n-brain.net|877-376-2724 x 101 On Feb 3, 2009, at 10:09 AM, Peter Verswyvelen wrote: On Tue, Feb 3, 2009 at 5:49 PM, John A. De Goes j...@n-brain.net wrote: I never said, CSS, I said like CSS. Oh, I missed the like word! What do you mean with that? What aspects of CSS do you prefer to? In WPF a style is basically just a bunch of attribute key/value pairs. Layout combinators in the spirit of TeX or Lout are more flexible while being simpler. In any case, a simple primitive grid :: [[Rect a]] - Rect a that arranges widgets in a rectangular grid should be enough for GUIs. Spoken like a true programmer who knows nothing about usability. :-) Yes, layout must be very versatile and user definable. Regards, John A. De Goes N-BRAIN, Inc. The Evolution of Collaboration http://www.n-brain.net|877-376-2724 x 101 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: #haskell-in-depth IRC channel
Well-done! I've said for many months that we need a channel like this! On Tue, Feb 3, 2009 at 7:15 PM, Philippa Cowderoy fli...@flippac.orgwrote: Hi folks. As I've been daft enough to get a few things rolling, it looks like it's fallen on me to announce the new IRC channel, #haskell-in-depth. #haskell has been a roaring success over the last few years, as Don has repeatedly pointed out. Unfortunately that roar is starting to make it hard for some to participate - there's so much traffic that it can be difficult to fit an additional conversation in. We're starting to hit the limits as to how far one channel can take us, and that means we need to explore ways to divide up traffic. Actually, this isn't entirely new - a number of years ago now, #haskell-blah was formed as a space for off-topic (and sometimes less-than-worksafe) conversation among #haskell regulars. We also created #haskell-overflow, but it doesn't see much use except among some of the cabal implementors because it's hard to know when to take the conversation you're currently in to -overflow. We need channels that people start their conversations in, not ones to send people to! So we're trying a space for in-depth discussion. The new channel is open to everyone, just like #haskell. But just as we're hoping for certain kinds of discussion, there're others we want to avoid. If you need to know how to use monads so you can do IO, #haskell-in-depth isn't the place. On the other hand, if you want to discuss how Haskell's monads compare to the category theory or what the category theory can tell us about how individual monads relate to the language as a whole, -in-depth is a good place! In particular, we're hoping that the kind of category theory discussions that give the mistaken impression you actually need to know CT will increasingly live in #haskell-in-depth. We're not after a theory channel though - architectural discussion, compiler implementation, possible type system extensions, library design, all are good subjects. Anyway, I shouldn't ramble on for too long here - #haskell-in-depth is open for business and we look forward to seeing you there! -- Philippa Cowderoy fli...@flippac.org ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why binding to existing widget toolkits doesn't make any sense
Nor does it need one: http://www.csszengarden.com/ Regards, John A. De Goes N-BRAIN, Inc. The Evolution of Collaboration http://www.n-brain.net|877-376-2724 x 101 On Feb 3, 2009, at 10:45 AM, Heinrich Apfelmus wrote: John A. De Goes wrote: Layout combinators in the spirit of TeX or Lout are more flexible while being simpler. In any case, a simple primitive grid :: [[Rect a]] - Rect a that arranges widgets in a rectangular grid should be enough for GUIs. Spoken like a true programmer who knows nothing about usability. :-) Hehe, well given that CSS doesn't even have such a primitive... :) Regards, apfelmus -- http://apfelmus.nfshost.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Elegant powerful replacement for CSS
Conal Elliott co...@conal.net wrote: [Spin-off from the haskell-cafe discussion on functional/denotational GUI toolkits] I've been wondering for a while now what a well-designed alternative to CSS could be, where well-designed would mean consistent, composable, orthogonal, functional, based on an elegantly compelling semantic model (denotational). I think a very important thing to keep in mind while investigating web-technologies for pointers is that Haskell already comes with XML and XSLT (in the disguise of ADT's and functions), and that CSS is often abused for operations that are in the domain of XSLT. I don't believe that it's possible to draw a clear destinction between concerns the programmer and concerns the designer. In fact, I get offended by the notion that I'm inherently incapable of distinguishing readable from unreadable text, and think that the notion of designers being unable to do anything but assembling a colourful collage of the data they're given is more of a self-fulfilling prophecy than a truth. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Elegant powerful replacement for CSS
On Tue, Feb 3, 2009 at 2:06 PM, Thomas Davie tom.da...@gmail.com wrote: On 3 Feb 2009, at 20:39, Conal Elliott wrote: [Spin-off from the haskell-cafe discussion on functional/denotational GUI toolkits] I've been wondering for a while now what a well-designed alternative to CSS could be, where well-designed would mean consistent, composable, orthogonal, functional, based on an elegantly compelling semantic model (denotational). Can I start by replacing html please :) I'd like to separate the document in roughly the same way as html and css attempt to, meaning I'd like a document description language, and a styling description language. I can imagine the styling language having the meaning function from documents onto geometry, but the document description language is harder. Ideally what I'd like to do with it is to make it describe *only* the logical structure of the information being conveyed – sections, text, figures, tables (no, not for layout, for tabular data) etc. This is easy to me. Everything is content. Sections, text, figures, tables -- these are all static content. Functions are interactive content. Numbers are content, as are lists of content, maybe content ... The interesting part is how you display it. In the simplest sense, a style is just a function Style a = a - Geometry. But work has been done, eg. with TVs, that have composition of content and composition of the display mirror each other. I'm not totally satisfied with TVs. For example, I think it's worth exploration describing *how* the content was composed, such that styling language maps compositions of content to compositions of geometry. Content is not interesting. The *mapping* from content to presentation is the important part. Luke ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANN: #haskell-in-depth IRC channel
Hi folks. As I've been daft enough to get a few things rolling, it looks like it's fallen on me to announce the new IRC channel, #haskell-in-depth. #haskell has been a roaring success over the last few years, as Don has repeatedly pointed out. Unfortunately that roar is starting to make it hard for some to participate - there's so much traffic that it can be difficult to fit an additional conversation in. We're starting to hit the limits as to how far one channel can take us, and that means we need to explore ways to divide up traffic. Actually, this isn't entirely new - a number of years ago now, #haskell-blah was formed as a space for off-topic (and sometimes less-than-worksafe) conversation among #haskell regulars. We also created #haskell-overflow, but it doesn't see much use except among some of the cabal implementors because it's hard to know when to take the conversation you're currently in to -overflow. We need channels that people start their conversations in, not ones to send people to! So we're trying a space for in-depth discussion. The new channel is open to everyone, just like #haskell. But just as we're hoping for certain kinds of discussion, there're others we want to avoid. If you need to know how to use monads so you can do IO, #haskell-in-depth isn't the place. On the other hand, if you want to discuss how Haskell's monads compare to the category theory or what the category theory can tell us about how individual monads relate to the language as a whole, -in-depth is a good place! In particular, we're hoping that the kind of category theory discussions that give the mistaken impression you actually need to know CT will increasingly live in #haskell-in-depth. We're not after a theory channel though - architectural discussion, compiler implementation, possible type system extensions, library design, all are good subjects. Anyway, I shouldn't ramble on for too long here - #haskell-in-depth is open for business and we look forward to seeing you there! -- Philippa Cowderoy fli...@flippac.org ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Elegant powerful replacement for CSS
amen amen! thanks, achim. On Tue, Feb 3, 2009 at 4:50 PM, Achim Schneider bars...@web.de wrote: Conal Elliott co...@conal.net wrote: [Spin-off from the haskell-cafe discussion on functional/denotational GUI toolkits] I've been wondering for a while now what a well-designed alternative to CSS could be, where well-designed would mean consistent, composable, orthogonal, functional, based on an elegantly compelling semantic model (denotational). I think a very important thing to keep in mind while investigating web-technologies for pointers is that Haskell already comes with XML and XSLT (in the disguise of ADT's and functions), and that CSS is often abused for operations that are in the domain of XSLT. I don't believe that it's possible to draw a clear destinction between concerns the programmer and concerns the designer. In fact, I get offended by the notion that I'm inherently incapable of distinguishing readable from unreadable text, and think that the notion of designers being unable to do anything but assembling a colourful collage of the data they're given is more of a self-fulfilling prophecy than a truth. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Purely funcional LU decomposition
Hi Rafael, 2009/2/3 Rafael Gustavo da Cunha Pereira Pinto rafaelgcpp.li...@gmail.com: Hello folks After a discussion on whether is possible to compile hmatrix in Windows, I decided to go crazy and do a LU decomposition entirely in Haskell... At first I thought it would be necessary to use a mutable or monadic version of Array, but then I figured out it is a purely interactive process. I am releasing this code fragment as LGPL. Pretty cool, thanks for releasing this into the wild. I remember looking into this about a year ago. By the way, have you seen Matt's DSP library? http://haskelldsp.sourceforge.net/ He's got LU and others in there, if my memory serves me. The last release seems to be 2003, so it might be worth emailing him to see what happened and if he has plans for the future. Regards, Paulo ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Ready for testing: Unicode support for Handle I/O
On Tue, 2009-02-03 at 17:39 -0600, John Goerzen wrote: On Tue, Feb 03, 2009 at 10:56:13PM +, Duncan Coutts wrote: Thanks to suggestions from Duncan Coutts, it's possible to call hSetEncoding even on buffered read Handles, and the right thing happens. So we can read from text streams that include multiple encodings, such as an HTTP response or email message, without having to turn buffering off (though there is a penalty for switching encodings on a buffered Handle, as the IO system has to do some re-decoding to figure out where it should start reading from again). Sounds useful, but is this the bit that causes the 30% performance hit? No. You only pay that penalty if you switch encoding. The standard case has no extra cost. I'm confused. I thought the standard case was conversion to the system's local encoding? How is that different than selecting the same encoding manually? Sorry, I think we've been talking at cross purposes. There always has to be *some* conversion from a 32-bit Char to the system's selection, right? Yes. In text mode there is always some conversion going on. Internally there is a byte buffer and a char buffer (ie UTF32). What exactly do we have to do to avoid the penalty? The penalty we're talking about here is not the cost of converting bytes to characters, it's in switching which encoding the Handle is using. For example you might read some HTTP headers in ASCII and then switch the Handle encoding to UTF8 to read some XML. Switching the Handle encoding has a penalty. We have to discard the characters that we pre-decoded and re-decode the byte buffer in the new encoding. It's actually slightly more complicated because we do not track exactly how the byte and character buffers relate to each other (it'd be too expensive in the normal cases) so to work out the relationship when switching encoding we have to re-decode all the way from the beginning of the current byte buffer. The point is, in terms of performance we get the ability to switch handle encoding more or less for free. It has a cost in terms of code complexity. The simpler alternative design was that you would not be able to switch encoding on a read handle that used any buffering at the character level without loosing bytes. The performance penalty when switching encoding is the downside to the ordinary code path being fast. No, I think that's 30% for latin1. The cost is not really the character conversion but the copying from a byte buffer via iconv to a char buffer. Don't we already have to copy between a byte buffer and a char buffer, since read() and write() use a byte buffer? In the existing Handle mechanism we read() into a byte buffer and then when doing say getLine or getContents we allocate [Char]'s in a loop reading bytes directly from the byte buffer. There is no separate character buffer. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] type metaphysics
Gregg Reynolds wrote: On Mon, Feb 2, 2009 at 2:25 PM, Ketil Malde ke...@malde.org wrote: Gregg Reynolds d...@mobileink.com writes: Just shorthand for something like data Tcon a = Dcon a, applied to Int. Any data constructor expression using an Int will yield a value of type Tcon Int. Right. But then the set of values is isomorphic to the set of Ints, right? The values constructed by that particular constructor, yes; good point. Isomorphic, but not the same. (And also, if we have a second constructor, what's our cardinality? The first one uses up all the integers, no? No. If we have the type (Either Integer Integer) we have W+W values. There's a tag to distinguish whether we chose the Left or Right variety of Integer, but having made that choice we still have the choice of any Integer. Thus, this type adds one extra bit to the size of the integers, doubling their cardinality. Which is why ADTs are often called sum--product types. Replacing products and coproducts with, er, products and summations we can talk about the cardinality of types (ignoring _|_): |()| = 1 |Bool| = 1 + 1 |Maybe N|= 1 + |N| |(N,M)| = |N| * |M| |Either N M| = |N| + |M| etc Really we're just changing the evaluation function for our ADT algebra. Extending things to GADTs, this is also the reason why functions are called exponential and denoted as such in category theory: |N - M| = |M| ^ |N| That's the number of functions that exist in that type. Not all of these are computable, however, as discussed elsewhere. -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Converting Lists to Sets
On Tue, Feb 3, 2009 at 14:58, rodrigo.bonifacio
rodrigo.bonifa...@uol.com.br wrote:
Hi all,
I'm trying to use the Funsat library. One of its data types is CNF:
data CNF = CNF {
numVars :: Int
numClauses :: Int
clauses :: Set Clause
}
I have a list of clauses, but I'm getting an error when converting such a
list to a Set. Using the fromList function, the ghc compiler reports that the
fromList function is not applicable to literals.
type Clause = [Lit]
newtype Lit = L {
unLit :: Int
}
So, my question is: How can I solve this problem?
Assuming your list of clauses, you just need Data.Set.fromList:
import qualified Data.Set as Set
clauses :: [Clause]
Set.fromList clauses :: Set Clause
Denis
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Ready for testing: Unicode support for Handle I/O
Duncan Coutts wrote: Sorry, I think we've been talking at cross purposes. I think so. There always has to be *some* conversion from a 32-bit Char to the system's selection, right? Yes. In text mode there is always some conversion going on. Internally there is a byte buffer and a char buffer (ie UTF32). What exactly do we have to do to avoid the penalty? The penalty we're talking about here is not the cost of converting bytes to characters, it's in switching which encoding the Handle is using. For example you might read some HTTP headers in ASCII and then switch the Handle encoding to UTF8 to read some XML. Simon referenced a 30% penalty. Are you saying that if we read from a Handle using the same encoding that we used when we first opened it, that we won't see any slowdown vs. the system in 6.10? Switching the Handle encoding has a penalty. We have to discard the characters that we pre-decoded and re-decode the byte buffer in the new encoding. It's actually slightly more complicated because we do not Got it. That makes sense, as does the decision to optimize for the more common (not switching the encoding) case. -- John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: ANN: #haskell-in-depth IRC channel
On Wed, 04 Feb 2009 00:15:48 +, Philippa Cowderoy fli...@flippac.org wrote: [...] If you need to know how to use monads so you can do IO, #haskell-in-depth isn't the place. On the other hand, if you want to discuss how Haskell's monads compare to the category theory or what the category theory can tell us about how individual monads relate to the language as a whole, -in-depth is a good place! In particular, we're hoping that the kind of category theory discussions that give the mistaken impression you actually need to know CT will increasingly live in #haskell-in-depth. We're not after a theory channel though - architectural discussion, compiler implementation, possible type system extensions, library design, all are good subjects. Great work! I look forward to participating sometime in the near future. In that case, for people who need to know how to use monads so that they can do IO, why not create a #haskell-beginners channel? I have occasionally read posts of some users who were hesitant to participate in #haskell until they learned enough to keep up with the discussions there. If neither #haskell nor #haskell-in-depth is appropriate, perhaps they would feel more comfortable in a Haskell-beginners-specific channel? -- Benjamin L. Russell -- Benjamin L. Russell / DekuDekuplex at Yahoo dot com http://dekudekuplex.wordpress.com/ Translator/Interpreter / Mobile: +011 81 80-3603-6725 Furuike ya, kawazu tobikomu mizu no oto. -- Matsuo Basho^ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] type metaphysics
On Tuesday 03 February 2009 9:05:08 pm wren ng thornton wrote: Extending things to GADTs, this is also the reason why functions are called exponential and denoted as such in category theory: |N - M| = |M| ^ |N| That's the number of functions that exist in that type. Not all of these are computable, however, as discussed elsewhere. This is all correct, except that exponentials are just part of algebraic data types, not generalized algebraic data types. Generalized algebraic data types are similar to inductive families, in that you can target constructors at specific type-indices, like so: data T t where I :: T Int P :: T a - T b - T (a,b) Both of those are genuine GADT constructors. There's also things like: E :: T a - T b - T b But those are doable by 'mere' ADTs plus existential quantification: data T b = ... | forall a. P (T a) (T b) -- Dan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: circular dependencies in cabal
Hi Duncan, I agree with your arguments. I think it is a less evil to disable 'cabal upgrade' until the problem is fixed. To have 'cabal upgrade' to ask for confirmation (and to allow user to select packages to be updated from the list) is even better. -- Valentyn. On Feb 3, 2009, at 2:04 AM, Duncan Coutts wrote: On Mon, 2009-02-02 at 19:16 -0800, Valentyn Kamyshenko wrote: Hi Duncan, The major problem that I see is with # cabal update # cabal upgrade sequence of operations (that is, upgrading all installed packages). Right, that's exactly what doesn't work well and that I'm proposing to temporarily disable. I use this regularly to keep packages that I use (or are going to use) up to date. This is the functionality that, I suppose, everybody expects from the system like hackage/cabal. And, so far as I can see, the major problem is that 'cabal upgrade' will happily upgrade packages, that the core package depends on, and eventually will create configuration with circular dependencies. Can we do something simple - like, for example, forbidding updates of the packages that the core depends on (directly and indirectly)? Yes and there are a couple of additional ways we could improve it. But I'm thinking it'd be better to release before those things are done, and so in the mean time disable upgrade. In the mean time we can make it list the available packages that are newer than the installed ones and you get to pick manually which ones are sensible to install. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: ANN: #haskell-in-depth IRC channel
On Wed, 2009-02-04 at 14:32 +0900, Benjamin L.Russell wrote: On Wed, 04 Feb 2009 00:15:48 +, Philippa Cowderoy fli...@flippac.org wrote: [...] If you need to know how to use monads so you can do IO, #haskell-in-depth isn't the place. On the other hand, if you want to discuss how Haskell's monads compare to the category theory or what the category theory can tell us about how individual monads relate to the language as a whole, -in-depth is a good place! In particular, we're hoping that the kind of category theory discussions that give the mistaken impression you actually need to know CT will increasingly live in #haskell-in-depth. We're not after a theory channel though - architectural discussion, compiler implementation, possible type system extensions, library design, all are good subjects. Great work! I look forward to participating sometime in the near future. In that case, for people who need to know how to use monads so that they can do IO, why not create a #haskell-beginners channel? I have occasionally read posts of some users who were hesitant to participate in #haskell until they learned enough to keep up with the discussions there. If neither #haskell nor #haskell-in-depth is appropriate, perhaps they would feel more comfortable in a Haskell-beginners-specific channel? Asking any Haskell-related question at any level is appropriate in #haskell, now as always. One of the implicit goals of the new channel is to minimize such intimidation. The explicit goal of the new channel is to increase the newbie friendliness of #haskell. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: ANN: #haskell-in-depth IRC channel
We explicitly want to avoid a newbie trap See the summary of the discussion that lead to the channel creation http://haskell.org/haskellwiki/IRC_channel/Phase_2 -- Don DekuDekuplex: On Wed, 04 Feb 2009 00:15:48 +, Philippa Cowderoy fli...@flippac.org wrote: [...] If you need to know how to use monads so you can do IO, #haskell-in-depth isn't the place. On the other hand, if you want to discuss how Haskell's monads compare to the category theory or what the category theory can tell us about how individual monads relate to the language as a whole, -in-depth is a good place! In particular, we're hoping that the kind of category theory discussions that give the mistaken impression you actually need to know CT will increasingly live in #haskell-in-depth. We're not after a theory channel though - architectural discussion, compiler implementation, possible type system extensions, library design, all are good subjects. Great work! I look forward to participating sometime in the near future. In that case, for people who need to know how to use monads so that they can do IO, why not create a #haskell-beginners channel? I have occasionally read posts of some users who were hesitant to participate in #haskell until they learned enough to keep up with the discussions there. If neither #haskell nor #haskell-in-depth is appropriate, perhaps they would feel more comfortable in a Haskell-beginners-specific channel? -- Benjamin L. Russell -- Benjamin L. Russell / DekuDekuplex at Yahoo dot com http://dekudekuplex.wordpress.com/ Translator/Interpreter / Mobile: +011 81 80-3603-6725 Furuike ya, kawazu tobikomu mizu no oto. -- Matsuo Basho^ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Purely funcional LU decomposition
On 3 Feb 2009, at 22:37, Rafael Gustavo da Cunha Pereira Pinto wrote: Hello folks After a discussion on whether is possible to compile hmatrix in Windows, I decided to go crazy and do a LU decomposition entirely in Haskell... At first I thought it would be necessary to use a mutable or monadic version of Array, but then I figured out it is a purely interactive process. I am releasing this code fragment as LGPL. Shinyness indeed – a quick note though, as ghc doesn't support dynamic linking of Haskell code, the above is equivalent to the GPL. Would be lovely if you packaged this up and stuck it on Hackage :) Bob___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Purely funcional LU decomposition
Array is no good man! Quad Tree matrices perform much nicer from what I've seen. I wrote some matrix stuff based on D. Stott Parker's Randomized Gaussian elimination papers (http://www.cs.ucla.edu/~stott/ge/). He presents some recursive block based methods of solving without pivoting. I want to upload the full library to Hackage, but it'd be nice to have some people look through it before - mainly because i never took linear algebra heh. QuickCheck seems to be holding things together though. Check these definitions (where the input matrix has been pre-transformed with the butterfly if needed -- revertRBT . invert . applyRBT): gauss (M.Scalar v) = (M.Scalar 1, M.Scalar v) gauss (M.Matrix (a,b,c,d)) = (M.Matrix (l, M.Scalar 0, x, l'), M.Matrix (u, y, M.Scalar 0, u')) where (l,u) = gauss a (l',u') = gauss $ d - (x * y) x = c * (invert u) y = (invert l) * b invert (M.Scalar v) = M.Scalar (1 / v) invert (M.Matrix (a,b,c,d)) = M.Matrix (w,x,y,z) where w = aI - (aIb * y) x = negate $ aIb * z y = negate $ z * caI z = invert $ d - (caI * b) --- aI = invert a caI = c * aI aIb = aI * b benchmarked against (in order of speed): 1. Mesa GL math in C called through FFI. 2. Finger tree based port. 3. Mutable array based port. 2 and 3 were scrapped right away. Heres some of the benchmark vs the C version. Matrix Inversion - 9x --- haskell ContextSwitches - 224017 First level fills = 0 Second level fills = 0 ETime( 0:00:41.328 ) UTime( 0:00:40.875 ) KTime( 0:00:00.000 ) ITime( 0:00:41.484 ) -- C --- ContextSwitches - 640016 First level fills = 0 Second level fills = 0 ETime( 0:01:56.109 ) UTime( 0:01:55.359 ) KTime( 0:00:00.000 ) ITime( 0:01:54.328 ) Matrix Inversion - 999x --- haskell ContextSwitches - 6204 First level fills = 0 Second level fills = 0 ETime( 0:00:00.687 ) UTime( 0:00:00.421 ) KTime( 0:00:00.000 ) ITime( 0:00:01.031 ) -- C --- ContextSwitches - 7396 First level fills = 0 Second level fills = 0 ETime( 0:00:01.171 ) UTime( 0:00:01.171 ) KTime( 0:00:00.000 ) ITime( 0:00:01.250 ) - Matrix multiplication - 9x - --- haskell ContextSwitches - 234644 First level fills = 0 Second level fills = 0 ETime( 0:00:42.093 ) UTime( 0:00:41.609 ) KTime( 0:00:00.000 ) ITime( 0:00:42.187 ) -- C --- ContextSwitches - 228596 First level fills = 0 Second level fills = 0 ETime( 0:00:41.609 ) UTime( 0:00:41.375 ) KTime( 0:00:00.000 ) ITime( 0:00:41.515 ) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
