multiplatform GUI design with parallelized lazy functional language 
Author Message
 multiplatform GUI design with parallelized lazy functional language

Hi All.

soon I have to design my next software prototype destined for win32
and Linux. And again with GUI :(
I'd like to use lazy functional language with good abilities to
(imlicit) parallelized execution as basis for this next software with
GUI. Currently I see the following cases for this flavour:

- Allegro Lisp from Franz Inc (a lot of money)
- Haskell + "Gtk+HS" (is it OK with gph?)
- OCaml + Zoggy
- Mozart (without GUI builder?)

Thus, my questions to audience are:

Q1. what is a reliable lazy functional language with good abilities to
(imlicit) parallelized execution  to use it as a basis for the
software with GUI?

if any...

Q2: what kind of environment/library I can use for GUI design with
this nice language?

if any...

Q3. Are there any nice distributions?

P.S. I'd be thankful if your answers will be Cc'ed to
v.khamenia at biovision dot de

kind thanks,
Valery A.Khamenya



Fri, 08 Jul 2005 19:31:44 GMT  
 multiplatform GUI design with parallelized lazy functional language

Quote:
> Hi All.

> soon I have to design my next software prototype destined for win32
> and Linux. And again with GUI :(
> I'd like to use lazy functional language with good abilities to
> (imlicit) parallelized execution as basis for this next software with
> GUI. Currently I see the following cases for this flavour:

> - Allegro Lisp from Franz Inc (a lot of money)

you missed
Xanalys LispWorks (which is far less money) see:
http://www.lispworks.com/buy/index.html
Quote:

> Q2: what kind of environment/library I can use for GUI design with
> this nice language?

CAPI (standard) or CLIM

Quote:

> if any...

> Q3. Are there any nice distributions?

Well yes LisWorks is a professional product.

Regards
Friedrich



Fri, 08 Jul 2005 20:33:33 GMT  
 multiplatform GUI design with parallelized lazy functional language

Quote:
> Hi All.

> soon I have to design my next software prototype destined for win32
> and Linux. And again with GUI :(
> I'd like to use lazy functional language with good abilities to
> (imlicit) parallelized execution as basis for this next software with
> GUI. Currently I see the following cases for this flavour:

> - Allegro Lisp from Franz Inc (a lot of money)
> - Haskell + "Gtk+HS" (is it OK with gph?)
> - OCaml + Zoggy
> - Mozart (without GUI builder?)

> Thus, my questions to audience are:

> Q1. what is a reliable lazy functional language with good abilities to
> (imlicit) parallelized execution  to use it as a basis for the
> software with GUI?

well, Ocaml is not a lazy language, just a functional one, Haskell
have no implicit parallelized execution, but I believe that there are
version with some parallelized execution.

But, I don't see in your example :
- Concurent Clean, which should have some parallelized execution
- Erlang

that may both be of some interest for parallelized execution and GUI.

Quote:
> P.S. I'd be thankful if your answers will be Cc'ed to
> v.khamenia at biovision dot de

I may have done it, If you hadn't spam protected your address, I'm to
lazy.

--
Rmi Vanicat

http://dept-info.labri.u-bordeaux.fr/~vanicat



Fri, 08 Jul 2005 20:24:55 GMT  
 multiplatform GUI design with parallelized lazy functional language
I'm only just started learning Oz, but I am extremely impressed with
it.

You have lazy evaluation if you want it by just adding "lazy" to the
definition of a function, and true concurrency was a primary design
goal, and so is extremely easy to write.

The developmemt environment is based on a customised Emacs, and works
extremely well, but obviously there are no drag-and-drop of GUI
components, (or at least I don't know of any!).

Finally, the principal GUI is based on Tk which is as close to a
cross-platform industry standard (used by almost all scripting
languages) that you are likely to get.



Sat, 09 Jul 2005 18:55:33 GMT  
 multiplatform GUI design with parallelized lazy functional language

| I'm only just started learning Oz, but I am extremely impressed with
| it.
|
| You have lazy evaluation if you want it by just adding "lazy" to the
| definition of a function, and true concurrency was a primary design
| goal, and so is extremely easy to write.

What is "true" concurrency?

thanks,



Sun, 10 Jul 2005 01:23:13 GMT  
 multiplatform GUI design with parallelized lazy functional language

Quote:


> | I'm only just started learning Oz, but I am extremely impressed with
> | it.
> |
> | You have lazy evaluation if you want it by just adding "lazy" to the
> | definition of a function, and true concurrency was a primary design
> | goal, and so is extremely easy to write.

> What is "true" concurrency?

Maybe Oz' concurrency model should be dubbed "extremely lightweight". Oz
pages claim that running ten thousands of processes incurs no noticeable
overhead. Even if that claim is exaggerated, it's obviously lightweight
enough that one can use concurrency as a structuring tool, instead of as
a thing to be avoided as far as possible.

Concurrency is a lot easier if you're writing in functional style: you
can't have race conditions if all data is immutable ;-) (in that case,
people tend to name the code "parallel" instead of "concurrent").

Regards,
Joachim
--
This is not an official statement from my employer.



Sun, 10 Jul 2005 20:04:58 GMT  
 multiplatform GUI design with parallelized lazy functional language

  > Maybe Oz' concurrency model should be dubbed "extremely
  > lightweight". Oz pages claim that running ten thousands of
  > processes incurs no noticeable overhead. Even if that claim is
  > exaggerated, it's obviously lightweight enough that one can use
  > concurrency as a structuring tool, instead of as a thing to be
  > avoided as far as possible.

It's probably not exaggerated. Erlang supports 262,000 simultaneous
processes, and the cost of spawning processes and sending
messages remains practically(*) constant (on my Ultra10, 16 us/4 us),
all the way up to the system limit.

The Oz designers have been inspired by, and benchmarked against,
Erlang in regards to concurrency, so it would not be surprising
if they are roughly in the same realm performance-wise.

/Uffe

(*) The deviation was within a microsecond in a ring
benchmark.

--
Ulf Wiger, Senior Specialist,
   / / /   Architecture & Design of Carrier-Class Software
  / / /    Strategic Product & System Management
 / / /     Ericsson Telecom AB, ATM Multiservice Networks



Mon, 11 Jul 2005 20:05:32 GMT  
 multiplatform GUI design with parallelized lazy functional language

Quote:

(snip)
>> I'd like to use lazy functional language with good abilities to
>> (imlicit) parallelized execution as basis for this next software with
(snip)
>well, Ocaml is not a lazy language, just a functional one, Haskell
>have no implicit parallelized execution, but I believe that there are

(snip)

Yes - that's a pity. You'd think that Haskell would lend itself quite
nicely to implicit parallelized execution - I can't help but wonder if
it will be along someday and how hard it will be to realise.

-- Mark



Mon, 11 Jul 2005 22:34:41 GMT  
 multiplatform GUI design with parallelized lazy functional language

Quote:


>   > Maybe Oz' concurrency model should be dubbed "extremely
>   > lightweight". Oz pages claim that running ten thousands of
>   > processes incurs no noticeable overhead. Even if that claim is
>   > exaggerated, it's obviously lightweight enough that one can use
>   > concurrency as a structuring tool, instead of as a thing to be
>   > avoided as far as possible.

> It's probably not exaggerated. Erlang supports 262,000 simultaneous
> processes, and the cost of spawning processes and sending
> messages remains practically(*) constant (on my Ultra10, 16 us/4 us),
> all the way up to the system limit.

I meant the overhead when compared to a sequential implementation.
If I understand you correctly, you're talking about whether concurrency
scales (which is also an important aspect, of course *g*).

Regards,
Joachim
--
This is not an official statement from my employer.



Mon, 11 Jul 2005 22:55:38 GMT  
 multiplatform GUI design with parallelized lazy functional language

Quote:

> Yes - that's a pity. You'd think that Haskell would lend itself quite
> nicely to implicit parallelized execution - I can't help but wonder if
> it will be along someday and how hard it will be to realise.

Well - using GPH seems to be relatively straightforward.  It's
probably much easier for the programmer to work out where to put 'seq's
and 'par's, than for the compiler.

-kzm
--
If I haven't seen further, it is by standing in the footprints of giants



Tue, 12 Jul 2005 15:20:19 GMT  
 multiplatform GUI design with parallelized lazy functional language

Quote:


> > Yes - that's a pity. You'd think that Haskell would lend itself
> > quite nicely to implicit parallelized execution - I can't help but
> > wonder if it will be along someday and how hard it will be to
> > realise.

>  Well - using GPH seems to be relatively straightforward.  It's
>  probably much easier for the programmer to work out where to put 'seq's
>  and 'par's, than for the compiler.

Does GPH use a call-by-need evaluation strategy, or did they change
that? It seems like cbn implies a lot of mutation under the covers,
and that could make parallelization tricky.

--
Neel Krishnaswami



Tue, 12 Jul 2005 20:59:57 GMT  
 multiplatform GUI design with parallelized lazy functional language

Quote:
> Yes - that's a pity. You'd think that Haskell would lend itself quite
> nicely to implicit parallelized execution - I can't help but wonder if
> it will be along someday and how hard it will be to realise.

Mozart/Oz has much of what he asks for right now.

--

natsu-gusa ya   / tsuwamono-domo-ga   / yume no ato
summer grasses  / strong ones         / dreams site

Summer grasses,
All that remains
Of soldier's dreams
(Basho trans. Stryk)



Sun, 17 Jul 2005 16:12:48 GMT  
 
 [ 12 post ] 

 Relevant Pages 

1. Free multiplatform Ada GUI Design Tool

2. Speed of FP languages, prospects (was Re: Benchmarking Lazy Functional Languages)

3. Lazy and Strict Functional languages

4. Benchmarking Lazy Functional Languages

5. Partial Evaluation for Lazy Functional Languages

6. Monitoring (Lazy) Functional Languages

7. Profiling Lazy Functional Languages

8. Time complexity of lazy programs. profiling functional languages

9. Lazy-evaluation functional language for MS DOS

10. Applications for lazy functional languages

11. Functional Programming Languages with Lazy Evaluation

12. Parial Evaluation & Lazy Functional Language

 

 
Powered by phpBB® Forum Software