RE: [Haskell-cafe] Type problem with simple takusen code (was: Trivialdatabase access in Haskell)
From: Paul Moore [mailto:[EMAIL PROTECTED] runhaskell db.hs can't load .so/.DLL for: sqlite3 (addDLL: unknown error) This seems odd, as I'm not (intending to be) using sqlite here. If I copy a sqlite3.dll onto my PATH (just to get by, it's quite possible sqlite isn't set up right but I really don't care just now) I get past this, but get runhaskell db.hs interactive: C:\Program Files\Haskell\Takusen-0.6\ghc-6.6/HSTakusen-0.6.o: unknown symbol `_PQconnectdb' ghc.exe: unable to load package `Takusen-0.6' This appears to be caused by ghci/runhaskell wanting to link the entire library at once, rather than just the modules you're using. I don't know if this is a bug or a feaure with ghci; anybody else want to comment? This problem affects both ghci and runhaskell. It does not affect ghc, though. I'm not sure what the best solution is; we might have to do what Krasimir did with HSQL and make each database-specific module a separate package. For now, if you want to use Takusen, you are stuck with ghc (the compiler). This invocation: ghc --make db.hs -o db should make you a working db.exe. I have added a README.txt to the darcs repo, which hopefully provides a lot of this missing information. I haven't added uninstall instructions though :-) Alistair * Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer. * ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Reversing a string of words: C# v Perl V Ruby v Haskell
On Dec 13, 2006, at 3:54 AM, Yitz Gale wrote: Nice. Here is something similar: reverseWords = concat . reverse . groupBy eqsp where eqsp x y = isSpace x == isSpace y This can be made even nicer using the 'on' function [1]: reverseWords = concat . reverse . groupBy ((==) `on` isSpace) [1] http://www.haskell.org/pipermail/libraries/2006-November/006156.html / Ulf ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Reversing a string of words: C# v Perl V Ruby v Haskell
ulfn: On Dec 13, 2006, at 3:54 AM, Yitz Gale wrote: Nice. Here is something similar: reverseWords = concat . reverse . groupBy eqsp where eqsp x y = isSpace x == isSpace y This can be made even nicer using the 'on' function [1]: reverseWords = concat . reverse . groupBy ((==) `on` isSpace) [1] http://www.haskell.org/pipermail/libraries/2006-November/006156.html Lambdabot trick(tm), use 'join' in the [] monad, instead of 'concat' join . reverse . groupBy ((==) `on` isSpace) -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Request for improvements
I have written a thin but useful layer on top of parts of Control.Concurrent and Control.Exception to aid in forking new threads. I think I have written it correctly and understand the guarantees (when running under GHC 6.4 or 6.6). It is useful when * you need to be able to check whether a thread has finished running * you need to be able to wait until a thread has finished running * when you want to run within the scope of 'block' * you need to run in another thread with ** an exception handler (catch) ** a finally clause ** bracket commands But it may need improving, especially if I have missed a subtle blocking or race condition. And suggestions on improved names are welcome. The code is on the wiki at http://haskell.org/haskellwiki/WrapConc -- Chris ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Type problem with simple takusen code (was: Trivialdatabase access in Haskell)
On 12/13/06, Bayley, Alistair [EMAIL PROTECTED] wrote: From: Paul Moore [mailto:[EMAIL PROTECTED] This appears to be caused by ghci/runhaskell wanting to link the entire library at once, rather than just the modules you're using. I don't know if this is a bug or a feaure with ghci; anybody else want to comment? This problem affects both ghci and runhaskell. It does not affect ghc, though. I'm not sure what the best solution is; we might have to do what Krasimir did with HSQL and make each database-specific module a separate package. For now, if you want to use Takusen, you are stuck with ghc (the compiler). This invocation: ghc --make db.hs -o db should make you a working db.exe. Thanks for the explanation - it's no problem using ghc, I was only using runhaskell for (a tiny bit of) convenience. Having said that, I now get ghc --make db.hs -o db [1 of 1] Compiling Main ( db.hs, db.o ) Linking db.exe ... D:\Apps\GHC\gcc-lib\ld.exe: cannot find -lsqlite3 collect2: ld returned 1 exit status This may be because I have a sqlite3.dll in my PATH, but no development libs. Would that make configure think that sqlite is available, but because the build needs the link library, fail at that stage? If so, I may well be heading for a problem with Oracle, as I have the client only installed, so the OCI DLLs are present, but not the headers and lib files. (I've hit this one before, and can get round it, though). I had a look on the sqlite website, but can't find a development libraries download. I'm reluctant to get bogged down in building sqlite, so I'm leaving it there for now. To work around this, I removed sqlite3.exe from my PATH, and set up an oracle directory in my PATH which did include OCI. Then runhaskell Setup.hs configure reported no sqlite, no postgres, and Oracle from where I wanted. I reinstalled Takusen with these options. However, now when I run ghc --make, I get a string of link errors from Oracle stuff (OCIconstants.o). This is serious progress - I'm linking the right stuff this time. I've seen similar issues before, where I tried to use gcc to link to the Oracle-supplied OCI libraries (or at least I think that was it), as Oracle supply MSVC compatible libraries instead. Could this be relevant here? I know ghc uses the gcc linker, so it seems like a possibility. I have added a README.txt to the darcs repo, which hopefully provides a lot of this missing information. I haven't added uninstall instructions though :-) That looks excellent - it would have given me exactly what I needed. Paul. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Haskell and .NET
Hi Yhc also has a .NET generating capability, just pass the -dotnet flag. http://haskell.org/haskellwiki/Yhc Thanks Neil On 12/12/06, Monique Monteiro [EMAIL PROTECTED] wrote: Hi Justin, I've runned a research project about this topic (in fact, it was the subject of my MSc dissertation). Please see the Haskell.NET Project (http://www.cin.ufpe.br/~haskell/haskelldotnet). We have compiled a subset of the Haskell language to .NET, but we still don't have an available release (we don't support the full Haskell prelude yet). The compiler is an extension to GHC. In the future, we intend to provide full interoperability with .NET in this way. There are some interesting references in the website about our compilation strategies. If you need further information about the project's status, please contact Prof. André Santos ([EMAIL PROTECTED]) and/or Guilherme Avelino ([EMAIL PROTECTED]). Best regards, -- _ Monique Monteiro, MSc http://www.cin.ufpe.br/~mlbm http://thespoke.net/blogs/moniquelouise/default.aspx [EMAIL PROTECTED] +55 81 34198137 Project Manager Recife Microsoft Innovation Center ___ 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: Micro-contributions to MissingH
Hi I'm wondering if I should submit this as a patch for MissingH. If so, where in the new hierarchy should this be placed? I submitted 3 patches to missingh about a week ago, but have heard nothing back since. Did they get spam filtered or something? Thanks Neil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Haskell and .NET
The problem with Haskell for .NET is that the produced executables are usually very slow. Good optimizing compiler like GHC has better chance to produce code with reasonable performance. The major problem with YHC is that it still doesn't have strictness analyzer. The consequence is that the produced .NET code creates lots of unnecessary temporal objects. Cheers, Krasimir On 12/13/06, Neil Mitchell [EMAIL PROTECTED] wrote: Hi Yhc also has a .NET generating capability, just pass the -dotnet flag. http://haskell.org/haskellwiki/Yhc Thanks Neil On 12/12/06, Monique Monteiro [EMAIL PROTECTED] wrote: Hi Justin, I've runned a research project about this topic (in fact, it was the subject of my MSc dissertation). Please see the Haskell.NET Project (http://www.cin.ufpe.br/~haskell/haskelldotnet). We have compiled a subset of the Haskell language to .NET, but we still don't have an available release (we don't support the full Haskell prelude yet). The compiler is an extension to GHC. In the future, we intend to provide full interoperability with .NET in this way. There are some interesting references in the website about our compilation strategies. If you need further information about the project's status, please contact Prof. André Santos ([EMAIL PROTECTED]) and/or Guilherme Avelino ([EMAIL PROTECTED]). Best regards, -- _ Monique Monteiro, MSc http://www.cin.ufpe.br/~mlbm http://thespoke.net/blogs/moniquelouise/default.aspx [EMAIL PROTECTED] +55 81 34198137 Project Manager Recife Microsoft Innovation Center ___ 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] Aim Of Haskell
I think this is going out of the way. Excuse me, but the main discussion was not about pascal! And thanks again to all. Now I think there is a bigger whole between current situation of Haskell and using It as a real tool, than what I thought before. But any way; I still have a hope for rising a new folk of thinkers in software world that will put ideas to work more practically. Haskell got academic-centric-being syndrome, as JAVA got perfectionism syndrome (see elegant and useless design patterns and architectures there!). I can not imagine a pure and clear vision about this new folk that IT world lakes now. If anyone helps me with clarification of this thing, It will be great to me! Best regards ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Dynamic types through unsafeCoerce
I really like your approach Udo, and I would use it, but I added the
condition of not splitting the descriptor for a good reason, let me
explain it.
Let's summarize what we have first ...
Here is my _simplified_ Descriptor
-- Descriptor, equivalent to a C struct with function pointers
-- hd is the handler of the callbacks (void *) in C
data Descriptor hd =
Descriptor { -- create a new instance and return its handler
instantiate:: InstanceInitData - hd,
-- Run and return a new handler
run:: hd - IO hd}
And here is Udo's proposal
-- --
type Descriptor = InstanceInitData - Runner
-- a function! Who would have thought it?
newtype Runner = R { run :: IO Runner }
-- could be a plain (IO Runner) instead of a newtype, if only it
-- weren't a recursive type
On 12/13/06, Udo Stenzel [EMAIL PROTECTED] wrote:
Finished! Look Ma, no existentials, no Typeable, no wrappers, even the
types have become simple!
I don't quite agree with this.
I like the fact that type parameters are removed, which makes them
homegeneus and solves the problem of storing them in a list but as a
drawback the Runner type is less intuitive than the simple run
function.
There's nothing horrible about it, but considering it's a binding I
think that the types should resemble the original C types as much as
possible. That has many advantages: the original documentation of the
library would still apply and anyone who understands C code which
makes use of the original library could translate it easily to Haskell
afterwards.
Okay, I cheated a bit: I _did_ split Descriptor in two. That feels more
right anyway, since 'instantiate' is only going to be called once (I
think) and before 'instantiate' is called, there is no meaningful 'run'
function anyway (and of that I'm sure).
As I said the example I posted is quite simplified. Actually the real
descriptor (a naive translation from a C struct) is:
-- hd and id are (void *) in C and modelled as type parameters in Haskell
data Descriptor id hd =
Descriptor {uniqueID :: LadspaIndex,
label :: String,
properties :: LadspaProperties,
name, maker, copyright :: String,
portCount :: LadspaIndex,
portDescriptors:: [PortDescriptor],
portNames :: [String],
portRangeHints :: [PortRangeHint],
implementationData :: id,
instantiate:: Descriptor id hd
- LadspaIndex -
Maybe hd,
-- In this case we are using lists to represent the port I/O buffers, so the
-- port connections (buffer pointers of ports) is handled by the marshaller
--connectPort :: (hd - LadspaIndex - Ptr LadspaData - IO hd)
activate :: Maybe(hd - IO ()),
-- (LadspaIndex,PortData) indicates the portnumber and its data
run:: hd -
LadspaIndex -
[(LadspaIndex,PortData)] -
([(LadspaIndex,PortData)], hd),
-- Not yet implemented (is not mandatory for a plugin to provide them)
--runAdding ::
--setAddingGain ::
deactivate :: Maybe(hd - IO ()),
cleanup:: hd - IO ()}
As you can see, apart from the run function , a Descriptor has some
other data and other functions, which can be _optional_ ( see
deactivate, and activate)
Those optional funcions cause a problem when splitting the type Udo
did: The C code must know which of those are optional when calling
chooseDescriptor.
One solution would be adding some Booleans to the Descriptor,
indicating wether those functions are finally going to be used or not
... but that causes redundancy and permits inconsistencies (Boolean
in Descriptor + Maybe value of the function itself which don't match).
That's how I actually do it right now (see
http://www.student.nada.kth.se/~alfonsoa/HLADSPA/HLADSPA-0.2.1/src/HLADSPA.hs
). But I'm not happy with it.
The only elegant solution which I could come up to solve the problem
is simply avoiding to split the Descriptor by using unsafeCoerce#
(which is not that elegant) to store the descriptors in a list.
Thats when I decided to start this thread ... and why I wrote that not
splitting the Descriptor was a must.
Any Suggestions?
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Dynamic types through unsafeCoerce
On 12/13/06, Brandon Moore [EMAIL PROTECTED] wrote:
It looks to me like the C code could make your program segfault from a
type missmatch, if it
gets a handle from instantiating one descriptor, and tries to run it
from another.
Well, the C code could even provide (by error or at will) any pointer
value which could mismatch or not. C is potentially dangerous by
definition and there is no way to cope with that whatever we export
from Haskell. This is just a particular case of that major problem, in
which we use a instance handle.
Building code which can fail that way hopefully requires unsafeCoerce!
Any haskell code which receives a C pointer is likely to suffer from
the type-mismatch segfault problem you mentioned above.
The purpose of using unsafeCoerce in my code is to allow me to pack
some polymorphic values in a list as if they ware homogeneous. I don't
see how unsafeCoerce would help me with a type mismatch.
I think Udo's code is the best way to go, if it solves your problem.
Udo's code is equivalent to code similar to yours but defined around the
existential type
data Descriptor =
forall hd . Descriptor { -- create a new instance and return its
handler
instantiate:: InstanceInitData - hd,
-- Run and return a new handler
run:: hd - IO hd}
Hiding the hd parameter breaks the C-exported cRun function.
Then observing that because hd is hidden you can only use an hd by
passing it run, so you
might as well wrap it up in that Runner type.
Which yet again, requires splitting Descriptor in two.
If you want to be able to define several Descriptors over the same type
hd, and
Different descriptors are allowed to have different handlers (void *)
in C. That's a precondition, and furthermore, the source of my
modelling problem and this thread :)
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: On improving libraries: wanted list
On Wed, Dec 13, 2006 at 04:19:58PM +1100, Donald Bruce Stewart wrote: In particular, you seem to be wanting my pipeBoth function. Note that your proposed String - IO String function type is insufficient because it does not provide a way to evaluate the return value of the function. this kind of functionality seems to be expected by new users (its one of the more common questions on #haskell). Is System.Cmd.Utils in a position to be moved into base alongside System.Cmd and System.Process? It seems quite fundamental for getting work done quickly for script-like haskell programs. It could go under System.Posix perhaps. It relies quite heavily on functionality provided by the unix package and the System.Posix.* tree. Take a look at the source at: http://software.complete.org/missingh/browser/src/System/Cmd/Utils.hs Only one function, safeSystem, is portable to Windows. Also, because Hugs doesn't support fork(), most aren't supported on Hugs, either. I would be happy to contribute this to somewhere on the System.Posix tree, or wherever it's most appropriate. These functions take advantage of hslogger (http://software.complete.org/hslogger), so you can use one line in your main command to turn on command invocation debugging (see what commands are started and what they return). That will have to be stripped out before it goes into base, which I'm willing to do. (Or hslogger could go into base, but I'm guessing there'd be objection to that.) Comments? Reminder for those just joining the thread, the API we're discussing is http://software.complete.org/missingh/static/doc/System-Cmd-Utils.html -- John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Micro-contributions to MissingH
On Wed, Dec 13, 2006 at 12:01:36PM +, Neil Mitchell wrote: Hi I'm wondering if I should submit this as a patch for MissingH. If so, where in the new hierarchy should this be placed? I submitted 3 patches to missingh about a week ago, but have heard nothing back since. Did they get spam filtered or something? I don't see them in my inbox. Can you try resending, and drop me a note once you have? I can then check my smtp logs. -- John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Re: Large data structures
Alex Queiroz wrote: On 12/12/06, Benjamin Franksen [EMAIL PROTECTED] wrote: PS: Please try to include exactly the relevant context in replies, no more, no less. Your original question (stripped down to the body of the text) would have been relevant, here, but neither 'Hello', nor 'Cheers' are worth quoting. Sorry, but I did not quote hello or cheers. Oops. My turn to say 'sorry'. No offense meant... Cheers Ben ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Aim Of Haskell
On 12/13/06, Kaveh Shahbazian [EMAIL PROTECTED] wrote: I think this is going out of the way. Excuse me, but the main discussion was not about pascal! This list is exactly for off-topic discussions :-) And thanks again to all. Now I think there is a bigger whole between current situation of Haskell and using It as a real tool, than what I thought before. But any way; I still have a hope for rising a new folk of thinkers in software world that will put ideas to work more practically. Haskell got academic-centric-being syndrome, as JAVA got perfectionism syndrome (see elegant and useless design patterns and architectures there!). I can not imagine a pure and clear vision about this new folk that IT world lakes now. If anyone helps me with clarification of this thing, It will be great to me! The reason why Haskell is academic-centric is that it was originally conceived by academics, and they were interested in doing research into language design and implementation and also had jobs to take care of and all of this doesn't leave much time for being a language evangelist or for figuring out what the practical issues might be (not to mention sleeping at night). People outside academia who might be inclined to take on some of those more practical questions are just beginning to notice that Haskell could be useful for them too. The reason this didn't happen earlier was that there was no marketing budget. It had to happen in a grassroots fashion, and IMO it couldn't have happened until after the rise of distributed open-source development (which, I remind you, didn't start gaining a lot of momentum until not that long ago). You could become one of those new folk of thinkers. Be the change you wish to see. Cheers, Kirsten -- Kirsten Chevalier* [EMAIL PROTECTED] *Often in error, never in doubt They say the world is just a stage you're on...or going through. --Jim Infantino ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Type problem with simple takusen code (was: Trivialdatabase access in Haskell)
Having said that, I now get ghc --make db.hs -o db [1 of 1] Compiling Main ( db.hs, db.o ) Linking db.exe ... D:\Apps\GHC\gcc-lib\ld.exe: cannot find -lsqlite3 collect2: ld returned 1 exit status This may be because I have a sqlite3.dll in my PATH, but no development libs. You need to have sqlite3.exe in the same folder as sqlite3.dll. sqlite3.exe is what the installer looks for - if it finds it, then it assumes sqlite3.dll is in the same place. When you built takusen, was this in your path? Check the output from runhaskell Setup.hs configure: this tells you if it finds Sqlite, and if so where it is. This information is then baked into takusen.buildinfo, and that's what's used by ghc for linking when you build your program. You don't need it if you want to use Oracle: just remove it from your path and configure/build/install Takusen. However, now when I run ghc --make, I get a string of link errors from Oracle stuff (OCIconstants.o). This is serious progress - I'm linking the right stuff this time. I've seen similar issues before, where I tried to use gcc to link to the Oracle-supplied OCI libraries (or at least I think that was it), as Oracle supply MSVC compatible libraries instead. Could this be relevant here? I know ghc uses the gcc linker, so it seems like a possibility. Not a problem I've experienced, but then my Oracle client install includes the headers etc. I don't think these are necessary unless you compile -fvia-C, which I don't think is happening (ghc -O results in -fvia-C, though). I use ghc for compilation and linking, and I have no trouble. Can you send me the compiler/linker output? Perhaps best if we take this off-list. Also, what version of Oracle is it? I've developed against 8i, and haven't had a chance to test against later versions. Alistair * Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer. * ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Aim Of Haskell
Hello Joachim, Wednesday, December 13, 2006, 2:17:08 AM, you wrote: Actually, it's quite simple: following the ideology de jour and teaching-relevant support. are you remember title of Wirth's book? algorithms + data structures = programs. i think that Haskell is ideal language for teaching programming now (like Pascal was in 80's), because it teaches how to develop algorithms instead of focusing on implementation details. of course, you are right that fashion and availability drives actual teachers selection -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[2]: [Haskell-cafe] Dynamic types through unsafeCoerce
Hello Udo, Wednesday, December 13, 2006, 3:25:32 AM, you wrote: Well, all you need to do is to throw out your OO-Think (and with it Typeable and casts) and you'll realize what you're actually doing here: you're passing functions. Say so and everything comes naturally. Alfonso, you may be interested in reading the following pages where i put some examples of passing functions in the cases where OOP programmers use classes. after all, OOP class is just data+functions bundled together, while in Haskell these are separate concepts http://haskell.org/haskellwiki/OOP_vs_type_classes http://haskell.org/haskellwiki/IO_inside (look at Example: a list of IO actions and next chapters) -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[2]: [Haskell-cafe] Aim Of Haskell
Hello Kirsten, Tuesday, December 12, 2006, 4:28:18 PM, you wrote: Actually, the more I think of it, the more I think we should rename the language altogether. Curry would have avoided this problem. we can also rename Pascal to Blez to avoid confusion -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[2]: [Haskell-cafe] Re: a cabal/database lib experience
Hello Paul, Tuesday, December 12, 2006, 4:48:55 PM, you wrote: ./Setup.lhs configure -p ./Setup.lhs build ./Setup.lhs install I come from a Python background, and Python's distutils (which feels very like cabal - or should that be the other way round?) tends to have later commands include earlier ones. So, i suggest you to write simple script that automates this. i've attached makefile which i include with all my libs that does this - you need to run only make install. i propose to all library developers to include such makefile with their libs -- Best regards, Bulatmailto:[EMAIL PROTECTED] Makefile Description: Binary data ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Haskell and .NET
Hello Monique, Wednesday, December 13, 2006, 1:05:18 AM, you wrote: subset of the Haskell language to .NET, but we still don't have an available release (we don't support the full Haskell prelude yet). if you are interested in providing Base library functionality, look at the http://haskell.org/haskellwiki/Library/Core - it is my project of refactoring Base library in (almost) compiler-independent way -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Dynamic types through unsafeCoerce
On 12/13/06, Alfonso Acosta [EMAIL PROTECTED] wrote:
-- hd and id are (void *) in C and modelled as type parameters in Haskell
data Descriptor id hd =
Descriptor {uniqueID :: LadspaIndex,
label :: String,
properties :: LadspaProperties,
name, maker, copyright :: String,
portCount :: LadspaIndex,
portDescriptors:: [PortDescriptor],
portNames :: [String],
portRangeHints :: [PortRangeHint],
implementationData :: id,
instantiate:: Descriptor id hd
- LadspaIndex -
Maybe hd,
Oh, LADSPA. Suddenly everything make so much more sense.
First, the implementationData is useless to you. Put it in a closure
when building this object:
ladspa_descriptor = do
...
let implementationData = ...
return Descriptor { ... referencing implementationData ... }
No need to export that to the user only to have them pass it back in.
Second, you don't want the consumer to pick the hd type. If you're
willing to accept extensions (I think you are), make it existential:
data Descriptor = forall hd. Descriptor { ... }
This will ensure that you can't pass the handles from one plugin to
the methods of another.
--
Taral [EMAIL PROTECTED]
You can't prove anything.
-- Gödel's Incompetence Theorem
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Dynamic types through unsafeCoerce
Alfonso Acosta wrote:
On 12/13/06, Udo Stenzel [EMAIL PROTECTED] wrote:
Finished! Look Ma, no existentials, no Typeable, no wrappers, even the
types have become simple!
I like the fact that type parameters are removed, which makes them
homegeneus and solves the problem of storing them in a list but as a
drawback the Runner type is less intuitive than the simple run
function.
Actually the Runner type _is_ a simple (impure) function. The
complication is just that you wrote your example in such a way that
'run' has to return a new 'run' function, and that gives it the type
(a where a = IO a), which is not possible in Haskell without the use of
a newtype.
[...]
As I said the example I posted is quite simplified. Actually the real
descriptor (a naive translation from a C struct) is:
-- hd and id are (void *) in C and modelled as type parameters in Haskell
data Descriptor id hd =
Descriptor {uniqueID :: LadspaIndex,
label :: String,
properties :: LadspaProperties,
name, maker, copyright :: String,
portCount :: LadspaIndex,
portDescriptors:: [PortDescriptor],
portNames :: [String],
portRangeHints :: [PortRangeHint],
implementationData :: id,
instantiate:: Descriptor id hd
- LadspaIndex -
Maybe hd,
-- In this case we are using lists to represent the port I/O buffers, so the
-- port connections (buffer pointers of ports) is handled by the marshaller
--connectPort :: (hd - LadspaIndex - Ptr LadspaData - IO
hd)
activate :: Maybe(hd - IO ()),
-- (LadspaIndex,PortData) indicates the portnumber and its data
run:: hd -
LadspaIndex -
[(LadspaIndex,PortData)] -
([(LadspaIndex,PortData)], hd),
-- Not yet implemented (is not mandatory for a plugin to provide them)
--runAdding ::
--setAddingGain ::
deactivate :: Maybe(hd - IO ()),
cleanup:: hd - IO ()}
As you can see, apart from the run function , a Descriptor has some
other data and other functions, which can be _optional_ ( see
deactivate, and activate)
Okay, beautiful solution first, again splitting Discriptor in two and
ignoring some fields being optional. Again, you have a factory and an
actual object, and we will implement it exactly this way, for the moment
ignoring the exports to C. I'm also leaving out implementationData,
because it's impossible to see what that's used for.
data HdMaker = HdMaker { uniqueID :: LadspaIndex,
label :: String,
...
instantiate :: LadspaIndex - Maybe Hd }
data Hd = Hd { connectPort :: LadspaIndex - Ptr LadspaData - IO Hd
, activate :: IO ()
, run :: LadspaIndex - [(LadspaIndex, PortData)]
- ([(LadspaIndex, PortData)], Hd)
, deactivate :: IO ()
, cleanup :: IO ()
}
newHdMaker ... = HdMaker { ...
, instantiate = newHandle }
where
newHandle = Hd { connectPort =
, activate =
, run =
, deactivate =
, cleanup =
}
You should be able to see how this is to be fleshed out. The important
point is that the fields of Hd (which are set in newHandle) don't need
to be passed a handle of sorts later, since that handle is already
available, though of course I can't infer where it is supposed to come
from. As usual, add newStablePtr/derefStablePtr as needed. I guess the
connectPort function has to construct yet another Hd.
Now you don't want to split the Descriptor record, because the C world
already decided to pass an additional opaque handle type. That's no
problem: you handle is simple the set of functions that take handles as
parameters.
data Descriptor = Descriptor
{ uniqueID :: LadspaIndex,
...
instantiate :: LadspaIndex - Maybe Hd,
connectPort :: Hd - LadspaIndex - Ptr LadspaData - IO Hd,
activate :: IO ()
...
}
newDescriptor ... = Descriptor
{ ...
instantiate = newHandle,
connectPort Hd = hd_connectPort Hd,
activate Hd = hd_activate Hd,
...
}
where the fields of Hd have to be suitably renamed.
Those optional funcions cause a problem when
Re: [Haskell-cafe] Dynamic types through unsafeCoerce
On 12/13/06, Alfonso Acosta [EMAIL PROTECTED] wrote: deactivate :: Maybe(hd - IO ()), According to the spec, NULL here means no-op. So instead of using Maybe, just set deactivate = \_ - return () if you see NULL. -- Taral [EMAIL PROTECTED] You can't prove anything. -- Gödel's Incompetence Theorem ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Haskell and .NET
Hi Krasimir, to produce code with reasonable performance. The major problem with YHC is that it still doesn't have strictness analyzer. It does, or rather Yhc.Core does (see Yhc.Core.Strictness - http://www.cs.york.ac.uk/fp/yhc/snapshot/docs/Yhc-Core-Strictness.html). This was only done a few weeks ago, so the .NET translator has no benefit from it. And strictness is not the biggest problem, a complete lack of any optimisations is, but I'm working on that one too! Thanks Neil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Dynamic types through unsafeCoerce
On 12/13/06, Taral [EMAIL PROTECTED] wrote:
Second, you don't want the consumer to pick the hd type. If you're
willing to accept extensions (I think you are), make it existential:
data Descriptor = forall hd. Descriptor { ... }
This will ensure that you can't pass the handles from one plugin to
the methods of another.
Third, we can split handles out as actual objects now:
data Descriptor =
Descriptor {uniqueID :: LadspaIndex,
label :: String,
properties :: LadspaProperties,
name, maker, copyright :: String,
portCount :: LadspaIndex,
portDescriptors:: [PortDescriptor],
portNames :: [String],
portRangeHints :: [PortRangeHint],
instantiate:: LadspaIndex - IO (Maybe Handle),
}
data Handle =
Handle {descriptor :: Descriptor,
activate :: IO (),
-- (LadspaIndex,PortData) indicates the portnumber and its data
run :: LadspaIndex - [(LadspaIndex,PortData)] - IO
[(LadspaIndex, PortData)],
deactivate :: IO (),
cleanup :: IO (),
}
Then you'll want helpers that use Control.Exception.bracket to provide
exception-safe access to these objects. For example:
withHandle h = bracket (activate h) (deactivate h)
You can also optionally use cleanup as the finalizer for the
ForeignPtr underlying Handles, but the GC isn't guaranteed to be
timely about calling finalizers, so that may or may not be what you
want.
--
Taral [EMAIL PROTECTED]
You can't prove anything.
-- Gödel's Incompetence Theorem
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Aim Of Haskell
On 12/13/06, Bulat Ziganshin [EMAIL PROTECTED] wrote: Hello Joachim, Wednesday, December 13, 2006, 2:17:08 AM, you wrote: Actually, it's quite simple: following the ideology de jour and teaching-relevant support. are you remember title of Wirth's book? algorithms + data structures = programs. i think that Haskell is ideal language for teaching programming now (like Pascal was in 80's), because it teaches how to develop algorithms instead of focusing on implementation details. of course, you are right that fashion and availability drives actual teachers selection That's a good point too. Actually, though, my original comment about understanding the reasons for programming language adoption was not just meant to refer to adoption in an educational context, but also to the reasons why people adopt the languages they do for commercial (or research or free software) projects, as well; so, I don't think it's quite *that* simple, although I should have been more clear. Cheers, Kirsten -- Kirsten Chevalier* [EMAIL PROTECTED] *Often in error, never in doubt Base eight is just like base ten, really... if you're missing two fingers. -- Tom Lehrer ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Haskell and .NET
On 12/13/06, Neil Mitchell [EMAIL PROTECTED] wrote: Hi Krasimir, to produce code with reasonable performance. The major problem with YHC is that it still doesn't have strictness analyzer. It does, or rather Yhc.Core does (see Yhc.Core.Strictness - http://www.cs.york.ac.uk/fp/yhc/snapshot/docs/Yhc-Core-Strictness.html). This was only done a few weeks ago, so the .NET translator has no benefit from it. And strictness is not the biggest problem, a complete lack of any optimisations is, but I'm working on that one too! It is great to hear that. Of course an optimiser will be beneficial too but I guess that even the benefit that the code generator can have from the strictness analyzer will make huge difference. Cheers, Krasimir ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Aim Of Haskell
Bulat Ziganshin [EMAIL PROTECTED] wrote: one particular thing that we still lack is something like book Haskell in real world How about: http://www.amazon.co.uk/Applications-Functional-Programming-Colin-Runciman/dp/1857283775/sr=1-16/qid=1166024994/ref=sr_1_16/202-8679714-4706263?ie=UTF8s=books Applications of Functional Programming (Hardcover) by Colin Runciman (Editor), David Wakeling (Editor) Routledge, 1995. Synopsis This book is unique in showcasing real non-trivial applications of functional programming using the Haskell language. It presents state-of-the-art work from the FLARE project and will be an invaluable resource for advanced study, research and implementation. The applications covered in the book range from workforce management and graphical design to computational fluid dynamics. Regards, Malcolm ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] ANNOUNCE: Phooey -- a Functional UI library for Haskell
On the web page the screen shots are all on Windows. Is that the only supported platform at the moment? (I'd love to see support for GTK :-) /M -- Magnus Therning (OpenPGP: 0xAB4DFBA4) [EMAIL PROTECTED] Jabber: [EMAIL PROTECTED] http://therning.org/magnus Software is not manufactured, it is something you write and publish. Keep Europe free from software patents, we do not want censorship by patent law on written works. As far as the laws of mathematics refer to reality, they are not certain, and as far as they are certain, they do not refer to reality. -- Albert Einstein pgp3jR1ymjn7f.pgp Description: PGP signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Writing Haskell For Dummies Or At Least For People Who Feel Like Dummies When They See The Word 'Monad'
On 12/12/06, Joachim Durchholz [EMAIL PROTECTED] wrote: Agreed. Something along the lines of The Art of Functional Programming. +1 . I would love to read something that is the equivalent of 'design patterns', but for functional languages. I thought Osasaki's book Purely Functional Data Structures would have that, but it was little too focused on proving properties of algorithms. As someone in industry, that wasn't so important to me. I want to learn how to think functionally. HSoE is great as a starting textbook. However, it just scratches the I picked this one up after learning Haskell for about 2 months. I really opened my eyes to the possibilities that functional programming offers. Seeing something in the same spirit but extended would be awesome. Justin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Haskell and .NET
On 12/13/06, Krasimir Angelov [EMAIL PROTECTED] wrote: The problem with Haskell for .NET is that the produced executables are usually very slow. Good optimizing compiler like GHC has better chance I don't really want something that compiles Haskell to the CLR, though that would be great eventually. Even something that just interoperates with .NET is good enough. The Hugs98.NET project seemed to extend the FFI to be able to work with .NET - is that capability available somewhere still? Justin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] ANNOUNCE: Phooey -- a Functional UI library for Haskell
Phooey is built on wxHaskell. Quoting from the wxHaskell home pagehttp://wxhaskell.sourceforge.net , wxHaskell is therefore built on top of wxWidgets http://www.wxwidgets.org/– a comprehensive C++ library that is portable across all major GUI platforms; including GTK, Windows, X11, and MacOS X. So I expect that Phooey runs on all of these platforms. That said, I have only tried Phooey on Windows. Please give it a try and let me know what happens. Thanks for the question. I've updated the Phooey home pagehttp://conal.net/Phooey/with this info. Cheers, - Conal On 12/13/06, Magnus Therning [EMAIL PROTECTED] wrote: On the web page the screen shots are all on Windows. Is that the only supported platform at the moment? (I'd love to see support for GTK :-) /M -- Magnus Therning (OpenPGP: 0xAB4DFBA4) [EMAIL PROTECTED] Jabber: [EMAIL PROTECTED] http://therning.org/magnus Software is not manufactured, it is something you write and publish. Keep Europe free from software patents, we do not want censorship by patent law on written works. As far as the laws of mathematics refer to reality, they are not certain, and as far as they are certain, they do not refer to reality. -- Albert Einstein ___ 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: Haskell and .NET
Hi And strictness is not the biggest problem, a complete lack of any optimisations is, but I'm working on that one too! It is great to hear that. Of course an optimiser will be beneficial too but I guess that even the benefit that the code generator can have from the strictness analyzer will make huge difference. In the GHC back end I seem to remember strictness gives a 10% performance improvement, but let motion gives a 30% improvement - its quite likely that .NET will benefit more from strictness, but still the general optimisation is probably going to be a bigger win. I think basic strictness information gained about 5% in the Javascript Yhc backend, so not great amounts. The optimiser does generalised deforestation, and loads of other cool tricks, so I'm hoping for at least 50% over the normal Yhc code :) Thanks Neil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Aim Of Haskell
The reason why Haskell is academic-centric is that it was originally conceived by academics, and they were interested in doing research into language design and implementation .. shouldn't we make this used to be academic-centric? People outside academia who might be inclined to take on some of those more practical questions are just beginning to notice that Haskell could be useful for them too. .. although just beginning to notice may be accurate on a historical scale, I have the feeling that the actual development is further along than this. at least, there have been sufficiently many and active early adopters for long enough to make a substantial difference. so those practical questions are not being raised, but several of them are actually being addressed. It had to happen in a grassroots fashion, and IMO it couldn't have happened until after the rise of distributed open-source development (which, I remind you, didn't start gaining a lot of momentum until not that long ago). one of the most exciting aspects of Haskell is that pragmatic interest in the language has been growing steadily without academic interest in it declining in any way. as a result, we have a language that represents an interesting mixture of good and useful, although it is not entirely clear yet how long this nice balance will hold. we have had lots of languages that were intended to be well-designed (good, beautiful, ..), but never much used in practice, and we have also had lots of languages that were intended to be pragmatic (practical, useful, ..), without much interest in theoretical beauty. but how many languages are there where the two aspects have converged, with both communities still actively interested in the result? claus ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Aim Of Haskell
Hallo, On 12/13/06, Claus Reinke [EMAIL PROTECTED] wrote: we have had lots of languages that were intended to be well-designed (good, beautiful, ..), but never much used in practice, and we have also had lots of languages that were intended to be pragmatic (practical, useful, ..), without much interest in theoretical beauty. but how many languages are there where the two aspects have converged, with both communities still actively interested in the result? Lua is a small scripting language created in academia, whose authors are academics, that has reached the industry embedded in several well-known products such as World of Warcraft or Adobe Lightroom (which is 40% Lua). Frequently people ask for bloat in the mailing list, and the usual answer is why?. The authors claim that when thinking about a new version of Lua they don't think of features to add, but what features they can remove. So I'd say it's perfectly possible to have an academia-backed language useful for the real world. Cheers, -- -alex http://www.ventonegro.org/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Dynamic types through unsafeCoerce
On 12/13/06, Taral [EMAIL PROTECTED] wrote:
On 12/13/06, Alfonso Acosta [EMAIL PROTECTED] wrote:
-- hd and id are (void *) in C and modelled as type parameters in Haskell
data Descriptor id hd =
Descriptor {uniqueID :: LadspaIndex,
label :: String,
properties :: LadspaProperties,
name, maker, copyright :: String,
portCount :: LadspaIndex,
portDescriptors:: [PortDescriptor],
portNames :: [String],
portRangeHints :: [PortRangeHint],
implementationData :: id,
instantiate:: Descriptor id hd
- LadspaIndex -
Maybe hd,
Oh, LADSPA. Suddenly everything make so much more sense.
I'm glad it does, I probably should have just started a thread asking
for advice for the translation of the struct. It's important to let
people know the source of the problem when asking.
I didn't mention it cause that question was already in HLADSPA's
initial release announcement post
(http://www.mail-archive.com/haskell-cafe@haskell.org/msg17620.html )
and didn't cause any excitement in the list :P.
First, the implementationData is useless to you. Put it in a closure
when building this object:
That has been one of doubts from the begining (please check the
message mentioned above)
I decided to leave it, for compatibility with LADSPA (but you might be
right saying that it's useles and should be removed).
Again, I continue saying that the more a binding resembles the
original library, the easier it would be for a developer who is
familiar with the original library to begin using it.
ladspa_descriptor = do
...
let implementationData = ...
return Descriptor { ... referencing implementationData ... }
No need to export that to the user only to have them pass it back in.
Actually the library requires some C wrapping glue code (which does
the memory management, inits GHC's RTS and does the marshalling) so I
can just omit it and fill in in the wrapper with a NULL value.
Second, you don't want the consumer to pick the hd type. If you're
willing to accept extensions (I think you are), make it existential:
data Descriptor = forall hd. Descriptor { ... }
This will ensure that you can't pass the handles from one plugin to
the methods of another.
This is exactly how it was implemented in the initial release :)
(please check the HLADSPA announcement for details). The Descriptor
posted here is a naive translation from a C struct
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Dynamic types through unsafeCoerce
On 12/13/06, Taral [EMAIL PROTECTED] wrote: On 12/13/06, Alfonso Acosta [EMAIL PROTECTED] wrote: deactivate :: Maybe(hd - IO ()), According to the spec, NULL here means no-op. So instead of using Maybe, just set deactivate = \_ - return () if you see NULL. I considered this solution as well, but is not really acceptable cause the function would be called anyway (which would harm performance). Furthermore is not sematically correct as externally the descriptor would be viewed as having a deactivate. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] cpphs and #pragma
Dimitry Golubovsky [EMAIL PROTECTED] wrote: Is this a bug or a feature that cpphs does not pass the #pragma cpp directive (they disappear in the output)? A feature I suppose. At least, it was a deliberate design choice. The purpose of cpphs is to remove all # directives from the file, leaving only Haskell (or plain text if you prefer). Now I realise that this is not entirely true, since cpphs _does_ leave #line droppings unless you specify the --noline option. But although most Haskell implementations do read and use #line hints, I was not aware of any tools that make further use of #pragma, and indeed quite the opposite - many tools break if they see the latter. In version 0.6 of cpphs: * Recognise and ignore the #pragma cpp directive. Or what command line options could be used to preserve #pragma's in cpphs output? I am happy to add an option (--pragmas maybe?) to preserve #pragma if there is user demand. Check the cpphs darcs repository at http://www.cs.york.ac.uk/fp/darcs/cpphs for new patches. Regards, Malcolm ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Dynamic types through unsafeCoerce
On 12/13/06, Taral [EMAIL PROTECTED] wrote:
Third, we can split handles out as actual objects now:
This idea resembles how a descriptor is modelled in the last version
of HLADSPA. The difference is that a handle is modelled as a type
class and not a record (see
http://www.student.nada.kth.se/~alfonsoa/HLADSPA/HLADSPA-0.2.1/src/HLADSPA.hs
)
data Handle =
Handle {descriptor :: Descriptor,
activate :: IO (),
-- (LadspaIndex,PortData) indicates the portnumber and its data
run :: LadspaIndex - [(LadspaIndex,PortData)] - IO
[(LadspaIndex, PortData)],
deactivate :: IO (),
cleanup :: IO (),
}
I wouldn't quite call this a Handle ... actually it only contains the
functions which operate over a handle (I would better call it
Instance). It lacks the handle itself (the state passed to, and
possibly altered by, the functions of an instance) and makes the
instance stateless.
e.g. you modified
run:: hd -
LadspaIndex -
[(LadspaIndex,PortData)] -
([(LadspaIndex,PortData)], hd),
into
run :: LadspaIndex - [(LadspaIndex,PortData)] -
IO[(LadspaIndex, PortData)]
Now the behaviour of run over the input audio doesn't depend on any
state. That state is a must (and that's why handles are used).
Otherwise things such as a delay effect wouldn't be able to remember
how many samples it did process already between calls to run and thus
wouldn't be feasible to implement.
Then you'll want helpers that use Control.Exception.bracket ...
Well, I couldn't find that function in hoogle and it's not present at
http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Exception.html
But I think that you are suggesting is to leave activate or deactivate
undefined in the record if they are not required. Then it should be
checked wheter they are undefined or not controlling if a exception is
raised when attempting to access them.
I don't see how that is an advantage compared to using Maybe. Actually
Nothing is more expressive than omitting the functions and furthermore
I don't think that leaving record fiedls undefined is a good practice
in general.
You can also optionally use cleanup as the finalizer for the
ForeignPtr underlying Handles ...
I don't see what you mean here. I'm not using ForeignPtrs at all.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] c2hs examples?
Does anyone know of any good source of examples if one wants to learn to use c2hs? The documentation that comes with c2hs is a little too sparse when it comes to examples to actually work out how things work. I don't mind looking at some reasonably sized project that uses c2hs (gtk2hs is a little too overwhelming). /M -- Magnus Therning (OpenPGP: 0xAB4DFBA4) [EMAIL PROTECTED] Jabber: [EMAIL PROTECTED] http://therning.org/magnus Software is not manufactured, it is something you write and publish. Keep Europe free from software patents, we do not want censorship by patent law on written works. Zaphod grinned two manic grins, sauntered over to the bar and bought most of it. -- Zaphod in paradise. pgpcv5P9hdN7Q.pgp Description: PGP signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Dynamic types through unsafeCoerce
On 12/13/06, Alfonso Acosta [EMAIL PROTECTED] wrote: I don't see what you mean here. I'm not using ForeignPtrs at all. ... you're *writing* a plugin, not using one. Oh. Um... let me think about that one. -- Taral [EMAIL PROTECTED] You can't prove anything. -- Gödel's Incompetence Theorem ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Mozart versus Beethoven (was: Writing Haskell For Dummies ...)
2006/12/12, Kirsten Chevalier [EMAIL PROTECTED]: [snip] I've been thinking about this. Are there really any programmers who are like Mozart in the way you describe? Donald Knuth might be one, or at least, he wrote that he wrote and debugged all of TeX on paper before entering it into a computer and only found 13 more bugs (or something like that), once he did. I don't remember if it was 13 exactly, but 13 more bugs might be the closest that any programmer gets to Mozart, or at least any programmer in the 20th or early 21st century. But, can you imagine waking up in the middle of the night, sitting down, and writing a compiler from start to finish? Well, of course, easily, undergrads do it all the time during finals period. But, one that works, and that contains original ideas? I know some awesome programmers, but I don't think any of them are quite that awesome. Whereas it's conceivable to imagine somebody writing a piece of music that way, or a poem. Does that just mean that computer science has a long way to go in maturation? Or does it mean something else? Maybe you forget one fact : we're talking about people who have exprerience, not undergrad. Moreover, if we talk about experience in one area (for example computer languages, ore opera/classic music (not electro, pop, rock, jazz and so on), I'm sure there're people who have enough experience in compiler to try out a new idea in a short amount of time. Or in other discipline. I think I've read John Carmack wrote *several* 3d engines for each of their titles that throw them away. Another difference with music that strikes me is the level of abstraction : a note is a note. A line of code (especially in a imperative setting) is much more than a line of code. Ok, one can argue that notes interact together but, imo, not in the same way line of code can do. Programming is complex, you have to layer code on codeon code. Music is quite 'direct', you hear it without thinking. Bye, minh thu ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Good Haskell introduction for an Ocaml programmer?
Hello Brian, Tuesday, December 12, 2006, 3:39:41 PM, you wrote: So I was wondering if there was a better introduction for me out there? I'm willing to pay for a book or read something online, whichever. i think that there are not so much FP programmers learning Haskell (comparing to number of imperative/OOP programmers) so you may be out of luck here. you may just skip things that you already know. laziness, advanced type system, monads and type classes would be main new concepts to learn you will find a lot of introductions into monads in the appropriate section of http://haskell.org/haskellwiki/Books_and_tutorials , including introductions for Muchos, Monsters and even starship builders ;) But the best one is http://sigfpe.blogspot.com/2006/08/you-could-have-invented-monads-and.html you will also find here introduction into monad transformers After you have groked what is monad you can read all about monads: http://www.nomaware.com/monads/html/index.html you may also be interested in looking at great introduction into Parsec library - parsing combinators is one of non-trivial application of monads: Parsec, a fast combinator parser (sorry, i remember only title of this page) you may also find interesting my explanation of IO monad: http://haskell.org/haskellwiki/IO_inside page that describes how type classes works and why they are different to OOP classes: http://haskell.org/haskellwiki/OOP_vs_type_classes also i found interesting to read chapter 7 of GHC users guide which describes all extensions of type system in GHC comparing to Haskell98 standard my another favorite is not about Haskell language but about using it for real-world apps: Tackling the awkward squad: monadic input/output, concurrency, exceptions, and foreign-language calls in Haskell http://research.microsoft.com/Users/simonpj/papers/marktoberdorf/marktoberdorf.ps.gz one more very interesting reading describes main Haskell differences comparing to previous languages: http://research.microsoft.com/~simonpj/tmp/history-v2.pdf -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Mozart versus Beethoven (was: Writing Haskell For Dummies ...)
On Tue, 12 Dec 2006 12:07:37 +0100, Kirsten Chevalier [EMAIL PROTECTED] wrote: On 12/12/06, Patrick Mulder [EMAIL PROTECTED] wrote: Not sure whether this is the right place to discuss computers and programming in general: You're implying that there's a *more* appropriate forum somewhere for discussing analogies between music composition and programming languages? If so, I'd like to know what it is! Maybe the UseNet newsgroup comp.music? -- Met vriendelijke groet, Henk-Jan van Tuyl -- http://Van.Tuyl.eu/ -- Using Opera's revolutionary e-mail client: https://secure.bmtmicro.com/opera/buy-opera.html?AID=789433 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: On improving libraries: wanted list
On Wed, 13 Dec 2006, John Goerzen wrote: [... re System.Cmd.Utils] It could go under System.Posix perhaps. It relies quite heavily on functionality provided by the unix package and the System.Posix.* tree. Take a look at the source at: http://software.complete.org/missingh/browser/src/System/Cmd/Utils.hs ... Comments? Reminder for those just joining the thread, the API we're discussing is http://software.complete.org/missingh/static/doc/System-Cmd-Utils.html Use of executeFile means you inherit its ideas about the argument list. Unless it has been fixed, you can't specify argv[0]. That's fine until you want to specify argv[0] for some reason, then it's a gratuitous compromise to the C interface. If there isn't any special issue that makes execve(2) awkward to use from Haskell, maybe you could use it and avoid executeFile. Otherwise, since argument list is not per man 2 execve, the difference needs to be documented for functions that take an argument list. I find the name PipeHandle confusing, since it turns out there's no open file pointer or any such Handle-like property. pipeLinesFrom seems gratuitous, I mean, can't people use `lines'? pOpen3Raw 3 4 4 ... is bad just because you'll close 4 twice? It seems like something people are bound to do anyway, and not a huge problem to support. For pOpen3, I think I would just say dup unit 0 from this fd, etc., rather than send stdin to this fd which makes sense only if this fd really is a pipe. And of course I'd change redirecting things to pipes to redirecting standard file descriptors, since it will work fine whatever kind of device the fd may actually be. It's clearer to use 0 as the name for UNIX standard input (and 1, 2 for output and error), and explain separately if you think that won't be obvious to the audience. From what I have seen of these pipe functions in other contexts, the hairy stuff happens when people get a process with pipes on both ends, and try to feed data in one end and milk it out on the other. That invariably causes some kind of deadlock. If the API doesn't directly support it, that would probably be just as well. Well, you asked for comments! Donn Cave, [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Re: Re: [Haskell-cafe] Writing Haskell For Dummies Or At Least For People Who Feel Like Dummies When They See The Word 'Monad'
Please note that it may be hard to make a print out of a wikibook. You might want to use Docbook/XML or Latex in a darcs repo- sitory instead. On Mon, Dec 11, 2006 at 03:23:13PM -0500, Matt Revelle wrote: Sorry, wasn't sure I had clearly expressed that it's possible to have an open book end up as a dead-tree book. Either way, I'm interested in helping. On 12/11/06, Kirsten Chevalier [EMAIL PROTECTED] wrote: It matters to me; if I'm going to put work into this, then that's what I want the result to be. I'm happy, of course, for projects that I am not involved in to use whatever publishing mechanisms that the people involved in those projects prefer. ___ 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] Request for a Simple Pretty Printing library
Hi, I've been using the HughesPJ pretty printing library, but I need a new combinator: wrap :: String - Doc - String - Doc wrap prepend doc append = ... The semantics of this would be that the text is prepended and appended to the doc when rendered, but does not alter the pretty printing at all. The idea of this is to support printing with HTML rendering: wrap span class='keyword' (text case) /span The HughesPJ library is 1000 lines long, so will be quite a lot of work to change this to get it working properly. Is there a simpler pretty printing library, with source code available somewhere? Ideally using the same interface. Of course, if anyone knows how to make this combinator using the existing library, or using another existing library, I'd appreciate it. Thanks Neil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Request for a Simple Pretty Printing library
On Wed, Dec 13, 2006 at 08:58:25PM +, Neil Mitchell wrote: I've been using the HughesPJ pretty printing library, but I need a new combinator: wrap :: String - Doc - String - Doc wrap prepend doc append = ... The semantics of this would be that the text is prepended and appended to the doc when rendered, but does not alter the pretty printing at all. The idea of this is to support printing with HTML rendering: wrap span class='keyword' (text case) /span The HughesPJ library is 1000 lines long, so will be quite a lot of work to change this to get it working properly. I am not sure it will work, but it's sufficiently easy to try. Look at the innards of HughesPJ, especially the TextBeside data constructor. Its second parameter is an Int holding the length of the text. Perhaps if you created TextBeside with your HTML markup, but with 0 length field, things would be laid out properly. Something like: wrap prepend doc append = zeroText prepend doc zeroText append zeroText s = textBeside_ (Str s) 0 Empty Best regards Tomasz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Request for a Simple Pretty Printing library
The Prettyprint library you can download from: http://www.cs.uu.nl/wiki/HUT/Download and is described on: http://www.cs.uu.nl/wiki/HUT/PrettyPrintingCombinators contains amongst others the following code: data Doc= Empty | Char Char -- invariant: char is not '\n' | Text !Int String -- invariant: text doesn't contain '\n' | Line !Bool-- True = when undone by group, do not insert a space | Cat Doc Doc | Nest !Int Doc | Union Doc Doc -- invariant: first lines of first doc longer than the first lines of the second doc | Column (Int - Doc) | Nesting (Int - Doc) text = Empty text s = Text (length s) s so if you define now: wrap l t r = Text 0 l | text t | Text 0 r you should be set and done, Doaitse Swierstra On Dec 13, 2006, at 10:31 PM, Tomasz Zielonka wrote: On Wed, Dec 13, 2006 at 08:58:25PM +, Neil Mitchell wrote: I've been using the HughesPJ pretty printing library, but I need a new combinator: wrap :: String - Doc - String - Doc wrap prepend doc append = ... The semantics of this would be that the text is prepended and appended to the doc when rendered, but does not alter the pretty printing at all. The idea of this is to support printing with HTML rendering: wrap span class='keyword' (text case) /span The HughesPJ library is 1000 lines long, so will be quite a lot of work to change this to get it working properly. I am not sure it will work, but it's sufficiently easy to try. Look at the innards of HughesPJ, especially the TextBeside data constructor. Its second parameter is an Int holding the length of the text. Perhaps if you created TextBeside with your HTML markup, but with 0 length field, things would be laid out properly. Something like: wrap prepend doc append = zeroText prepend doc zeroText append zeroText s = textBeside_ (Str s) 0 Empty Best regards Tomasz ___ 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] less than helpful GHC error message
Consider the terminal session at the bottom of this message.
The extra xc in Test.hs was the result of me missing CTRL during an
Emacs command (I'm guessing...). Unfortunately this took 30 minutes to
find since I had far more than two modules and the error message
doesn't point this out. Sure it's a silly mistake to make, but I'm
guessing it's pretty common.
I'm running GHC 6.6 on a PPC Mac.
I know pragmas are wierd things, but could this error message be improved?
Thanks,
Nick
$ head -n 1 Main.hs Test.hs
== Main.hs ==
module Main where
import Test
main = test
== Test.hs ==
xc{-# OPTIONS -fglasgow-exts #-}
module Test where
test = putStrLn weee
$ ghc --make Main
no location info: file name does not match module name `Main'
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Request for a Simple Pretty Printing library
Hi Something like: wrap prepend doc append = zeroText prepend doc zeroText append zeroText s = textBeside_ (Str s) 0 Empty Thanks, that works great! Is there likely to be any support for adding this to the standard library? I'd rather not have to fork a version of HughesPJ to get this feature. Thanks Neil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Mozart versus Beethoven (was: Writing Haskell For Dummies ...)
On 12/13/06, minh thu [EMAIL PROTECTED] wrote: Another difference with music that strikes me is the level of abstraction : a note is a note. A line of code (especially in a imperative setting) is much more than a line of code. Ok, one can argue that notes interact together but, imo, not in the same way line of code can do. Programming is complex, you have to layer code on codeon code. Music is quite 'direct', you hear it without thinking. I'm not sure that's right, though. Just as a line of code seems to be simple but what's going on at the hardware level is very complex, a musical note is simple but what goes in inside your brain when you hear one is extremely complex, poorly understood, and the details of it aren't accessible to you consciously. You say you hear it without thinking -- exactly, you feel like you're not thinking because of all of the amazingly complicated things that are going on inside. No program is nearly that complex! I suppose I must be channeling Hofstadter. Cheers, Kirsten -- Kirsten Chevalier* [EMAIL PROTECTED] *Often in error, never in doubt One of these days and it won't be long / Going down in the valley and sing my song Gonna sing it loud, sing it strong / Let the echo decide if I was right or wrong -- Bob Dylan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Aim Of Haskell
On 12/13/06, Claus Reinke [EMAIL PROTECTED] wrote: The reason why Haskell is academic-centric is that it was originally conceived by academics, and they were interested in doing research into language design and implementation .. shouldn't we make this used to be academic-centric? I think that's still slightly premature, although it seems like a ton of progress has been made just this year. People outside academia who might be inclined to take on some of those more practical questions are just beginning to notice that Haskell could be useful for them too. .. although just beginning to notice may be accurate on a historical scale, I have the feeling that the actual development is further along than this. at least, there have been sufficiently many and active early adopters for long enough to make a substantial difference. so those practical questions are not being raised, but several of them are actually being addressed. Certainly, and not to in any way denigrate the early adopters' work (and I am, I guess, an early adopter, though not one who's actually contributed much). I guess I was just trying to say to the poster I was replying to that if you're still not happy with the level of practicality of Haskell tools now, either jump in and help improve them yourself, or if you don't want to do that, have a little patience -- they'll get there soon enough. one of the most exciting aspects of Haskell is that pragmatic interest in the language has been growing steadily without academic interest in it declining in any way. as a result, we have a language that represents an interesting mixture of good and useful, although it is not entirely clear yet how long this nice balance will hold. we have had lots of languages that were intended to be well-designed (good, beautiful, ..), but never much used in practice, and we have also had lots of languages that were intended to be pragmatic (practical, useful, ..), without much interest in theoretical beauty. but how many languages are there where the two aspects have converged, with both communities still actively interested in the result? I'm interested to see what's going to happen, too. To answer your question with another, how many languages are there that have quite the same kind of people committed to them that Haskell does? :-) Cheers, Kirsten -- Kirsten Chevalier* [EMAIL PROTECTED] *Often in error, never in doubt Happy is all in your head / When you wake up and you're not dead / It's a sign of maturation / That you've lowered your expectations...--Barbara Kessler ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[2]: [Haskell-cafe] Aim Of Haskell
Hello Alex, Wednesday, December 13, 2006, 8:01:07 PM, you wrote: mailing list, and the usual answer is why?. The authors claim that when thinking about a new version of Lua they don't think of features to add, but what features they can remove. Newspeak is the only language that is decreases, instead of increases, during the time - Orwell, 1984. so, Lua is second one :) -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[2]: [Haskell-cafe] Aim Of Haskell
Hello Malcolm, Wednesday, December 13, 2006, 6:53:56 PM, you wrote: one particular thing that we still lack is something like book Haskell in real world How about: Applications of Functional Programming (Hardcover) by Colin Runciman (Editor), David Wakeling (Editor) Routledge, 1995. unfortunately, it's hard for me to buy on amazon. anyway, i think that Haskell significantly changed during these 10 years and while this book may provide overall picture of how functional languages can be used to develop programs, actual details are far from current state-of-the-art i think that it's also possible to use any other FP-oriented book about commercial applications for functional programming, especially for ML-family of languages, while for details relevant to current Haskell the only good source is awkward squad. so we are still in the situation when there is no books that describes how to use modern Haskell tools to develop these real programs -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] What is a hacker? [was: Mozart versus Beethoven]
Kirsten Chevalier wrote: On 12/12/06, Patrick Mulder [EMAIL PROTECTED] wrote: PS I like the idea of a book Hakell for Hackers Maybe Haskell for People Who Want to Be Hackers? I would never buy a book with such a title, even if I didn't have the slightest clue about programming. However Haskell for Hackers is cool. (Since, of course, one should never apply the term hacker to oneself.) Who told you that? Calling oneself 'hacker' is a sign of healthy self-respect; to the contrary, I don't know anyone who would call themselves wannabe-hacker. I'm not sure whether it's best to aim at people who might be already hackers who want to learn Haskell, or people who are already programmers who want to be Haskell hackers, in particular. I suppose that the first group of people is probably larger. Being a hacker is a matter of attitude and self-definition more than knowledge and experience. A hacker, even if young and lacking experience, reads books for hackers (if at all) not 'how do I become a hacker' books. The attitude is 'gimme the knowledge so i can go ahead and start doing real stuff', not 'oh, there is so much to learn, maybe after 10 years of study and hard work people will finally call me a hacker'. Cheers Ben ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Reversing a string of words: C# v Perl V Ruby v Haskell
ok, i'll bite. why should i prefer join rather than concat in the list monad. and, moreover, why is this a lambdabot trick? i suspect that the answer actually has a deep connection to the 'dummies' thread next door. while any program that produces the right result is correct, there are some that are more correct than others. a good introductory guide to haskell should lead you in that direction. reasoning by analogy, for c++, andy koenig's accelerated c++ had a huge impact on teaching c++ because it didn't start with C or pidgen c++, but instead required the student to accept that many mechanisms would be explained later, but that they should be used -now-. i suspect that being biased towards higher order functions, and writing new functions such that monads (although the more i learn i think that should be typeclasses) can take advantage of those functions, is the skill that needs to be learned / taught. the equivalent of the central dogma of OO, where it's all about objects having identity, state , and behavior. On 12/13/06, Donald Bruce Stewart [EMAIL PROTECTED] wrote: ulfn: On Dec 13, 2006, at 3:54 AM, Yitz Gale wrote: Nice. Here is something similar: reverseWords = concat . reverse . groupBy eqsp where eqsp x y = isSpace x == isSpace y This can be made even nicer using the 'on' function [1]: reverseWords = concat . reverse . groupBy ((==) `on` isSpace) [1] http://www.haskell.org/pipermail/libraries/2006-November/006156.html Lambdabot trick(tm), use 'join' in the [] monad, instead of 'concat' join . reverse . groupBy ((==) `on` isSpace) -- Don ___ 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] Reversing a string of words: C# v Perl V Ruby v Haskell
sdowney: ok, i'll bite. why should i prefer join rather than concat in the list monad. and, moreover, why is this a lambdabot trick? Oh, but you shouldn't prefer it! It's obfuscating! It's a trick simply because lambdabot knows the rewriting: 12:16 dons ?pl reverseWords = concat . reverse . groupBy ((==) `on` isSpace) 12:16 lambdabot reverseWords = join . reverse . groupBy ((==) `on` isSpace) Refactoring autobots to the resuce! i suspect that the answer actually has a deep connection to the 'dummies' thread next door. while any program that produces the right result is correct, there are some that are more correct than others. a good introductory guide to haskell should lead you in that direction. reasoning by analogy, for c++, andy koenig's accelerated c++ had a huge impact on teaching c++ because it didn't start with C or pidgen c++, but instead required the student to accept that many mechanisms would be explained later, but that they should be used -now-. i suspect that being biased towards higher order functions, and writing new functions such that monads (although the more i learn i think that should be typeclasses) can take advantage of those functions, is the skill that needs to be learned / taught. the equivalent of the central dogma of OO, where it's all about objects having identity, state , and behavior. Yes, and I think a proper understanding of higher order functions, parametric and bounded polymorphism and monadic computations is sorely lacking in a lot of undergraduate courses. With monads in C#, and parametric polymorphism in Java, I wonder how long it will be before you're expected to understand these concepts to program real world Java/C#/... -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Aim Of Haskell
well, if Sun hadn't have released a version of smalltalk with a funny c like syntax, you might have seen some interesting developments in the mid 90's On 12/13/06, Claus Reinke [EMAIL PROTECTED] wrote: The reason why Haskell is academic-centric is that it was originally conceived by academics, and they were interested in doing research into language design and implementation .. shouldn't we make this used to be academic-centric? People outside academia who might be inclined to take on some of those more practical questions are just beginning to notice that Haskell could be useful for them too. .. although just beginning to notice may be accurate on a historical scale, I have the feeling that the actual development is further along than this. at least, there have been sufficiently many and active early adopters for long enough to make a substantial difference. so those practical questions are not being raised, but several of them are actually being addressed. It had to happen in a grassroots fashion, and IMO it couldn't have happened until after the rise of distributed open-source development (which, I remind you, didn't start gaining a lot of momentum until not that long ago). one of the most exciting aspects of Haskell is that pragmatic interest in the language has been growing steadily without academic interest in it declining in any way. as a result, we have a language that represents an interesting mixture of good and useful, although it is not entirely clear yet how long this nice balance will hold. we have had lots of languages that were intended to be well-designed (good, beautiful, ..), but never much used in practice, and we have also had lots of languages that were intended to be pragmatic (practical, useful, ..), without much interest in theoretical beauty. but how many languages are there where the two aspects have converged, with both communities still actively interested in the result? claus ___ 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] Request for a Simple Pretty Printing library
doaitse: The Prettyprint library you can download from: http://www.cs.uu.nl/wiki/HUT/Download I've added uulib to the libraries page: http://haskell.org/haskellwiki/Libraries_and_tools/Compiler_tools#Pretty_printing But this makes me wonder: how many other top secret utrecht libraries aren't also documented on the libraries page? No one will know to use them, if they're not on haskell.org libraries page! :) http://haskell.org/haskellwiki/Libraries_and_tools -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Aim Of Haskell
well, if Sun hadn't have released a version of smalltalk with a funny c like syntax, you might have seen some interesting developments in the mid 90's yes, perhaps. but now that funny smalltalk is open source, the self team has been released from indenture (after Scheme and Self people, Sun is known to have hired at least one Haskeller;-), and the strongtalk vm is open source. I'm still a fan of the old ideas in that community, although I no longer expect much from that language itself (it still has features that are fundamentally lacking in Haskell, but Haskell has at least as many features that are fundamentally lacking in Squeak, say; and I tend to the conclusion that it would be easier to start from the Haskell side if one wanted the best of both worlds). but the people who were behind smalltalk are still up to wonderful stuff, just off the mainstream (for instance, anyone interested in one possible future wrt to user interfaces ought to read some of the papers on the croquet project http://en.wikipedia.org/wiki/Croquet_project ; and don't let yourself be fooled by the screenshots - there is much more thought behind that than behind the run-of-the-mill virtual 3d distributed reflective live-programmable multi-user collaborative environment:). but I wasn't saying that there are no other languages with similar convergence effects. I was suggesting that there are few, very few such languages, especially considering the flood of languages in both the academic and the pragmatic camps. being a member of these illustrous few, Haskell has become a conduit for exchange of ideas and problems between the two camps, giving it a distinct advantage over most of its contemporaries. and while it may be true that the effects have only become widely noticable not too long ago, the development has been going on for a long time (one example: Conal Elliot's ideas for Fran had pragmatic needs that used to drive new developments in Hugs/ GHC many years ago). and from watching the development over many years, I have the feeling that the curve is exponential (but perhaps I'm just channelling Kurzweil;-). so even if we are still near the beginning of that curve, perhaps, in the not too distant future, when some group of clever folks starts a project as interesting as Croquet, they'll use Haskell rather than Squeak? for me, the aim of Haskell is to be an enabler for such developments, in both academia and industry, and especially where the two come together. but let's wait and see, shall we?-) Claus ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Designing an object model in Haskell (RESOLVED)
Hi all,
I'm now using existential types. I avoided learning about them because the
name sounded so highly technical and obscure it did not occur to me they
could be related to OO.
Thanks,
-John
On 12/7/06, John Ky [EMAIL PROTECTED] wrote:
Hi,
I've got an object model that I have a difficult time conceptualising how
it might look like in Haskell:
class Element { }
class Inline : Element { }
class ParentInline : Inline {
ListInline children;
}
class Bold : ParentInline { }
class Underline : ParentInline { }
class Link : ParentInline {
String link;
}
class Text : Inline {
String text;
}
class Block : Element { }
class Paragraph : Block {
ListInline paragraph;
}
class Heading : Block {
ListInline heading;
}
class Document : Element {
ListBlock blocks;
}
How best to represent this OO data model in Haskell?
Thanks
-John
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Building the community
One of the great aspects of programming Haskell is the community. We should aim to have the strongest, friendliest, most productive community we can. We're doing a good job so far, can we do even better? Reading this: How to Build a User Community http://headrush.typepad.com/creating_passionate_users/2006/12/how_to_build_a_.html has inspired me to make some suggestions of what *you* can do to help make Haskell the language and community people want to spend time on. * Always encourage newbies to ask questions + I rate us at 8/10 * Encourage newer users--especially those who've been active askers--to start trying to answer questions + we can do more here. If you know the solutoin to a problem, dive in and help out. Canonical, type correct answers preferred! + if you're at the 'intermediate' stage, you can help *now* by contributing to the wiki, solving new user problems, blogging your ideas and code and so on. * Give tips on how to answer questions + Ok. we can put up an article here. Some suggestions: - No questions are bad questions - Code should come with examples of how to run it - Solutions with unsafePerformIO should be discouraged (moreso ;) - Be polite! (we're good at this) * Adopt a near-zero-tolerance Be Nice policy when people answer questions + 8/10, we can do even better I think * Teach and encourage the more advanced users (including moderators) how to correct a wrong answer while maintaining the original answerer's dignity. + Pretty good. I encourage people to point out (privately) and encourage grumpy people to be nicer So dive in! Help out new users, collaborate, contribute to the wiki, release your code, and help make Haskell the language people want to use. -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: On improving libraries: wanted list
jgoerzen: On Wed, Dec 13, 2006 at 04:19:58PM +1100, Donald Bruce Stewart wrote: In particular, you seem to be wanting my pipeBoth function. Note that your proposed String - IO String function type is insufficient because it does not provide a way to evaluate the return value of the function. this kind of functionality seems to be expected by new users (its one of the more common questions on #haskell). Is System.Cmd.Utils in a position to be moved into base alongside System.Cmd and System.Process? It seems quite fundamental for getting work done quickly for script-like haskell programs. It could go under System.Posix perhaps. It relies quite heavily on functionality provided by the unix package and the System.Posix.* tree. Can't we do something like this, on top of System.Process? Do we need unix* stuff anymore? (modulo getting rid of the non-portable stuff) module Lib.Process (popen) where import System.Exit import System.IO import System.Process import Control.Concurrent (forkIO, newEmptyMVar, putMVar, takeMVar) import qualified Control.Exception popen :: FilePath - [String] - Maybe String - IO (String,String,ExitCode) popen file args minput = Control.Exception.handle (\e - return ([],show e,error (show e))) $ do (inp,out,err,pid) - runInteractiveProcess file args Nothing Nothing case minput of Just input - hPutStr inp input hClose inp -- importante! Nothing- return () output - hGetContents out errput - hGetContents err forkIO (Control.Exception.evaluate (length output)) forkIO (Control.Exception.evaluate (length errput)) e - Control.Exception.catch (waitForProcess pid) (\_ - return ExitSuccess) return (output,errput,e) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] type variable question
I'm developing a typesafe record library (akin to HList but starting with key/val pairs and enforcing uniqueness and sorted order of keys). I'm having a GHC problem I've had with other projects and seen comments regarding it in other people's code (HList for instance: GHC doesn't like it's own type to paraphrase). I have a function |update| --update :: forall sel val rec val' rec' . -- SetField sel val rec val' rec' = sel - (val - val') - rec - rec' update sel f rec = rec' where --val :: val val = value sel rec --val' :: val' val' = f val --rec' :: rec' rec' = set sel val' rec The commented out signature is the signature that GHC infers for the function. When I uncomment that signature, it will no longer type check. Why does this happen? Even with the forall and the explicit signatures in the where clause, it chokes. I don't plan on sharing the code for |SetField| because it's that wild looking type class hackery, and the problem isn't specific to this example--I remember having it happen in far simpler cases which I can't seem to find right now... Is there a canonical example example that exhibits this behavior? Or a ticket for it already? I'd like to understand what's happening. Thanks for your time, Nick ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Building the community
On 12/13/06, Donald Bruce Stewart [EMAIL PROTECTED] wrote: * Give tips on how to answer questions + Ok. we can put up an article here. Some suggestions: - Solutions with unsafePerformIO should be discouraged (moreso ;) I'd like to at least suggest a slight qualification here, based on some personal experience. A colleague of mine learned Haskell after having spent a while doing systems programming, and (with the danger of completely misinterpreting him here), the (perceived) lack of unsafePerformIO et. al. led him to conclude that Haskell was a good high-level language, but a certain number of projects would at least require you to write a fair amount of your code in C. Once he saw some code that (safely) used unsafePerformIO - particularly in fps, as I recall - he changed his mind. To this day, he hasn't written any code using unsafe*, but is generally somewhat more interested in Haskell. So, I'd suggest that demonstrating both the use of unsafePerformIO when the question is obviously trending that way and mentioning why it is a bad idea -- perhaps with an example of something that will obviously segfault or otherwise break type safety - is sometimes a better idea than simply not admitting its existence. Also, I strongly support the necromancy/IO analogies. /g -- It is myself I have never met, whose face is pasted on the underside of my mind. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What is a hacker? [was: Mozart versus Beethoven]
On 12/14/06, Benjamin Franksen [EMAIL PROTECTED] wrote: Kirsten Chevalier wrote: (Since, of course, one should never apply the term hacker to oneself.) Who told you that? The Jargon File. But yes, I can anticipate more or less all of the possible responses to *that*, and, point taken. Calling oneself 'hacker' is a sign of healthy self-respect; to the contrary, I don't know anyone who would call themselves wannabe-hacker. Well, I hope so, since I contradict my own advice and call myself a hacker anyway :-) Being a hacker is a matter of attitude and self-definition more than knowledge and experience. A hacker, even if young and lacking experience, reads books for hackers (if at all) not 'how do I become a hacker' books. The attitude is 'gimme the knowledge so i can go ahead and start doing real stuff', not 'oh, there is so much to learn, maybe after 10 years of study and hard work people will finally call me a hacker'. Very reasonable. Very sane. Speaking of the term hacker and of various subcultures, the way in which Haskell and the open-source community seem to have met each other this year just makes me melt with joy. I know it wasn't like that six years ago; the Haskell community was small, and there wasn't exactly such a thing as the open-source community (and please let's not have a free software vs. open source debate, because I've heard that all before, too). I don't know exactly what happened in the meantime, besides the miracle of this vast series of tubes that we cann the Internet, but someone should really be writing a sociology paper about it. Cheers, Kirsten -- Kirsten Chevalier* [EMAIL PROTECTED] *Often in error, never in doubt The geeks shall inherit the earth. -- Karl Lehenbauer ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Interpreter output in color
Forward to haskell-cafe@haskell.org for further discussion. - Forwarded message from Walter Moreira [EMAIL PROTECTED] - Date: Thu, 14 Dec 2006 06:46:44 + From: Walter Moreira [EMAIL PROTECTED] To: haskell@haskell.org Subject: [Haskell] interpreter ouput in color Hi all. I was wondering if some people miss the colored output of some applications, such like the IPython enhanced shell. I've been googling for similar options for Haskell but I found nothing. I feel that the type error messages, for example, would be a lot more readable (or at least quicker to read). Is there a way to write plugins for ghci to get this?, or do you people have some suggestion about what would be the easiest component to hack for applying colors? Thank you. Cheers, Walter Walter, I think this is a great idea. Currently, there is an existing tool, HsColour: http://www.cs.york.ac.uk/fp/darcs/hscolour/ which does a great job of marking up source files to ansi, html and css output. I think with only a little bit of effort, it could be integrated into ghci (or a ghci wrapper written), that runs each expression in ghci through HsColour. Here's a mockup (the result of dumping ghci's output through HsColour): http://www.cse.unsw.edu.au/~dons/tmp/colour-ghci.png Is someone interested in writing a wrapper over ghci that pipes input and output through HsColour? We might have to modify HsColour slightly to take input from stdin. I've put up an initial wiki page for this here: http://haskell.org/haskellwiki/GHCi_in_colour If you've thoughts on how to implement this- -- or want to just go ahead and do it, please dive in! -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
