Re: [Haskell-cafe] Graphical Haskell

2007-06-22 Thread Pasqualino 'Titto' Assini
This might be of interest:

http://pipes.yahoo.com/pipes/

Best,

titto

On Friday 22 June 2007 11:15:49 peterv wrote:
 Hi,

 Since nobody gave an answer on this topic, I guess it is insane to do it in
 Haskell (at least for a newbie)? :)

 Thanks for any info,
 Peter

 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED] On Behalf Of peterv
 Sent: Wednesday, June 20, 2007 21:48
 To: haskell-cafe@haskell.org
 Subject: [Haskell-cafe] Graphical Haskell

 In the book Haskell School of Expression, streams are nicely explained
 using a graphical flow graph.

 This is also done more or less in
 http://research.microsoft.com/~simonpj/papers/marktoberdorf/Marktoberdorf.p
p t to explain monads and other concepts.

 I would like to create a program that allows you to create such flow
 graphs, and then let GHC generate the code and do type inference.

 I found a paper where Haskell is used to create a GUI application with
 undo/redo etc for creating graphical Basian networks
 (http://www.cs.uu.nl/dazzle/f08-schrage.pdf), so this gave me confidence
 that I could it do all in Haskell.

 Now, instead of generating Haskell code (which I could do first, would be
 easier to debug), I would like to directly create an AST, and use an
 Haskell API to communicate with GHC.

 I already found out that GHC indeed has such an API, but how possible is
 this idea? Has this been done before? I only found a very old attempt at
 this, confusingly also called Visual Haskell, see
 http://ptolemy.eecs.berkeley.edu/%7Ejohnr/papers/visual.html, but I can't
 find any source code for that project.

 I did a similar project in C# that generated C++ code, so I've done it
 before, just not in Haskell.

 Thanks a lot,
 Peter


 ___
 Haskell-Cafe mailing list
 Haskell-Cafe@haskell.org
 http://www.haskell.org/mailman/listinfo/haskell-cafe

 No virus found in this incoming message.
 Checked by AVG Free Edition.
 Version: 7.5.472 / Virus Database: 269.9.1/857 - Release Date: 20/06/2007
 14:18


 No virus found in this outgoing message.
 Checked by AVG Free Edition.
 Version: 7.5.472 / Virus Database: 269.9.1/857 - Release Date: 20/06/2007
 14:18


 ___
 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] Graphical Haskell

2007-06-22 Thread peterv
Hi,

Since nobody gave an answer on this topic, I guess it is insane to do it in
Haskell (at least for a newbie)? :)

Thanks for any info,
Peter

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of peterv
Sent: Wednesday, June 20, 2007 21:48
To: haskell-cafe@haskell.org
Subject: [Haskell-cafe] Graphical Haskell

In the book Haskell School of Expression, streams are nicely explained
using a graphical flow graph.

This is also done more or less in
http://research.microsoft.com/~simonpj/papers/marktoberdorf/Marktoberdorf.pp
t to explain monads and other concepts.

I would like to create a program that allows you to create such flow graphs,
and then let GHC generate the code and do type inference. 

I found a paper where Haskell is used to create a GUI application with
undo/redo etc for creating graphical Basian networks
(http://www.cs.uu.nl/dazzle/f08-schrage.pdf), so this gave me confidence
that I could it do all in Haskell.

Now, instead of generating Haskell code (which I could do first, would be
easier to debug), I would like to directly create an AST, and use an Haskell
API to communicate with GHC. 

I already found out that GHC indeed has such an API, but how possible is
this idea? Has this been done before? I only found a very old attempt at
this, confusingly also called Visual Haskell, see
http://ptolemy.eecs.berkeley.edu/%7Ejohnr/papers/visual.html, but I can't
find any source code for that project.

I did a similar project in C# that generated C++ code, so I've done it
before, just not in Haskell.

Thanks a lot,
Peter


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

No virus found in this incoming message.
Checked by AVG Free Edition. 
Version: 7.5.472 / Virus Database: 269.9.1/857 - Release Date: 20/06/2007
14:18
 

No virus found in this outgoing message.
Checked by AVG Free Edition. 
Version: 7.5.472 / Virus Database: 269.9.1/857 - Release Date: 20/06/2007
14:18
 

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


RE: [Haskell-cafe] Graphical Haskell

2007-06-22 Thread Henning Thielemann

On Fri, 22 Jun 2007, peterv wrote:

 Since nobody gave an answer on this topic, I guess it is insane to do it in
 Haskell (at least for a newbie)? :)

It's certainly an interesting project. Since signal processing is much
like functional programming, a graphical Haskell editor could also serve
as a nice signal processing graph editor.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Graphical Haskell

2007-06-22 Thread Pasqualino 'Titto' Assini

On Friday 22 June 2007 11:21:31 Henning Thielemann wrote:
 On Fri, 22 Jun 2007, peterv wrote:
  Since nobody gave an answer on this topic, I guess it is insane to do it
  in Haskell (at least for a newbie)? :)

 It's certainly an interesting project. Since signal processing is much
 like functional programming, a graphical Haskell editor could also serve
 as a nice signal processing graph editor.

An existing example of which is CAL's Gem Cutter:

http://resources.businessobjects.com/labs/cal/gemcutter-techpaper.pdf 

titto
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Graphical Haskell

2007-06-22 Thread Claus Reinke

Since nobody gave an answer on this topic, I guess it is insane to do it in
Haskell (at least for a newbie)? :)


not necessarily; we're all waiting for your first release?-)


I would like to create a program that allows you to create such flow graphs,
and then let GHC generate the code and do type inference. 


spun off from dazzle, which you've found, there's also blobs:

   http://www.cs.york.ac.uk/fp/darcs/Blobs/


Now, instead of generating Haskell code (which I could do first, would be
easier to debug), I would like to directly create an AST, and use an Haskell
API to communicate with GHC. 


one thing to consider: things get a little more tricky when the generated
haskell and dynamically loaded code is meant to do graphics (such as 
updating the original diagram with the state of the simulation). in particular, 
check that the gui framework actually works via that more circuituous route 
(similar problems to running in ghci instead of ghc).



I already found out that GHC indeed has such an API, but how possible is
this idea? Has this been done before? 


the ghc api is meant to support this kind of endeavours, and it isn't frozen
yet, either: the ghc team is happy to receive feedback about things that work 
or things that could work better.


before the ghc api, before blobs (after dazzle, though;), i did an embedding
of haskell-coloured petri nets in haskell, with a very simplistic graphical
net editor on top of wxhaskell, which generated haskell code for the net,
then called ghci to type-check and run the resulting code with a copy of
the original net graphics to update during simulation (poor man's reflection:):

   http://www.cs.kent.ac.uk/people/staff/cr3/HCPN/

it worked, but some things were annoying: 


- no high-level support for writing graph editors in wxhaskell;
   blobs aims to fix that

- awkward meta-programming and runtime reflection;
   ghc api should help a lot (but i can't see anything wrong with
   letting it work on generated source code first; optimization can
   come latter)

- wxhaskell encourages low-level dependencies, at least when
   you're writing your first wxhaskell programs, because it can
   be rather difficult just to find the function you need, you're
   tempted to use it right there, just to see if it works, and leave
   cleaning up for later, which never comes; 

   gui frameworks are worse than the io monad; try to abstract 
   and limit your uses of gui lib features to as few modules as 
   possible; nicer code, easier to switch to different framework


- abi incompatibility!!^*L$W%*^%*! 


   sorry,-) but that has become the deal breaker for me; it is
   bad enough that there are two major haskell gui libs out
   there, as it means that your clients may have the wrong one
   or none at all, and need to install the one you need; but,
   worse than that, whenever there's a new ghc release, 
   everybody needs to rebuild their gui libs, and if you

   have the latest ghc release and a recent ghc head installed,
   you even need separate copies of the gui lib, etc, etc. 


   so you use a nice high-level language to get a lot done
   in very little very portable code, but instead of distributing
   a few pages of haskell, with build as simple as ghc --make,
   you have to worry about rather huge gui lib installations,
   and you have to worry anew for each ghc release..

btw, i am thinking about reviving my hcpn project, to make 
use of the ghc api, but i'd like to get rid of the binary gui lib 
dependency first. my current take on this is gui lib? no, 
thanks, i'm just  browsing, if you know what i mean?-)


hth,
claus


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


RE: [Haskell-cafe] Graphical Haskell

2007-06-22 Thread peterv
Wow thanks for all the info! This certainly can get me started.

And yet I have some more questions (sorry!):

- Unfortunately this project won't be open source; if my first tests are
successful, I will try to convince my employer (who wants to develop such a
graphical language) to use Haskell for building a prototype instead of
C#/F#/Java. Can Haskell be used for creating commercial projects? When the
product is released, it *will* be downloadable for free, but the source code
won't be (most likely). 

- If my employer agrees on Haskell, and when our first round of investment
is completed, we will be looking for a couple of good Haskell developers.
What would be the best place to look for good Haskell developers? This
mailing list? Ideally development will have to take place in
Antwerp/Belgium, although we might work with remotely located freelancers.
We prefer agile development (SCRUM, and maybe we will be doing extreme
programming, to be decided) with a small group of capable people. To get an
idea of what my employer is doing, visit http://www.nazooka.com. My
colleagues and I wrote most of the software for doing this back in the
1990s, and of course the real work is done by 3D graphics artists.

- Regarding GUIs, does a real FP-style GUI exist instead of those wrappers
around OO GUIs? I did some searches but besides some research papers about
FranTk and wxFruit I only found wrappers such as Gtk2Hs and wxHaskell that
use a lot of monadic IO. It's very hard for an old school OO style
programmer like myself to switch my mind into lazy functional programming
(although I think I've seen the light yesterday when digging deep into the
FRP of the SOE book, LOL ;-).
 
- Functional reactive programming like looks cool (I only looked at the SOE
book, must still look at Yampa), but somehow I feel this is still an active
area of research. What is the latest work on FRP (for GUIs / games /
animation / simulations...)? What are the major open issues? 

- Regarding performance (for real-time simulations, not GUIs), I think the
garbage collector will get really stressed using FRP because of all those
infinite lazy streams; my gut feeling says a generational garbage collector
like Microsoft's .NET could help here (but the gut is often wrong, see
http://www.youtube.com/watch?v=RF3m3f9iMRc for an laugh ;). Regarding the
GC, is http://hackage.haskell.org/trac/ghc/wiki/GarbageCollectorNotes still
up-to-date?  

Okay, that's enough for now. More is less...

- Peter

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Claus Reinke
Sent: Friday, June 22, 2007 14:02
To: haskell-cafe@haskell.org
Subject: Re: [Haskell-cafe] Graphical Haskell

 Since nobody gave an answer on this topic, I guess it is insane to do it
in
 Haskell (at least for a newbie)? :)

not necessarily; we're all waiting for your first release?-)

 I would like to create a program that allows you to create such flow
graphs,
 and then let GHC generate the code and do type inference. 

spun off from dazzle, which you've found, there's also blobs:

http://www.cs.york.ac.uk/fp/darcs/Blobs/
 
 Now, instead of generating Haskell code (which I could do first, would be
 easier to debug), I would like to directly create an AST, and use an
Haskell
 API to communicate with GHC. 

one thing to consider: things get a little more tricky when the generated
haskell and dynamically loaded code is meant to do graphics (such as 
updating the original diagram with the state of the simulation). in
particular, 
check that the gui framework actually works via that more circuituous route 
(similar problems to running in ghci instead of ghc).
 
 I already found out that GHC indeed has such an API, but how possible is
 this idea? Has this been done before? 

the ghc api is meant to support this kind of endeavours, and it isn't frozen
yet, either: the ghc team is happy to receive feedback about things that
work 
or things that could work better.

before the ghc api, before blobs (after dazzle, though;), i did an embedding
of haskell-coloured petri nets in haskell, with a very simplistic graphical
net editor on top of wxhaskell, which generated haskell code for the net,
then called ghci to type-check and run the resulting code with a copy of
the original net graphics to update during simulation (poor man's
reflection:):

http://www.cs.kent.ac.uk/people/staff/cr3/HCPN/

it worked, but some things were annoying: 

- no high-level support for writing graph editors in wxhaskell;
blobs aims to fix that

- awkward meta-programming and runtime reflection;
ghc api should help a lot (but i can't see anything wrong with
letting it work on generated source code first; optimization can
come latter)

- wxhaskell encourages low-level dependencies, at least when
you're writing your first wxhaskell programs, because it can
be rather difficult just to find the function you need, you're
tempted to use it right there, just to see

Re: [Haskell-cafe] Graphical Haskell

2007-06-22 Thread Donald Bruce Stewart
bf3:
 Wow thanks for all the info! This certainly can get me started.
 
 And yet I have some more questions (sorry!):
 
 - Unfortunately this project won't be open source; if my first tests are
 successful, I will try to convince my employer (who wants to develop such a
 graphical language) to use Haskell for building a prototype instead of
 C#/F#/Java. Can Haskell be used for creating commercial projects? When the
 product is released, it *will* be downloadable for free, but the source code
 won't be (most likely). 

It can, and is used. See the industry page, 

   http://haskell.org/haskellwiki/Haskell_in_industry 

they're the big players, there's numerous small groups that have maybe a
few in house Haskell tools.

 
 - If my employer agrees on Haskell, and when our first round of investment
 is completed, we will be looking for a couple of good Haskell developers.

Wonderful.

 What would be the best place to look for good Haskell developers? This
 mailing list? Ideally development will have to take place in
 Antwerp/Belgium, although we might work with remotely located freelancers.
 We prefer agile development (SCRUM, and maybe we will be doing extreme
 programming, to be decided) with a small group of capable people. To get an
 idea of what my employer is doing, visit http://www.nazooka.com. My
 colleagues and I wrote most of the software for doing this back in the
 1990s, and of course the real work is done by 3D graphics artists.

I suspect the best place to advertise is still [EMAIL PROTECTED]
Most jobs seems to be sent here, and its also cheap :-) You have access
to a few thousand competent Haskell people directly.

 - Regarding GUIs, does a real FP-style GUI exist instead of those wrappers
 around OO GUIs? I did some searches but besides some research papers about
 FranTk and wxFruit I only found wrappers such as Gtk2Hs and wxHaskell that
 use a lot of monadic IO. It's very hard for an old school OO style
 programmer like myself to switch my mind into lazy functional programming
 (although I think I've seen the light yesterday when digging deep into the
 FRP of the SOE book, LOL ;-).

gtk2hs is probably the most 'industrial' UI lib.

  
 - Functional reactive programming like looks cool (I only looked at the SOE
 book, must still look at Yampa), but somehow I feel this is still an active
 area of research. What is the latest work on FRP (for GUIs / games /
 animation / simulations...)? What are the major open issues? 
 
 - Regarding performance (for real-time simulations, not GUIs), I think the
 garbage collector will get really stressed using FRP because of all those
 infinite lazy streams; my gut feeling says a generational garbage collector
 like Microsoft's .NET could help here (but the gut is often wrong, see
 http://www.youtube.com/watch?v=RF3m3f9iMRc for an laugh ;). Regarding the
 GC, is http://hackage.haskell.org/trac/ghc/wiki/GarbageCollectorNotes still
 up-to-date?  

Well, best to find out. In practice i've not found GC to be an issue.
Premature optimisation and all that.

 
 Okay, that's enough for now. More is less...
 

-- Don
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Graphical Haskell

2007-06-22 Thread Jon Harrop
On Friday 22 June 2007 16:38:18 peterv wrote:
 - Unfortunately this project won't be open source; if my first tests are
 successful, I will try to convince my employer (who wants to develop such a
 graphical language) to use Haskell for building a prototype instead of
 C#/F#/Java. Can Haskell be used for creating commercial projects? When the
 product is released, it *will* be downloadable for free, but the source
 code won't be (most likely).

We are developing both OCaml and F# into graphical platforms for technical 
computing:

  http://www.ffconsultancy.com/products/smoke_vector_graphics/
  http://www.ffconsultancy.com/products/fsharp_for_visualization/

and are also interested in doing this with Haskell. Our projects are also 
closed source but Smoke is freely available in platform-independent bytecode.

 ...
 - Regarding performance (for real-time simulations, not GUIs), I think the
 garbage collector will get really stressed using FRP because of all those
 infinite lazy streams; my gut feeling says a generational garbage collector
 like Microsoft's .NET could help here (but the gut is often wrong, see
 http://www.youtube.com/watch?v=RF3m3f9iMRc for an laugh ;). Regarding the
 GC, is http://hackage.haskell.org/trac/ghc/wiki/GarbageCollectorNotes still
 up-to-date?

To the best of my knowledge, OCaml is head and shoulders above the 
alternatives in this respect. It is certainly several times faster than F# 
for GC-intensive work. The main reason is that .NET imposes concurrent GC, 
which introduces locks around every allocation and cripples performance when 
value lifetime distributions are typical of a functional language. The Unix 
approach of forking processes seems to be far better suited to functional 
languages (this is not dissimilar to Erlang's GC-per-thread approach).

For example, the time taken to solve the 11 queens problem with the same 
program that filters out int pairs from a list of all board positions:

OCaml: 5s
F#: 30s

Also, the worst case performance of our visualization tools is 5x faster in 
OCaml than it was in C++. Assuming the same is true of Haskell, I think it is 
probably premature to be worrying about GC performance.

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
The OCaml Journal
http://www.ffconsultancy.com/products/ocaml_journal/?e
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


[Haskell-cafe] Graphical Haskell

2007-06-20 Thread peterv
In the book Haskell School of Expression, streams are nicely explained
using a graphical flow graph.

This is also done more or less in
http://research.microsoft.com/~simonpj/papers/marktoberdorf/Marktoberdorf.pp
t to explain monads and other concepts.

I would like to create a program that allows you to create such flow graphs,
and then let GHC generate the code and do type inference. 

I found a paper where Haskell is used to create a GUI application with
undo/redo etc for creating graphical Basian networks
(http://www.cs.uu.nl/dazzle/f08-schrage.pdf), so this gave me confidence
that I could it do all in Haskell.

Now, instead of generating Haskell code (which I could do first, would be
easier to debug), I would like to directly create an AST, and use an Haskell
API to communicate with GHC. 

I already found out that GHC indeed has such an API, but how possible is
this idea? Has this been done before? I only found a very old attempt at
this, confusingly also called Visual Haskell, see
http://ptolemy.eecs.berkeley.edu/%7Ejohnr/papers/visual.html, but I can't
find any source code for that project.

I did a similar project in C# that generated C++ code, so I've done it
before, just not in Haskell.

Thanks a lot,
Peter


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe