[Haskell-cafe] ANN: Haskell BLAS bindings version 0.7
New version! The blas package is a set of bindings to the BLAS (Basic Linear Algebra Subprograms) library. On Hackage: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/blas-0.7 What's new: * Get rid of most functional dependencies in favor of type families. There is one remaining functional dependency that cannot be gotten rid of until GHC implements equality constraints in superclass contexts. * Put the right superclass constraints in ReadMatrix/ReadBanded. * Fix freeze/thaw functions. They used to be awkward to use. * Fix a bug in getting a row view of a banded matrix. * Make sure no NaNs/Infinities/Denormals are used when testing. * Documentation. * Export functions for writing QuickCheck tests. * Remove Perm and Diag. These will be in the LAPACK bindings. * Get rid of "UnsafeIOToM" type class. * Lots of INLINE everywhere. This will improve performance (?) * Switch to autoconf for build system. Requisite blog post: http://quantile95.com/2009/01/09/new-haskell-blas-bindings/ Not much example code. Here's some old stuff: http://github.com/patperry/blas/tree/master/examples/LU.hs Thanks for listening. Any feedback is always welcome. Patrick ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANN: Haskell BLAS bindings version 0.7
Here's the haddock documentation; I'm not sure if Hackage honors {-#
OPTIONS_HADDOCK hide #-} when it displays the exposed modules:
http://quantile95.com/blas/
Patrick
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: Haskell BLAS bindings version 0.7
2009/1/10 Patrick Perry :
> Here's the haddock documentation; I'm not sure if Hackage honors {-#
> OPTIONS_HADDOCK hide #-} when it displays the exposed modules:
>
> http://quantile95.com/blas/
It should, so If it doesn't then please tell us about it. We have a trac at:
http://trac.haskell.org/haddock/
David
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Issues with posix-realtime package
Galchin, Vasili ha scritto: Manlio, so compiling to native machine code works ok but if using ghci byte-code interpreter doesn't . can you supply your program please? Right. Can't you reproduce the problem? The program is very simple (I was just testing your package, since I suggested the use of clock_gettime to Mauricio in a previous post): import System.Posix.Realtime.RTTime import System.Posix.Realtime.RTDataTypes main = do time <- clockGetTime Clock_Monotonic; print $ tvSec time print $ tvNsec time runghc rttime.hs I suspect that this is a problem with shared library loading in ghci, since the C code you use for your package, is also used by the base package (for the Posix subsystem). By the way: I don't see reasons to add all that code, since it is not used. However, when I tried to remove all the unused code, executing the program gave me a stack exception (maybe I have removed too many things...). One personal note: I don't like `tvSec` and `tvNsec`, I think `seconds` and `nanoSeconds` is a better choice. Also, it would useful a function to compute elapsed time (maybe a general class in base package, and a specialized instance declaration in posix-realtime for the timespec?) Vasili > [...] Manlio ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: concurrent haskell: thread priorities
On Fri, Jan 9, 2009 at 8:22 PM, Don Stewart wrote: > Every time Simon responds on questions of parallelism and the GHC > runtime, I learn something. That indicates to me that we've got a 'bus > error' situation with how to effectively use the smp runtime. > > Simon: time for a multicore FAQ wiki page to gather this knowledge, like > we did for the performance tips? Somewhere to paste these insights? A few weeks ago, during the weekly GHC meeting, Simon explained the internals of the threading system to me. Among other things he explained how many threads are run per core, how they are load balanced and migrated between cores. I found it very enlightening. Maybe, that could serve as a basis for a GHCThreadingInternals wiki page. Is #ghc channel logged anywhere? Cheers, Johan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] data declarations should provide fold functions
I know the short-term answer is "use TH" to derive folds if I want them, but I think such an important concept should probably be part of the language. The fold function is an example of a generic program, which can be defined using generic programming libraries. Since the fold has to know about the recursive structure of a datatype, not all (actually, very few) generic programming libraries can be used to define a fold. An example of a recent library that can define folds is multirec (developed by our own group, blatant self promotion): http://hackage.haskell.org/cgi-bin/hackage-scripts/package/multirec A description of the library can be found in http://www.cs.uu.nl/research/techreps/UU-CS-2008-019.html Older generic programming approaches such as PolyP could define the fold too, be it only for so-called regular (non mutually recursive) datatypes. The multirec library defines folds for mutually recursive datatypes. The released version of multirec doesn't include the TH files for generating the boilerplate code (for example, embedding-projection pairs for datatypes) necessary for using the library. However, the head has TH support for this. All the best, Johan Jeuring Tim Newsham http://www.thenewsh.com/~newsham/ ___ 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] Looking for Haskellers on Windows
Hi all, I'm looking for Haskell programmer that use Windows as their OS-Plattform. I developing an application in Haskell on Windows and run into problems that seem to have a lower priority with the greater Haskell community as most of them are using Linux where the problems do not occur or are already solved. So it'd be nice to get in touch with other Haskellers that face the same problems. Günther ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Computer time, independent of date
Steve Schafer ha scritto: On Fri, 09 Jan 2009 09:28:49 -0600, you wrote: I'm not sure that the original question implied *that* level of need. I can't imagine being worried about leap seconds yet at the same time being willing to accept the potential vagaries of any of the built-in clocks. POSIX realtime extensions have been developed to be high reliable. I don't know if the implementations on general purpose operating systems like Linux are reliable, but in case of problems one can try to switch to a real time operating system. This resources may be useful: http://juliusdavies.ca/posix_clocks/clock_realtime_linux_faq.html Timing is, however, a complex issue. Steve Schafer Fenestra Technologies Corp. http://www.fenestra.com Manlio Perillo ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Looking for Haskellers on Windows
Hi Bulat, I do :), but I was amazed that there was no response to a post with, what I thought, would be a rather common problem for an application developer. That post was about writing to an MS-Access database via HDBC-ODBC, which fails. When I then asked the HDBC maintainer himself it turned out that he doesn't use Windows either and thus can't help. Thus my cry for help explicitly to Haskellers on Windows. Günther Am 10.01.2009, 15:18 Uhr, schrieb Bulat Ziganshin : Hello Günther, Saturday, January 10, 2009, 5:03:18 PM, you wrote: there are lot of windows haskellers so you can just write your questions in haskell-cafe Hi all, I'm looking for Haskell programmer that use Windows as their OS-Plattform. I developing an application in Haskell on Windows and run into problems that seem to have a lower priority with the greater Haskell community as most of them are using Linux where the problems do not occur or are already solved. So it'd be nice to get in touch with other Haskellers that face the same problems. Günther ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Erstellt mit Operas revolutionärem E-Mail-Modul: http://www.opera.com/mail/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[2]: [Haskell-cafe] Looking for Haskellers on Windows
Hello Günther, Saturday, January 10, 2009, 5:31:13 PM, you wrote: i think that problem is not shortage of windows developers among haskellers, but shortage of db developers :) > Hi Bulat, > I do :), but I was amazed that there was no response to a post with, what > I thought, would be a rather common problem for an application developer. > That post was about writing to an MS-Access database via HDBC-ODBC, which > fails. When I then asked the HDBC maintainer himself it turned out that he > doesn't use Windows either and thus can't help. > Thus my cry for help explicitly to Haskellers on Windows. > Günther > Am 10.01.2009, 15:18 Uhr, schrieb Bulat Ziganshin > : >> Hello Günther, >> >> Saturday, January 10, 2009, 5:03:18 PM, you wrote: >> >> there are lot of windows haskellers so you can just write your questions >> in >> haskell-cafe >> >>> Hi all, >> >>> I'm looking for Haskell programmer that use Windows as their >>> OS-Plattform. >>> I developing an application in Haskell on Windows and run into problems >>> that seem to have a lower priority with the greater Haskell community as >>> most of them are using Linux where the problems do not occur or are >>> already solved. >> >>> So it'd be nice to get in touch with other Haskellers that face the same >>> problems. >> >>> Günther >> >>> ___ >>> Haskell-Cafe mailing list >>> Haskell-Cafe@haskell.org >>> http://www.haskell.org/mailman/listinfo/haskell-cafe >> >> -- Best regards, Bulatmailto:bulat.zigans...@gmail.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Looking for Haskellers on Windows
I do have to ship things to Windows and so I have a small amount of interaction with that platform. This is, unfortunately, something we see all over open source environments. Python and Ruby lists both see posts like this from time to time. While it is important that the interests of Windows developers be represented -- I was myself surprised to discover that the UUID package only worked on Linux -- it would be unconstructive to carry out such discussions offlist. -- Jason Dusek ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Looking for Haskellers on Windows
Hi Jason, I don't mean to take this off-list at all. Quite the opposite, I just meant to draw the attention of other Haskellers who also use Windows and might feel a bit alone because of it. It certainly was my feeling, this is only for the windows specific Haskell stuff. Günther Am 10.01.2009, 15:54 Uhr, schrieb Jason Dusek : I do have to ship things to Windows and so I have a small amount of interaction with that platform. This is, unfortunately, something we see all over open source environments. Python and Ruby lists both see posts like this from time to time. While it is important that the interests of Windows developers be represented -- I was myself surprised to discover that the UUID package only worked on Linux -- it would be unconstructive to carry out such discussions offlist. -- Jason Dusek -- Erstellt mit Operas revolutionärem E-Mail-Modul: http://www.opera.com/mail/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Looking for Haskellers on Windows
Hi Kyra, thanks for your reply. The problem I was facing is using an MS-Access backend with HDBC-ODBC. I try to export data to MS-Access and I can't get it to work. Otherwise HDBC works fine in other parts of my app but with MS-Access it blows up. I did of course post this on the haskell-cafe list first, but no response and the HDBC package maintainer himself was unable to help too since he's not using Windows. Günther Am 10.01.2009, 15:48 Uhr, schrieb kyra : GЭnther Schmidt wrote: Hi all, I'm looking for Haskell programmer that use Windows as their OS-Plattform. I developing an application in Haskell on Windows and run into problems that seem to have a lower priority with the greater Haskell community as most of them are using Linux where the problems do not occur or are already solved. So it'd be nice to get in touch with other Haskellers that face the same problems. GЭnther I don't know what problems You are talking about, but, since Windows is my development platform and I'm a haskeller, I hope to be able to help You. What problems are your facing? Kyra -- Erstellt mit Operas revolutionärem E-Mail-Modul: http://www.opera.com/mail/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Monads aren't evil
Related to this issue, I have a question here. I might be wrong, but it seems to me that some Haskellers don't like writing monads (with do notation) or arrows (with proc sugar) because of the fact they have to abandon the typical applicative syntax, which is so close to the beautiful lambda calculus core. Or is it maybe because some people choose monads were the less linear applicative style could be used instead, so the choice of monads is not always appropriate. Haskell is full of little hardcoded syntax extensions: list notation syntactic, list comprehensions, and even operator precedence that reduces the need for parentheses, etc... Of course IMHO the syntactic sugar is needed, e.g. a Yampa game written without the arrows syntax would be incomprehensible for the average programmer. But one could claim that this syntactic sugar hides what is really going on under the hood, so for newcomers these extensions might make it harder. It could also feel like a hack, a failure to keep things as simple as possible yet elegant. Some people I talked with like that about the Scheme/ & LISP languages: the syntax remains ultimately close to the core, with very little hardcoded syntactic extensions. And when one wants to add syntactic extensions, one uses syntactic macros. I'm not sure what others feel about the hardcoded syntax extensions in Haskell... Personally I'm not that much of a purist, I'm an old school hacker that mainly needs to get the job done. I like the syntax extensions in Haskell (and even C#/F# ;) because they let me write code shorter and clearer... On Fri, Jan 9, 2009 at 4:07 AM, Neal Alexander wrote: > Ertugrul Soeylemez wrote: > >> Hello fellow Haskellers, >> >> When I read questions from Haskell beginners, it somehow seems like they >> try to avoid monads and view them as a last resort, if there is no easy >> non-monadic way. I'm really sure that the cause for this is that most >> tutorials deal with monads very sparingly and mostly in the context of >> input/output. Also usually monads are associated with the do-notation, >> which makes them appear even more special, although there is really >> nothing special about them. >> >> > Yea, i was the same way when i started learning Haskell. I understood how > Monads worked, and what the motivation was for them, but not why i would > want to restructure code to use them in specific instances. > > "Why should i care about monads when i can use Arrows or (.)" was also a > factor. > > Its kinda like getting advice from an adult as a child. You have no > particular reason to distrust the advice, but the value of it doesn't set in > until something happens to you first hand to verify it. > > For me the turning point was writing some code that needed to handle > running code locally/remotely in a transparent manner. > > Maybe having a list of real-world usage scenarios or exercises on the wiki > may help. > > > __ _ > 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 BLAS bindings version 0.7
Hi David,
The problem is with Hackage, not with haddock.
Patrick
On Jan 10, 2009, at 3:38 AM, David Waern wrote:
2009/1/10 Patrick Perry :
Here's the haddock documentation; I'm not sure if Hackage honors {-#
OPTIONS_HADDOCK hide #-} when it displays the exposed modules:
http://quantile95.com/blas/
It should, so If it doesn't then please tell us about it. We have a
trac at:
http://trac.haskell.org/haddock/
David
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: Haskell BLAS bindings version 0.7
On Sat, Jan 10, 2009 at 02:46:05AM -0800, Patrick Perry wrote:
> Here's the haddock documentation; I'm not sure if Hackage honors {-#
> OPTIONS_HADDOCK hide #-} when it displays the exposed modules:
>
> http://quantile95.com/blas/
Who do you want the same modules to be both exposed and hidden?
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Looking for Haskellers on Windows
Hi Kyra,
and again, thanks for taking the effort.
Kyra I've tried any sort of values to any sort of columns. I tried "insert
into somesinglecolumntable (someNumbercolumn) values (?)" [toSql 5] ...
and so on.
So I'm not certain at all the error message does actually give the right
clue.
It just blows no matter what.
What does work though is this:
run dbc "insert into sometable (someVarcharcolumn) values ('some string
value')" []
This would be a workaround for my app, but I hope I can do better.
Günther
Am 10.01.2009, 17:01 Uhr, schrieb kyra :
Günther Schmidt wrote:
Hi Kyra,
thanks for your reply.
The problem I was facing is using an MS-Access backend with HDBC-ODBC.
I try to export data to MS-Access and I can't get it to work. Otherwise
HDBC works fine in other parts of my app but with MS-Access it blows up.
I did of course post this on the haskell-cafe list first, but no
response and the HDBC package maintainer himself was unable to help too
since he's not using Windows.
I've looked at Your problem now. What is the type of that single field
in 'mytable'? Google shows numerous similar cases, e.g. for date or memo
fields, that Access don't accept varchars and require longvarchars for.
I'm in no way an Access expert.
Cheers,
Kyra
--
Erstellt mit Operas revolutionärem E-Mail-Modul: http://www.opera.com/mail/
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: Haskell BLAS bindings version 0.7
2009/1/10 Patrick Perry : > Hi David, > > The problem is with Hackage, not with haddock. Oops, Sorry. I misread Hackage as Haddock :) David ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell not ready for Foo [was: Re: Hypothetical Haskell job in New York]
Hi John, Take two examples I gave up getting to work: a Haskell wrapper for a popular GUI library; and a Haskell wrapper for a database. I understand the former has a new team of developers, so perhaps it's time to revisit the library. Then again, writing 5000 line GUIs in an imperative style in a Haskell program just doesn't seem very appealing to me. And that's one of the problem with FFI-based libraries: it exposes the functionality (when it works), but in a strictly imperative way. Selection bias applies to us both. To quote myself, "Which means your statements come from your experience, and my statements come from my experience, and the truth is probably somewhere in between." Regards, John On Jan 9, 2009, at 1:42 PM, John Goerzen wrote: John A. De Goes wrote: Hi Austin, How do you know it's not your experience with FFI code that isn't biased? As far as I know, there has been no systematic attempt to document whether pure Haskell or FFI-based libraries are better designed and better maintained. Which means your statements come from your experience, and my statements come from my experience, and the truth is probably somewhere in between. In my experience, FFI code is often based on bulk translation of C header files into the IO monad. It requires an exact version of a library to work (usually much older than the current), it does not compile out of the box, there's scant documentation, and very little high-level design has been imposed on the low-level C interface (may as well use C!). Exceptions to this rule, there are, but as I said before, my experience leads me to believe they *are* exceptions to a *general* rule. Which libraries are you talking about? I haven't ever used *any* like that, as far as I know. Current libraries almost always do build right out of the box with standard cabal commands. Maybe part of what you state was accurate a few years ago, but right now? As far as selection bias is concerned, that would apply equally well to both of us, would it not? -- John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell not ready for Foo [was: Re: Hypothetical Haskell job in New York]
On Jan 9, 2009, at 9:01 AM, Creighton Hogg wrote: 2009/1/9 John A. De Goes : If you're looking for a project to take on, I would suggest starting with the following: A high-level, type-safe AMQP client written in 100% Haskell, which provides a clean way of handling hundreds of unique message types. Then it would be possible to hook it up to any AMQP broker (most likely RabbitMQ). There are logical steps beyond the above (an embedded Haskell broker), but the above project is far from trivial. And the main undertaking, I think, consists not in coding to the spec (for which there is some help; a JSON representation of the AMQP specification can be processed and used to emit language-specific code), but in finding a design that works well in Haskell. I apologize, but my question was geared more towards understanding what high-level OTP-like libraries Haskell is lacking, not full blown applications that haven't been written in Haskell. It sounded like you had some specific insight into this. A Haskell AMQP client is not an application, but a library that Haskell applications would use (if it existed). The use of the word "client" refers to the client/server metaphor used in centralized message broker systems like AMQP. Regarding the OTP specifically, Haskell doesn't have anything like it. Haskell has bits and pieces, but they're not integrated in a single stack, and much functionality is missing. For example, there's no way to dynamically poke running Haskell code, to see what it's doing; no way to update code on the fly as a process is running; no scalable distributed database system; etc. Regards, John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: Haskell BLAS bindings version 0.7
The reason I want to expose modules but hide the documentation is because there are a lot of "unsafeX" functions I want to provide access to, but which 99% of users don't care about. The array library does the same thing. Patrick ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell not ready for Foo [was: Re: Hypothetical Haskell job in New York]
On Jan 9, 2009, at 8:23 AM, John Goerzen wrote: Well, you pretty much always have to get down to the C level on a *nix platform at some point, anyhow. You've got to make syscalls somewhere. Take a language like Ruby or Python (or Java, or C#, etc.). The vast majority of code written in these languages does not "get down to the C level". When I say, "vast majority", I'm referring to > 99.999%. That's because the standard libraries provide sufficiently comprehensive platform-agnostic abstractions to do what most people need to do. As a result, libraries for these languages are built on the standard libraries, and do not require native code. I don't think FFI is so evil. There is value in avoiding wheel reinvention, too. If zlib already works great, why re-invent it when you can easily just use what's there? There are lots of reasons: 1. If there's a bug in a library, Haskellers are more likely to fix the bug if the library is written in Haskell. 2. Haskellers are more likely to improve code that is written in Haskell. 3. A chain is only as strong as its weakest link -- libraries with more dependencies are more fragile, more likely to break, and less likely to work across platforms. 4. Haskell-only libraries are easier to build, easy to use, and easier to include in your program (this is subjective and we don't agree on this one, so ignore it if you like). 5. Haskell libraries are generally more commercial friendly than the GNU-licensed libraries that inevitably back FFI-based libraries. 6. Haskell libraries can more easily offer tight integration with Haskell code, and take advantage of features unique to Haskell, such as purity and laziness, and a declarative coding style. A shining role model is the Java ecosystem. No platform has as many open source, commercial-friendly, robust, feature-rich, and community- supported libraries than Java does. These libraries are, in the vast majority of cases, written in 100% Java, work identically on all platforms, are as easy to use as adding a single file to your project (Java also has Maven, which functions similarly to Cabal). That's where I'd like Haskell to be in 5 years. Regards, John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: Haskell BLAS bindings version 0.7
Why don't you put them into a separate non-hidden Unsafe module and provide documentation for it? Users who don't care simply won't look there, whereas users who do care (for whom you are providing access) will still have a possibility to do so. 2009/1/10 Patrick Perry : > The reason I want to expose modules but hide the documentation is because > there are a lot of "unsafeX" functions I want to provide access to, but > which 99% of users don't care about. The array library does the same thing. > > > Patrick > > ___ > 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] Haskell not ready for Foo [was: Re: Hypothetical Haskell job in New York]
John A. De Goes wrote: > > Hi John, > > Take two examples I gave up getting to work: a Haskell wrapper for a > popular GUI library; and a Haskell wrapper for a database. I understand Is this database HDBC? If so, then I would appreciate detailed description of your problem so I can address it. If not, do you have the same criticism of HDBC? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Looking for Haskellers on Windows
Günther Schmidt wrote:
> Hi Kyra,
>
> and again, thanks for taking the effort.
>
> Kyra I've tried any sort of values to any sort of columns. I tried "insert
> into somesinglecolumntable (someNumbercolumn) values (?)" [toSql 5] ...
> and so on.
>
> So I'm not certain at all the error message does actually give the right
> clue.
>
> It just blows no matter what.
>
> What does work though is this:
>
> run dbc "insert into sometable (someVarcharcolumn) values ('some string
>
> value')" []
It is probably good to avoid this. HDBC does not provide SQL string
escaping functions because it is designed around the model of the
replacable parameters, which are more secure and more performant. You
will have to be very careful to sanitize input if you do take this approach.
As to the larger question, there are quite a few Windows Haskell users
out there. Some well-known Haskell personalities work for a division of
Microsoft, even.
I am not sure that there are all that many people talking to Access
databases via ODBC to start with, though, but of course if anybody has a
patch to contribute, I'd be happy to apply it.
-- John
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell not ready for Foo [was: Re: Hypothetical Haskell job in New York]
No, it's not HDBC -- which I have not yet tried. I'll tell you what: I'll give HDBC a try this week and let you know if it's as easy as you say it is. :-) Regards, John On Jan 10, 2009, at 10:09 AM, John Goerzen wrote: John A. De Goes wrote: Hi John, Take two examples I gave up getting to work: a Haskell wrapper for a popular GUI library; and a Haskell wrapper for a database. I understand Is this database HDBC? If so, then I would appreciate detailed description of your problem so I can address it. If not, do you have the same criticism of HDBC? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Shared library creating on Mac OS X
I¹ve made a bit of progress here after reading up on Darwin¹s GCC a bit more: ghc --make -no-hs-main -fPIC -optl '-dynamiclib' -optl '-undefined' -optl 'suppress' -optl '-flat_namespace' -o Inv.dylib InverseNormal.hs This dies when it links against haskell¹s own libraries, my guess is because they are position dependant. So the only way I see forward would be to recompile haskell with ³fPIC². This seems like a lot of hassle, so I¹m shelving this for now if anyone has any other (less distruptive) ways to proceed give me a shout even if it means linking statically. Cheers, Phil. Linker error now is: ld: warning codegen with reference kind 13 in _stg_CAF_BLACKHOLE_info prevents image from loading in dyld shared cache ld: absolute addressing (perhaps -mdynamic-no-pic) used in ___stginit_haskell98_Array_ from /usr/local/ghc/6.10.1/lib/ghc-6.10.1/haskell98-1.0.1.0/libHShaskell98-1.0.1. 0.a(Array__1.o) not allowed in slidable image collect2: ld returned 1 exit status On 10/01/2009 02:26, "Phil" wrote: > Hi, > > I¹m hitting a problem trying create shared haskell libs to be linked into a C > program on Mac OS X. > > I¹m using the latest download for Leopard from the GHC page: > http://www.haskell.org/ghc/dist/6.10.1/witten/ghc-6.10.1-powerpc-apple-darwin. > tar.bz2 > > I can get basic executables working fine (with a C main() #including ghc¹s > stub header), using something like: > ghc -optc-O invnorm.c InverseNormal.o InverseNormal_stub.o -o cTest > > I started off using the following line to try to create a shared lib: > > ghc --make -no-hs-main -optl '-shared' -o Inv.so InverseNormal.hs > > This doesn¹t work on mac os x because Apple¹s gcc annoyingly takes different > switches, so I changed it to: > > ghc --make -no-hs-main -optl '-dynamiclib' -o Inv.dylib InverseNormal.hs > > Which still fails at the final link giving: > > Linking Inv.dylib ... > Undefined symbols: > "_environ", referenced from: > _environ$non_lazy_ptr in libHSbase-4.0.0.0.a(PrelIOUtils.o) > ld: symbol(s) not found > > I¹ve seen similar things before, and I believe if you have full control over > the source you just slip in a: > > #define environ (*_NSGetEnviron()) > > Sure enough, I can find references to environ in, for example HsBase.h > > Problem (as I see it) is that references to environ are already wrapped up in > the static lib libHSbase-4.0.0.0.a, so without recompiling Haskell we can¹t > alter the C definition now. However, given that packager must have made this > behave when he compiled the distribution there must be a way to make Mac gcc > accept _envrion symbols?? > > Has anyone seen this before / can confirm my analysis / and by any chance have > a solution? > > Many thanks, > > Phil. > > ___ > 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: Computer time, independent of date
On Sat, 10 Jan 2009 15:04:36 +0100, you wrote: >POSIX realtime extensions have been developed to be high reliable. I think people are missing the details here. Yes, the built-in real-time clocks have excellent long-term accuracy. They run UTC-based correction algorithms using NTP, and are thus traceable to TAI. However, they offer no guarantees on interval measurements, and the correction algorithms can cause the measurement of a time interval of an hour or so duration to be off by +/- 1 sec, especially within the first few hours after a cold boot. If you care about leap seconds, you should certainly care about that magnitude of error. Steve Schafer Fenestra Technologies Corp. http://www.fenestra.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Looking for Haskellers on Windows
Hi John,
thx for responding :)
I'm trying to analyze the HDBC code so that, maybe, I'm able to find the
spot that's causing me trouble.
Do you happen to have some documentation on how you desigend this?
Also while digging through the code I learned some stuff that I found
quite interessting. As an example I found the function "executeMany" to be
part of a data declaration, now that's certainly something I as a newbie
have never seen before, is there a special name for this technique?
Günther
Am 10.01.2009, 18:12 Uhr, schrieb John Goerzen :
Günther Schmidt wrote:
Hi Kyra,
and again, thanks for taking the effort.
Kyra I've tried any sort of values to any sort of columns. I tried
"insert
into somesinglecolumntable (someNumbercolumn) values (?)" [toSql 5] ...
and so on.
So I'm not certain at all the error message does actually give the right
clue.
It just blows no matter what.
What does work though is this:
run dbc "insert into sometable (someVarcharcolumn) values ('some string
value')" []
It is probably good to avoid this. HDBC does not provide SQL string
escaping functions because it is designed around the model of the
replacable parameters, which are more secure and more performant. You
will have to be very careful to sanitize input if you do take this
approach.
As to the larger question, there are quite a few Windows Haskell users
out there. Some well-known Haskell personalities work for a division of
Microsoft, even.
I am not sure that there are all that many people talking to Access
databases via ODBC to start with, though, but of course if anybody has a
patch to contribute, I'd be happy to apply it.
-- John
--
Erstellt mit Operas revolutionärem E-Mail-Modul: http://www.opera.com/mail/
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] teaching functional programming at work
Thank you all for your responses on this. These ideas/materials are very helpful. In particular, the John Harrison book looks excellent (http://www.cl.cam.ac.uk/teaching/Lectures/funprog-jrh-1996/index.html ) -- a comprehensive and understandable introduction to all the concepts I had in mind. (I'm not sure what my audience's attention span will be though.) The WhyFP paper is also very good, although doesn't go into monads or types, it does a good job of illustrating modularity/composability. I'll send an update if this study group gets off the ground, to let you all know how it worked out. Warren___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Looking for Haskellers on Windows
Günther Schmidt wrote: Hi Bulat, I do :), but I was amazed that there was no response to a post with, what I thought, would be a rather common problem for an application developer. That post was about writing to an MS-Access database via HDBC-ODBC, which fails. When I then asked the HDBC maintainer himself it turned out that he doesn't use Windows either and thus can't help. Thus my cry for help explicitly to Haskellers on Windows. If you managed to get HDBC-ODBC to compile on Windows in the first place, you got further than me... It's a pitty that Windows receives so little support, but I guess if nobody has a Windows box to test with, there's not much you can do about it. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell not ready for Foo [was: Re: Hypothetical Haskell job in New York]
john: > On Jan 9, 2009, at 9:01 AM, Creighton Hogg wrote: > >2009/1/9 John A. De Goes : > >> > >>If you're looking for a project to take on, I would suggest > >>starting with > >>the following: > >> > >>A high-level, type-safe AMQP client written in 100% Haskell, which > >>provides > >>a clean way of handling hundreds of unique message types. > >> > >>Then it would be possible to hook it up to any AMQP broker (most > >>likely > >>RabbitMQ). There are logical steps beyond the above (an embedded > >>Haskell > >>broker), but the above project is far from trivial. And the main > >>undertaking, I think, consists not in coding to the spec (for which > >>there is > >>some help; a JSON representation of the AMQP specification can be > >>processed > >>and used to emit language-specific code), but in finding a design > >>that works > >>well in Haskell. > > > >I apologize, but my question was geared more towards understanding > >what high-level OTP-like libraries Haskell is lacking, not full blown > >applications that haven't been written in Haskell. It sounded like > >you had some specific insight into this. > > > A Haskell AMQP client is not an application, but a library that > Haskell applications would use (if it existed). The use of the word > "client" refers to the client/server metaphor used in centralized > message broker systems like AMQP. > > Regarding the OTP specifically, Haskell doesn't have anything like it. > Haskell has bits and pieces, but they're not integrated in a single > stack, and much functionality is missing. For example, there's no way > to dynamically poke running Haskell code, to see what it's doing; no > way to update code on the fly as a process is running; no scalable > distributed database system; etc. There are at least two ways to do dynamic code update, via compiled code, and via bytecode. -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: Haskell BLAS bindings version 0.7
Thanks for the suggestion! Done and uploaded to hackage. Patrick On Jan 10, 2009, at 9:07 AM, Eugene Kirpichov wrote: Why don't you put them into a separate non-hidden Unsafe module and provide documentation for it? Users who don't care simply won't look there, whereas users who do care (for whom you are providing access) will still have a possibility to do so. 2009/1/10 Patrick Perry : The reason I want to expose modules but hide the documentation is because there are a lot of "unsafeX" functions I want to provide access to, but which 99% of users don't care about. The array library does the same thing. Patrick ___ 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] Looking for Haskellers on Windows
John Goerzen wrote:
GЭnther Schmidt wrote:
Kyra I've tried any sort of values to any sort of columns. I tried "insert
into somesinglecolumntable (someNumbercolumn) values (?)" [toSql 5] ...
and so on.
So I'm not certain at all the error message does actually give the right
clue.
It just blows no matter what.
It seems, I've managed to track down the issue.
Access ODBC driver doesn't support sqlDescribeParam.
bindCol (Database/HDBC/ODBC/Statement.hsc) contains the following stub
for this:
do poke pdtype #{const SQL_CHAR}
poke pcolsize 0
poke pdecdigits 0
This does not work.
I've made an experiment replacing 'poke pcolsize 0' with 'poke pcolsize
255'. Now all integer or varchar bindings work!
It seems simpleSqlColumns or something similar must be used.
Cheers,
Kyra
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Looking for Haskellers on Windows
Andrew, even moral support is welcome. I'm on WinXP Pro here, using ghc 6.8.3, and cabal install. Maybe I can help with the installation problem, what did you do so far? Günther Am 10.01.2009, 15:38 Uhr, schrieb Andrew Coppin : Günther Schmidt wrote: Hi Bulat, I do :), but I was amazed that there was no response to a post with, what I thought, would be a rather common problem for an application developer. That post was about writing to an MS-Access database via HDBC-ODBC, which fails. When I then asked the HDBC maintainer himself it turned out that he doesn't use Windows either and thus can't help. Thus my cry for help explicitly to Haskellers on Windows. If you managed to get HDBC-ODBC to compile on Windows in the first place, you got further than me... It's a pitty that Windows receives so little support, but I guess if nobody has a Windows box to test with, there's not much you can do about it. -- Erstellt mit Operas revolutionärem E-Mail-Modul: http://www.opera.com/mail/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Looking for Haskellers on Windows
redcom: > Hi all, > > I'm looking for Haskell programmer that use Windows as their OS-Plattform. > I developing an application in Haskell on Windows and run into problems > that seem to have a lower priority with the greater Haskell community as > most of them are using Linux where the problems do not occur or are > already solved. > > So it'd be nice to get in touch with other Haskellers that face the same > problems. > Galois ships apps on Windows. We've developed windows installers and howtos for Haskell on Windows in the past, http://hackage.haskell.org/cgi-bin/hackage-scripts/package/bamse and this week, how to use a GMP DLL on Windows, http://haskell.forkio.com/gmpwindows There is a lack of a coherent 'Windows platform' as we have on the unix distros though, unfortunately. -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Looking for Haskellers on Windows
Kyra,
that is fantastic new!
Victory is near, I can smell it hahahahahahahaha ...
Um, sry for that, I'm just really really happy and glad I made that post
today. I've been trying to get this issue resolved for more than 14 days
now and if now solution had shown up on the horizon I would have been
forced to dump Haskell and do it all over again in Smalltalk and really
quick on top of it because the final deadline is Jan 19.
The app is 95 % finished and really all that is missing is the bloody
export to Access.
Thank you very very much.
Günther
Am 10.01.2009, 19:48 Uhr, schrieb kyra :
John Goerzen wrote:
GЭnther Schmidt wrote:
Kyra I've tried any sort of values to any sort of columns. I tried
"insert into somesinglecolumntable (someNumbercolumn) values (?)"
[toSql 5] ... and so on.
So I'm not certain at all the error message does actually give the
right clue.
It just blows no matter what.
It seems, I've managed to track down the issue.
Access ODBC driver doesn't support sqlDescribeParam.
bindCol (Database/HDBC/ODBC/Statement.hsc) contains the following stub
for this:
do poke pdtype #{const SQL_CHAR}
poke pcolsize 0
poke pdecdigits 0
This does not work.
I've made an experiment replacing 'poke pcolsize 0' with 'poke pcolsize
255'. Now all integer or varchar bindings work!
It seems simpleSqlColumns or something similar must be used.
Cheers,
Kyra
--
Erstellt mit Operas revolutionärem E-Mail-Modul: http://www.opera.com/mail/
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Monads aren't evil
My issue is that there seem to be many cases where the syntax extension does *almost* what I want, but not quite. And there isn't any method to extend it, so you are left with two choices: (1) Go back to unsugared syntax (2) Hack your technique into the constraints of the existing syntax extension. For example, "fail" is in the Monad class only because binding in "do" needs to handle pattern-match failure. But a better syntax extension wouldn't tie "do" to Monad only; it would allow pattern match failure to be handled by a separate class if needed, and allow additional extensions to deal with other cases where the existing syntax isn't quite good enough. This is where lisp-style syntactic macros show their real power. I'd go to TH but there's no way to make TH transparent. I almost wish that do ... and similar notations would just call a TH function to decode the expression! Then, if I wanted a different decoding I could just put a different "sugarDoNotation" function in scope. On a related note, I hate the explosion of <*>, <$>, liftM, etc. when working in monadic/applicative code. Often the code only typechecks with these lifting operators present, so why am I explaining to the compiler that I want it to use the applicative apply operator? When is strong typing going to help me write *less* code instead of *more*? We've solved the "type annotation" problem to my satisfaction via inference, but there is still a lot of what I would call "source annotation". For example, which of these is easier to read? f,g :: Int -> [Int] h1 :: Int -> [Int] h1 x = do fx <- f x gx <- g x return (fx + gx) h2 :: Int -> [Int] h2 x = (+) <$> f x <*> g x h3 :: Int -> [Int] h3 x = f x + g x -- not legal, of course, but wouldn't it be nice if it was? Of course this raises problems of order of evaluation, etc, but as long as such things were well-defined, that seems fine. If you want finer control, you can always go back to more verbose syntax. These cases are dominated by the cases where you simply don't care! This said, I don't want to sound overly negative; all of this pain is *worth* the correctness guarantees that I get when writing in Haskell. I just wish I could get the same guarantees with less pain! -- ryan 2009/1/10 Peter Verswyvelen : > Related to this issue, I have a question here. > I might be wrong, but it seems to me that some Haskellers don't like > writing monads (with do notation) or arrows (with proc sugar) because of the > fact they have to abandon the typical applicative syntax, which is so close > to the beautiful lambda calculus core. Or is it maybe because some people > choose monads were the less linear applicative style could be used instead, > so the choice of monads is not always appropriate. > Haskell is full of little hardcoded syntax extensions: list notation > syntactic, list comprehensions, and even operator precedence that reduces > the need for parentheses, etc... > > Of course IMHO the syntactic sugar is needed, e.g. a Yampa game written > without the arrows syntax would be incomprehensible for the average > programmer. But one could claim that this syntactic sugar hides what is > really going on under the hood, so for newcomers these extensions might make > it harder. It could also feel like a hack, a failure to keep things as > simple as possible yet elegant. > Some people I talked with like that about the Scheme/ & LISP languages: the > syntax remains ultimately close to the core, with very little hardcoded > syntactic extensions. And when one wants to add syntactic extensions, one > uses syntactic macros. > I'm not sure what others feel about the hardcoded syntax extensions in > Haskell... > > Personally I'm not that much of a purist, I'm an old school hacker that > mainly needs to get the job done. I like the syntax extensions in Haskell > (and even C#/F# ;) because they let me write code shorter and clearer... > On Fri, Jan 9, 2009 at 4:07 AM, Neal Alexander > wrote: >> >> Ertugrul Soeylemez wrote: >>> >>> Hello fellow Haskellers, >>> >>> When I read questions from Haskell beginners, it somehow seems like they >>> try to avoid monads and view them as a last resort, if there is no easy >>> non-monadic way. I'm really sure that the cause for this is that most >>> tutorials deal with monads very sparingly and mostly in the context of >>> input/output. Also usually monads are associated with the do-notation, >>> which makes them appear even more special, although there is really >>> nothing special about them. >>> >> >> Yea, i was the same way when i started learning Haskell. I understood how >> Monads worked, and what the motivation was for them, but not why i would >> want to restructure code to use them in specific instances. >> >> "Why should i care about monads when i can use Arrows or (.)" was also a >> factor. >> >> Its kinda like getting advice from an adult as a child. You have no >> particular reason to distrust the advice, but the value
[Haskell-cafe] Re: Looking for Haskellers on Windows
Hi Bulat, (...) Thus my cry for help explicitly to Haskellers on Windows. (...) It's a pitty that Windows receives so little support, but I guess if nobody has a Windows box to test with, there's not much you can do about it. I think it deserves consideration: what about a mailing list like haskell-portability? If someone asks on this haskell-cafe for some way to do, say, USB on windows using Haskell, some answers would arrive; but if one asks at this, say, haskell-portability list, "I have a working Haskell USB library running everywhere except on Windows", it's likely to get the attention of people who do have deep OS understanding and are willing to do a big effort to solve a problem if that results in a new library that can be trusted at any OS. Maurício ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Monads aren't evil
> > For example, which of these is easier to read? > > f,g :: Int -> [Int] > > h1 :: Int -> [Int] > h1 x = do >fx <- f x >gx <- g x >return (fx + gx) > > h2 :: Int -> [Int] > h2 x = (+) <$> f x <*> g x > > h3 :: Int -> [Int] > h3 x = f x + g x -- not legal, of course, but wouldn't it be nice if it > was? > Yes, all that lifting is something that takes away lot of the beauty and simplicity of Haskell, but as far as my limited knowledge goes, I don't think this problem is easily solved :) Anyway, for your particular example, for newbies I guess the clearest would be: h0 x = [ fx+gx | fx <- f x, gx <- g x ] since one must recognize that a list monad exists and what it does... Now, for binary operators, Thomas Davie made a nice pair of combinators on Hackage (InfixApplicative) that would allow this to become: h3 x = f x <^(+)^> g x But in general, I guess you have a good point... > > Of course this raises problems of order of evaluation, etc, but as > long as such things were well-defined, that seems fine. If you want > finer control, you can always go back to more verbose syntax. These > cases are dominated by the cases where you simply don't care! > > This said, I don't want to sound overly negative; all of this pain is > *worth* the correctness guarantees that I get when writing in Haskell. > I just wish I could get the same guarantees with less pain! > > -- ryan > > > 2009/1/10 Peter Verswyvelen < bugf...@gmail.com>: > > Related to this issue, I have a question here. > > I might be wrong, but it seems to me that some Haskellers don't like > > writing monads (with do notation) or arrows (with proc sugar) because of > the > > fact they have to abandon the typical applicative syntax, which is so > close > > to the beautiful lambda calculus core. Or is it maybe because some people > > choose monads were the less linear applicative style could be used > instead, > > so the choice of monads is not always appropriate. > > Haskell is full of little hardcoded syntax extensions: list notation > > syntactic, list comprehensions, and even operator precedence that reduces > > the need for parentheses, etc... > > > > Of course IMHO the syntactic sugar is needed, e.g. a Yampa game written > > without the arrows syntax would be incomprehensible for the average > > programmer. But one could claim that this syntactic sugar hides what is > > really going on under the hood, so for newcomers these extensions might > make > > it harder. It could also feel like a hack, a failure to keep things as > > simple as possible yet elegant. > > Some people I talked with like that about the Scheme/ & LISP languages: > the > > syntax remains ultimately close to the core, with very little hardcoded > > syntactic extensions. And when one wants to add syntactic extensions, one > > uses syntactic macros. > > I'm not sure what others feel about the hardcoded syntax extensions in > > Haskell... > > > > Personally I'm not that much of a purist, I'm an old school hacker that > > mainly needs to get the job done. I like the syntax extensions in Haskell > > (and even C#/F# ;) because they let me write code shorter and clearer... > > On Fri, Jan 9, 2009 at 4:07 AM, Neal Alexander > > wrote: > >> > >> Ertugrul Soeylemez wrote: > >>> > >>> Hello fellow Haskellers, > >>> > >>> When I read questions from Haskell beginners, it somehow seems like > they > >>> try to avoid monads and view them as a last resort, if there is no easy > >>> non-monadic way. I'm really sure that the cause for this is that most > >>> tutorials deal with monads very sparingly and mostly in the context of > >>> input/output. Also usually monads are associated with the do-notation, > >>> which makes them appear even more special, although there is really > >>> nothing special about them. > >>> > >> > >> Yea, i was the same way when i started learning Haskell. I understood > how > >> Monads worked, and what the motivation was for them, but not why i would > >> want to restructure code to use them in specific instances. > >> > >> "Why should i care about monads when i can use Arrows or (.)" was also a > >> factor. > >> > >> Its kinda like getting advice from an adult as a child. You have no > >> particular reason to distrust the advice, but the value of it doesn't > set in > >> until something happens to you first hand to verify it. > >> > >> For me the turning point was writing some code that needed to handle > >> running code locally/remotely in a transparent manner. > >> > >> Maybe having a list of real-world usage scenarios or exercises on the > wiki > >> may help. > >> > >> __ _ > >> 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: Computer time, independent of date
POSIX realtime extensions have been developed to be high reliable. (...) However, they offer no guarantees on interval measurements, and the correction algorithms can cause the measurement of a time interval of an hour or so duration to be off by +/- 1 sec, especially within the first few hours after a cold boot. (...) At the start of this thread, my assumption was that all computers had a 100% reliable tick counter. Well, this shows I understand nothing about hardware. My problem is that the equipment I interact with is supposed to deliver data at a constant rate. Since I don't know how much its engineers care about patients, I wanted to be sure not to save wrong information. It wouldn't matter if the clock is saying we are on XVII century, as long as 10 seconds would never be 10.1. But, as I learned from you, my PC is not to be considered as a reference. Maybe the right approach is to ask people who understand hardware if mine is actually a valid concern. Thanks, Maurício ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Propositional logic implementation
All, Is there some better way to do this? It seems like a lot of boilerplate. Thanks! http://hpaste.org/13807#a1 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Issues with posix-realtime package
Galchin, Vasili ha scritto: Hi Manlio, I am the author of this package. Let me think about what you have said. Regards, Vasili If you can't reproduce the problem: there is a possibility that I have messed up my (GHC) system. I'm on Linux Debian Lenny. GHCi, version 6.8.2: http://www.haskell.org/ghc/ :? for help :1:22: attempting to use module `System.IO' (System/IO.hs) which is not loaded :1:22: Not in scope: `System.IO.stderr' :1:22: Not in scope: `System.IO.stdin' ghc-6.8.2: panic! (the 'impossible' happened) (GHC version 6.8.2 for i386-unknown-linux): interactiveUI:setBuffering Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Yesterday there were no problems with ghci, and I don't remember having done something strange. P.S: the impossible can always happen! Thanks Manlio Perillo ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] System.CPUTime and picoseconds
Hi. Just out of curiosity, but why Haskell 98 System.CPUTime library module uses picoseconds instead of, say, nanoseconds? At least on POSIX systems, picoseconds precision is *never* specified. Thanks Manlio Perillo ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Haskell Weekly News: Issue 100 - January 10, 2009
--- Haskell Weekly News http://sequence.complete.org/hwn/20090110 Issue 100 - January 10, 2009 --- Welcome to issue 100 of HWN, a newsletter covering developments in the [1]Haskell community. Welcome to the 100th (!) issue of the Haskell Weekly News, suitably published on your friendly neighborhood HWN editor's 1000th birthday (base 3). If you ever have content to be included in the HWN (announcements, blog posts, major life news) or a suggestion on how the HWN could be more useful to you as a window into the goings-on of the Haskell community, please don't hesitate to send it along, using the contact information at the end of each issue. Announcements Haskell BLAS bindings version 0.7. Patrick Perry [2]announced the [3]release of version 0.7 of the [4]blas package, Haskell bindings to the BLAS (Basic Linear Algebra Subprograms) library. According to Patrick, this release is "a major milestone---it is finally the library with all of the features that I want." X Haskell Bindings. Antoine Latter [5]announced a preview release of the [6]X Haskell Bindings. The goal of the library is to provide low-level access to the X11 protocol, in the spirit of the [7]X C Bindings. Data.TCache 0.5.5. Alberto G. Corona [8]announced the 0.5.5 release of the [9]TCache package, a transactional data cache with configurable persistence. This version adds the the capability to safely handle transactions, and incrementally serialize many data types simultaneously in the same piece of code. haskell-src-exts 0.4.8. Niklas Broberg [10]announced a new release (0.4.8) of the [11]haskell-src-exts package. This is a bug-fix release in the wake of the flurry of bug reports due to [12]hlint. bytestring-trie 0.1.2 (bugfix). wren ng thornton [13]announced a bugfix release for [14]bytestring-trie, efficient finite maps from (byte)strings to values. This release fixes a bug in alterBy, and adds an Eq instance. wxHaskell 0.11.1. Jeremy O'Donoghue [15]announced the release of [16]wxHaskell 0.11.1, a Haskell binding for the wxWidgets GUI library. The main highlights include support for XRC resource files, support for wxWidgets 2.8.x and GHC 6.10, and preliminary support for Cabal and Hackage. cabal2doap 0.1. Greg Heartsfield [17]announced the [18]release of [19]Cabal2doap, which generates Description of a Project (DOAP) XML/RDF data representing a Haskell project. This should make it possible for semantic web project aggregation sites to find and index Haskell projects. Jobs Jane Street is hiring functional programmers. Yaron Minsky [20]reminded everyone that [21]Jane Street is still hiring! Jane Street now has over 30 OCaml developers, and is actively looking to hire more in Tokyo, London and New York. PhD, postdoc, and engineering positions at HATS. CFP [22]announced the availability of 10 PhD, postdoc, and engineering positions within the HATS project (Highly Adaptable and Trustworthy Software using Formal Models), a new Integrated Project funded by the European Union, within the programme "Future and Emerging Technologies" (FET). The goal of HATS is a tool-supported framework and formal methodology for the development of long-lived and trustworthy software systems. Hypothetical Haskell job in New York. Tony Hannan [23]asked how many would be interested in applying to a hypothetical Haskell job in New York, assuming his boss can be convinced to use Haskell. Blog noise [24]Haskell news from the [25]blogosphere. * Lennart Augustsson (augustss): [26]LLVM arithmetic. * GHC / OpenSPARC Project: [27]Bootstrapping 6. * Patrick Perry: [28]New Haskell BLAS bindings!. * Clemens Fruhwirth: [29]Liskell standalone. * The GHC Team: [30]Benchmarking recent improvements in parallelism. * Galois, Inc: [31]Tech Talk: OpenTheory: Package Management for Higher Order Logic Theories. * Eric Kow (kowey): [32]fold diagram revisited?. * GHC / OpenSPARC Project: [33]Bootstrapping 5. * Lennart Augustsson (augustss): [34]LLVM. * Sebastian Fischer: [35]Monadic and Queue-Based Tree Search. * Philip Wadler: [36]Well-typed programs can't be blamed. * GHC / OpenSPARC Project: [37]Bootstrapping 4. * Manuel M T Chakravarty: [38]GPU Kernels as Data-Parallel Array Computations in Haskell.. * GHC / OpenSPARC Project: [39]Bootstrapping 3. * Tom Schrijvers: [40]Monadic Constraint Programming. * Conal Elliott: [41]Another angle on functional future values. * >>> Greg Heartsfield: [42]Cabal2doap. * Christopher Lane Hinson: [43]MaybeArrow?. * GHC / OpenSPARC Project: [44]Bootstrapping 2. * Darcs: [45]darc
Re: [Haskell-cafe] Looking for Haskellers on Windows
Hi Kyra, IT WORKS! Thank you very much, my application is now almost finished. It was a whole lot of fun writing this in Haskell, but the last 2 weeks where frustrating, until today. I am amazed at the possibilities Haskell gives me in wiring code together and I would not want to miss it by having to go back and do the whole app again in Smalltalk. Günther ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Issues with posix-realtime package
On Sat, Jan 10, 2009 at 5:52 AM, Manlio Perillo wrote: > Galchin, Vasili ha scritto: > >> Manlio, >> >> so compiling to native machine code works ok but if using ghci byte-code >> interpreter doesn't . can you supply your program please? >> >> > Right. > Can't you reproduce the problem? > > The program is very simple (I was just testing your package, since I > suggested the use of clock_gettime to Mauricio in a previous post): > > import System.Posix.Realtime.RTTime > import System.Posix.Realtime.RTDataTypes > > > main = do > time <- clockGetTime Clock_Monotonic; > print $ tvSec time > print $ tvNsec time > > > runghc rttime.hs > > > I suspect that this is a problem with shared library loading in ghci, since > the C code you use for your package, is also used by the base package (for > the Posix subsystem). > > By the way: I don't see reasons to add all that code, since it is not used. ^^^ which code? > > However, when I tried to remove all the unused code, executing the program > gave me a stack exception (maybe I have removed too many things...). > > > > One personal note: I don't like `tvSec` and `tvNsec`, I think `seconds` and > `nanoSeconds` is a better choice. > ^^^ ok .. I agree and will change. I asked others for > criticisms(constructive) when I put to hackage but didn't get any. This is > good ... > > Also, it would useful a function to compute elapsed time (maybe a general > class in base package, and a specialized instance declaration in > posix-realtime for the timespec?) > > > Vasili >> >> > > [...] > > > > Manlio > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Computer time, independent of date
Mauricio ha scritto: POSIX realtime extensions have been developed to be high reliable. (...) However, they offer no guarantees on interval measurements, and the correction algorithms can cause the measurement of a time interval of an hour or so duration to be off by +/- 1 sec, especially within the first few hours after a cold boot. (...) At the start of this thread, my assumption was that all computers had a 100% reliable tick counter. High Precision Event Timer (http://en.wikipedia.org/wiki/HPET) should be pretty reliable, but it will never be as reliable as a dedicated clock. Well, this shows I understand nothing about hardware. My problem is that the equipment I interact with is supposed to deliver data at a constant rate. What is the rate value? How do you read the data? Since I don't know how much its engineers care about patients, I wanted to be sure not to save wrong information. You should trust the engineers, IMHO, since that is a medical equipment and should be more reliable than a PC. Read carefully the equipment specification. It wouldn't matter if the clock is saying we are on XVII century, as long as 10 seconds would never be 10.1. But, as I learned from you, my PC is not to be considered as a reference. Maybe the right approach is to ask people who understand hardware if mine is actually a valid concern. If you can, you should ask to the equipment producer. If you are on a POSIX system, store both the time information from the equiment and from clock_gettime(CLOCK_MONOTONIC), but only trust the equipment. Thanks, Maurício Regards Manlio ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Issues with posix-realtime package
Galchin, Vasili ha scritto: [...] I suspect that this is a problem with shared library loading in ghci, since the C code you use for your package, is also used by the base package (for the Posix subsystem). By the way: I don't see reasons to add all that code, since it is not used. ^^^ which code? Code from HsUnix.h and execvpe.h. One personal note: I don't like `tvSec` and `tvNsec`, I think `seconds` and `nanoSeconds` is a better choice. ^^^ ok .. I agree and will change. I asked others for criticisms(constructive) when I put to hackage but didn't get any. This is good ... I would like to help to develope any wrappers around POSIX API. Manlio ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Computer time, independent of date
Mauricio wrote: patients, I wanted to be sure not to save wrong information. It wouldn't matter if the clock is saying we are on XVII century, as long as 10 seconds would never be 10.1. Chris (yes I am an experimental physicist) asks: What are the interval durations you need to measure? 0.1 second is very different from 1 ms or 0.1 μs ! (1 ms is the atomic time radio signal accuracy) (0.1 μs can be had with GPS receivers) Since they are from equipment, what is the spec? What is the error tolerance for these durations? How are these errors allowed or forbidden to accumulate? Since you say you do not trust the incoming timing then you need to be able to measure it. Do you need to monitor the timing of each and every measurement while running? Could you measure and certify the timing of the equipment before using it? Got a cheap oscilloscope? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Propositional logic implementation
Look at SYB (Data.Data, Data.Generics.*). For example, your "symbols" function can be rewritten as symbols :: Sentence -> [Symbol] symbols s = nub $ listify (const True) s "true" is not that simple, because this code is NOT boilerplate - each alternative is valuable by itself. On 10 Jan 2009, at 23:56, Andrew Wagner wrote: All, Is there some better way to do this? It seems like a lot of boilerplate. Thanks! http://hpaste.org/13807#a1 ___ 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: System.CPUTime and picoseconds
Manlio Perillo wrote: Hi. Just out of curiosity, but why Haskell 98 System.CPUTime library module uses picoseconds instead of, say, nanoseconds? At least on POSIX systems, picoseconds precision is *never* specified. I have not idea. But at a guess, I would say that 1 ns is not such a small time interval anymore. The CPU speeds are about 3 GHz, so 0.3 ns per CPU clock. Even the RAM clock in a laptop (e.g. Apple's 17" Mac Pro) is 1066 MHz, so the internal there is just under 1 ns. Whoever picked picoseconds has made it possible to talk about a single clock interval for hardware like this. -- Chris ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell not ready for Foo [was: Re: Hypothetical Haskell job in New York]
Quoth "John A. De Goes" : | Take a language like Ruby or Python (or Java, or C#, etc.). The vast | majority of code written in these languages does not "get down to the | C level". When I say, "vast majority", I'm referring to > 99.999%. | That's because the standard libraries provide sufficiently | comprehensive platform-agnostic abstractions to do what most people | need to do. As a result, libraries for these languages are built on | the standard libraries, and do not require native code. Maybe I haven't been paying enough attention, but I see Python and Haskell in about the same position on this, especially in light of how different they are (Haskell's FFI is a lot easier!) Plenty of Python software depends on C library modules and foreign code. The particular examples you mention - DB and UI - are great examples where it's sort of crazy to do otherwise for just the reasons you go on to list. Of the cases I myself am familiar with in these languages, LDAP is the one that seems most likely to benefit from a native implementation, as Perl does (but not Python.) The protocol is fairly simple, and the common open source C implementation makes an awkward FFI and is relatively troublesome to install and maintain. But it also represents a long legacy of hacks and features that allow it to interoperate as well as it does with other implementations that supposedly also support this same "fairly simple" protocol, a history that would be expensive and unpleasant to repeat just for the sake of a cleaner interface. The arguments you list in favor of native code are reasonable (though some of them cut both ways - in particular it's a bold assertion that bug fixes and general development are more likely in a Haskell implementation, compared to a widely used C implementation that it parallels.) But each case has its own merits, and it's perilous to generalize. It would have been absurd for Python to take the approach that Java takes (lacking the major corporate backing), and probably so also for Haskell. (Though Haskell may in the end need it for APIs that involve I/O, the way things seem to be going in GHC.) Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Issues with posix-realtime package
On Sat, Jan 10, 2009 at 4:37 PM, Manlio Perillo wrote: > Galchin, Vasili ha scritto: > >> [...] >>I suspect that this is a problem with shared library loading in >>ghci, since the C code you use for your package, is also used by the >>base package (for the Posix subsystem). >> >>By the way: I don't see reasons to add all that code, since it is >>not used. >> >> ^^^ which code? >> >> > Code from HsUnix.h and execvpe.h. > > >> >>One personal note: I don't like `tvSec` and `tvNsec`, I think >>`seconds` and `nanoSeconds` is a better choice. >> ^^^ ok .. I agree and will change. I asked others for >>criticisms(constructive) when I put to hackage but didn't get any. >>This is good ... >> > > I would like to help to develope any wrappers around POSIX API. ^^^ you are suggesting to change current wrapper API? Vasili > > > > Manlio > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Propositional logic implementation
Nice Idea, though I don't know that I want something that extensive. I was more looking for whether there was a better way I could define the algebraic data type. On Sat, Jan 10, 2009 at 6:04 PM, Miguel Mitrofanov wrote: > Look at SYB (Data.Data, Data.Generics.*). For example, your "symbols" > function can be rewritten as > > symbols :: Sentence -> [Symbol] > symbols s = nub $ listify (const True) s > > "true" is not that simple, because this code is NOT boilerplate - each > alternative is valuable by itself. > > > On 10 Jan 2009, at 23:56, Andrew Wagner wrote: > > All, >> Is there some better way to do this? It seems like a lot of boilerplate. >> Thanks! >> >> http://hpaste.org/13807#a1 >> ___ >> 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: Monads aren't evil
On 2009 Jan 10, at 15:19, Peter Verswyvelen wrote: h3 x = f x <^(+)^> g x Is that an operator or Batman? (yes, I know, 3 operators) -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allb...@kf8nh.com system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu electrical and computer engineering, carnegie mellon universityKF8NH ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Monads aren't evil
Holy concatenated operators, Batman! Is that an operator or Batman? > (yes, I know, 3 operators) > > -- > brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allb...@kf8nh.com > system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu > electrical and computer engineering, carnegie mellon universityKF8NH > > > > ___ > 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 BLAS bindings version 0.7
Patrick Perry schrieb: > The reason I want to expose modules but hide the documentation is > because there are a lot of "unsafeX" functions I want to provide access > to, but which 99% of users don't care about. The array library does the > same thing. Alternatively, the DEPRECATED pragma may prevent programmers from using these functions too extensively. However, this may be considered abuse of this pragma. I think the Unsafe module is the cleanest solution. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Syntactic Sugar (Was: Monads aren't evil)
Peter Verswyvelen schrieb: > Related to this issue, I have a question here. > > I might be wrong, but it seems to me that some Haskellers don't like > writing monads (with do notation) or arrows (with proc sugar) because of > the fact they have to abandon the typical applicative syntax, which is > so close to the beautiful lambda calculus core. Or is it maybe because > some people choose monads were the less linear applicative style could > be used instead, so the choice of monads is not always appropriate. > > Haskell is full of little hardcoded syntax extensions: list notation > syntactic, list comprehensions, and even operator precedence that > reduces the need for parentheses, etc... http://www.haskell.org/haskellwiki/Syntactic_sugar/Cons ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Infix expressions (Was: Monads aren't evil)
Peter Verswyvelen schrieb: > Now, for binary operators, Thomas Davie made a nice pair of combinators > on Hackage (InfixApplicative) that would allow this to become: > > h3 x = f x <^(+)^> g x http://www.haskell.org/haskellwiki/Infix_expressions ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Propositional logic implementation
On Sunday 11 January 2009 01:44:50 Andrew Wagner wrote: > Nice Idea, though I don't know that I want something that extensive. I was > more looking for whether there was a better way I could define the > algebraic data type. Let's have a look at your definitions from http://hpaste.org/13807#a1 : > data Sentence = Atomic Atom | Complex Complex The distinction between atomic expressions and complex expressions seems to be merely academic: None of your functions actually distinguishes between them. Thus, I suggest that you move the constructors of type Atom and Complex to type Sentence. The only place where type Atom is used is in the following declaration: > newtype Model = Model [Atom] But a close look at function true :: Model -> Sentence -> Bool reveals that it is sufficient to make a model a list of symbols. Therefore, we modify type Model to type Model = [Symbol] If Symbol was an instance of type class Ord, we could even move from lists to sets: import qualified Data.Set as Set type Model = Set.Set Symbol Then function symbols could also return sets of symbols, allowing for a much more efficient implementation via Set.union instead of List.nub and List.++: symbols :: Sentence -> Set.Set Symbol > data Atom = T | F | Symbol Symbol deriving Eq In function symbols you need to distinguish between symbols and other values of type Atom. With your current definition, function symbol must evaluate every atom to a concrete truthvalue. We can avoid this by defining Atom as data Atom = Const Bool | Symbol Symbol deriving Eq > data Symbol = A | B | C | P | Q | R | X | Y | Z | Label String deriving Eq I don't like two things about this definition: 1) There are two kinds of symbols, but there is no clear distinction between them. Instead, String-type labels are modelled as one special case of a symbol. 2) You enumerate characters explicitly. Instead, you could use type Char for single-character symbols. If you define symbols by type Symbol = Either Char String then you have a clear distinction between single-character symbols and labels, and you also get the above-mentioned instance of typeclass Ord for free. > data Complex = Not Sentence > | Sentence :/\: Sentence > | Sentence :\/: Sentence > | Sentence :=>: Sentence > | Sentence :<=>: Sentence There are some opportunities to reduce the number of constructors in this declaration. Constructor :=>: can easily be replaced by a function (==>) :: Sentence -> Sentence -> Sentence a ==> b = Not a :/\: b You can even define true, false, negation, conjunction and disjunction in terms of a newly introduced constructor Nand [Sentence] so that false = Nand [] true = Nand [false] Operator <=> can also be expressed in terms of Nand, but that would lead to duplicated work in function symbol and function true. Thus, we keep constructor :<=>:. The resulting declarations are data Sentence = Nand [Sentence] | Sentence :<=>: Sentence | Symbol Symbol type Symbol = Either Char String type Model = Set.Set Symbol This will reduce your boilerplate code to a minimum. :) Regards, Holger ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Propositional logic implementation
I like using smart constructors to replace :<=>: and :=>: a \/ b = a :\/: b a /\ b = a :/\: b a ==> b = Not a \/ b a <=> b = (a ==> b) /\ (b ==> a) Also, if you generalize Sentence a bit you get a really nice formulation of "true". See my paste at http://hpaste.org/13807#a2 -- ryan 2009/1/10 Andrew Wagner : > Nice Idea, though I don't know that I want something that extensive. I was > more looking for whether there was a better way I could define the algebraic > data type. > > On Sat, Jan 10, 2009 at 6:04 PM, Miguel Mitrofanov > wrote: >> >> Look at SYB (Data.Data, Data.Generics.*). For example, your "symbols" >> function can be rewritten as >> >> symbols :: Sentence -> [Symbol] >> symbols s = nub $ listify (const True) s >> >> "true" is not that simple, because this code is NOT boilerplate - each >> alternative is valuable by itself. >> >> On 10 Jan 2009, at 23:56, Andrew Wagner wrote: >> >>> All, >>> Is there some better way to do this? It seems like a lot of boilerplate. >>> Thanks! >>> >>> http://hpaste.org/13807#a1 >>> ___ >>> 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
