From: justinhj
Subject: Future of Lisp
Date: 
Message-ID: <1136237346.391149.37240@g43g2000cwa.googlegroups.com>
Some of you may have watched Herb Sutter's 1 hour + lecture on the
future of C++

http://microsoft.sitestream.com/PDC05/TLN/TLN309_files/Default.htm#nopreload=1&autostart=1

Funnily enough the first 1/3 of the talk covers the four new features
which are all already in lisp (familiar theme I know).

1) A "for each" keyword that iterates over sequences without doing an
explicit for( var init, cond, inc) type stuff  (which of course lisp
has in various forms)
2) Automatic type inference via an "auto" keyword (we have dynamic and
non-explicit types already)
3) lambda functions (yep, got those of course)
4) concepts (which we don't really need, as they are a mechanism for
better describing generic template code which we approach differently
in lisp)

The rest of the talk has some pretty nice looking code with some high
level keywords for doing concurrent programming in a future version of
C++, which allows the creation of objects that run functions
asynchronously and an explicit "wait" keyword which allows you to see
where your program will block, as well as declaring return values as
'future' which means they only block when accessed.

The talk made me wonder, what is the future of lisp, if Herb is right
and the future of high performance applications depends upon being able
to take advantage of multiple processors or other forms of hardware
multithreading... what are our current options for writing highly
parallel code in common lisp, and what options are likely to be around
in the next few years?

Justin

From: Marco Antoniotti
Subject: Re: Future of Lisp
Date: 
Message-ID: <1136240340.634620.88840@g49g2000cwa.googlegroups.com>
justinhj wrote:
> Some of you may have watched Herb Sutter's 1 hour + lecture on the
> future of C++
>
> http://microsoft.sitestream.com/PDC05/TLN/TLN309_files/Default.htm#nopreload=1&autostart=1
>
> Funnily enough the first 1/3 of the talk covers the four new features
> which are all already in lisp (familiar theme I know).
>
> 1) A "for each" keyword that iterates over sequences without doing an
> explicit for( var init, cond, inc) type stuff  (which of course lisp
> has in various forms)

CL-ENUMERATIONS in common-lisp.net
(http://common-lisp.net/project/cl-enumeration/ shameless plug)


> 2) Automatic type inference via an "auto" keyword (we have dynamic and
> non-explicit types already)

Type inference for CL is not for the faint of heart

> 4) concepts (which we don't really need, as they are a mechanism for
> better describing generic template code which we approach differently
> in lisp)

What are those?

>
> The rest of the talk has some pretty nice looking code with some high
> level keywords for doing concurrent programming in a future version of
> C++, which allows the creation of objects that run functions
> asynchronously and an explicit "wait" keyword which allows you to see
> where your program will block, as well as declaring return values as
> 'future' which means they only block when accessed.

Macros and a SMOP plus getting the implementors to agree on a portable
interface.

> The talk made me wonder, what is the future of lisp, if Herb is right
> and the future of high performance applications depends upon being able
> to take advantage of multiple processors or other forms of hardware
> multithreading... what are our current options for writing highly
> parallel code in common lisp, and what options are likely to be around
> in the next few years?

Ask your implementor/vendor.

Cheers
--
Marco
From: justinhj
Subject: Re: Future of Lisp
Date: 
Message-ID: <1136248841.780273.80150@g43g2000cwa.googlegroups.com>
Marco Antoniotti wrote:
> > 2) Automatic type inference via an "auto" keyword (we have dynamic and
> > non-explicit types already)
>
> Type inference for CL is not for the faint of heart

You don't need to worry about it most of the time though.

> > 4) concepts (which we don't really need, as they are a mechanism for
> > better describing generic template code which we approach differently
> > in lisp)
>
> What are those?

I didn't understand it in depth, it looked like some way of giving more
information about template functions so that you get better debugging
support. It's like you specify a contract, which is what
specialisations of the functions must adhere to, in order to compile..

> Macros and a SMOP plus getting the implementors to agree on a portable
> interface.
>
> > The talk made me wonder, what is the future of lisp, if Herb is right
> > and the future of high performance applications depends upon being able
> > to take advantage of multiple processors or other forms of hardware
> > multithreading... what are our current options for writing highly
> > parallel code in common lisp, and what options are likely to be around
> > in the next few years?
>
> Ask your implementor/vendor.

Is that good enough though?

All the vendors and implementors support threads and multi-processing
in different ways and varying degrees. If concurrent programming
becomes important to large numbers of lisp programmers perhaps a system
will evolve to fill the gap, like clos.

And if it does then the question is what will it look like? Multilisp
provides an interesting example.
From: ········@gmail.com
Subject: Re: Future of Lisp
Date: 
Message-ID: <1136250112.769878.99830@g14g2000cwa.googlegroups.com>
justinhj wrote:
>Is that good enough though?

>All the vendors and implementors support threads and multi-processing
>in different ways and varying degrees. If concurrent programming
>becomes important to large numbers of lisp programmers perhaps a system
>will evolve to fill the gap, like clos.

the best way to predict the future is to write it

http://dirkgerrits.com/programming/erlisp/ <-- some more proactive
people have already started

>And if it does then the question is what will it look like? Multilisp
>provides an interesting example.

hmm... maybe also check out *lisp (star lisp), qlisp, termite,
scheme48, "higher order distributed objects" (describing kali
scheme)... maybe AIM-410?

Nick
From: justinhj
Subject: Re: Future of Lisp
Date: 
Message-ID: <1136253638.541577.237520@f14g2000cwb.googlegroups.com>
········@gmail.com wrote:
> justinhj wrote:
> >Is that good enough though?
>
> >All the vendors and implementors support threads and multi-processing
> >in different ways and varying degrees. If concurrent programming
> >becomes important to large numbers of lisp programmers perhaps a system
> >will evolve to fill the gap, like clos.
>
> the best way to predict the future is to write it

I agree but I am just asking questions out of interest rather than some
pressing need for a concurrent common lisp.

> http://dirkgerrits.com/programming/erlisp/ <-- some more proactive
> people have already started

Looks very interesting, although I'm not sure how you can tell they are
more proactive than I am, since you have no idea what projects I am
currently working on?

Justin
From: ········@gmail.com
Subject: Re: Future of Lisp
Date: 
Message-ID: <1136277108.736495.14850@g14g2000cwa.googlegroups.com>
>> http://dirkgerrits.com/programming/erlisp/ <-- some more proactive
>> people have already started

>Looks very interesting, although I'm not sure how you can tell they are
>more proactive than I am, since you have no idea what projects I am
>currently working on?

I guess I came off little more smarmy than intended... How about "some
proactive people have already started" or "some of the the more
proactive people around here have already started"? 

regrets

Nick
From: justinhj
Subject: Re: Future of Lisp
Date: 
Message-ID: <1136304251.257987.235310@f14g2000cwb.googlegroups.com>
········@gmail.com wrote:
> >> http://dirkgerrits.com/programming/erlisp/ <-- some more proactive
> >> people have already started
>
> >Looks very interesting, although I'm not sure how you can tell they are
> >more proactive than I am, since you have no idea what projects I am
> >currently working on?
>
> I guess I came off little more smarmy than intended... How about "some
> proactive people have already started" or "some of the the more
> proactive people around here have already started"?
>
> regrets
> 
> Nick

Maybe I am too sensitive, no offense taken ;-)
From: Ulrich Hobelmann
Subject: Re: Future of Lisp
Date: 
Message-ID: <41uu0kF1gbikbU1@individual.net>
········@gmail.com wrote:
> hmm... maybe also check out *lisp (star lisp), qlisp, termite,
> scheme48, "higher order distributed objects" (describing kali
> scheme)... maybe AIM-410?

I don't know about the others, but Scheme48 threads are based on 
continuations, so they aren't SMP-able OS-level threads.  Of course that 
has its advantages too...

I hear some CLs used to have user-level threads too, so that doesn't 
seem like a huge step forward, even though Scheme48 is quite a nifty 
implementation.

-- 
the bottom line is that a JavaSchool that won't teach C and won't teach
Scheme is not really teaching computer science, either.  --  Joel Spolsky
From: ········@gmail.com
Subject: Re: Future of Lisp
Date: 
Message-ID: <1136338992.031247.65640@o13g2000cwo.googlegroups.com>
http://bc.tech.coop/blog/050117.html

came across this by accident today.

Nick
From: justinhj
Subject: Re: Future of Lisp
Date: 
Message-ID: <1136394356.618217.314230@o13g2000cwo.googlegroups.com>
········@gmail.com wrote:
> http://bc.tech.coop/blog/050117.html
>
> came across this by accident today.
>
> Nick

Thanks I missed that link when googling on the subject.

Had some thoughts on this last night. The video link I posted from Herb
Sutters presentation is about what they are doing as implementors of
C++ to enable concurrent processing. They want to abstract it as much
as possible so that how the code works under the hood is transparent to
the user, giving them more options for current and future
optimizations.

Erlisp seems to be a good start but it seems that there is stuff that
could be concurrent in lisp, under the hood, without the user knowing
or caring... certain mapcar and loop operations, let* statements and so
on.
From: lin8080
Subject: Re: Future of Lisp
Date: 
Message-ID: <43BAB267.5BE51BAA@freenet.de>
justinhj schrieb:

... what are our current options for writing highly
> parallel code in common lisp, and what options are likely to be around
> in the next few years?

My head thinks about: )loops around there(

  simulate masiv parallel

Sicne every CPU has a limit command-structure, it should be possible to
take this and simulate as much CPUs you want. 
Modern processors work with 3GHz and 64bits. That is enough to create a
test-scenario for old 8-bit apps.
When you have such a program you can let it run with threading or what
else should be available.

lin
From: Joe Marshall
Subject: Re: Future of Lisp
Date: 
Message-ID: <1136315603.723441.192490@z14g2000cwz.googlegroups.com>
Using a single CPU to simulate multiple slower CPUs is imperfect
because it is
tricky to emulate true parallelism with time-slice multiplexing.  For
example,
busses that support multiple CPUs have arbitration logic to handle
simultaneous
requests.  A single CPU can never trigger this logic and a multiplexing
scheme
that switches on instruction boundaries could never issue simultaneous
requests.
Writing an emulator that exhibited *all* the interesting failure modes
and race conditions
would be almost as challenging as writing the thread library that
masked them all.
From: lin8080
Subject: Re: Future of Lisp
Date: 
Message-ID: <43BC1756.EF3A4BD4@freenet.de>
Joe Marshall schrieb:

> Using a single CPU to simulate multiple slower CPUs is imperfect...

jaja, hmmm

> Writing an emulator that exhibited *all* the interesting failure 
> modes and race conditions would be almost as challenging as 
> writing the thread library that masked them all.

Think I give you an example to what circles in my head around.

0110 1001 is everywhere in use. It is either one signal or no signal.
All 8 cables together give a value for interpreting by the processor.
Note: it uses 8 times 0 or 1 to say something to the CPU.
There is no way to say anything at the same time as often you want, only
possible to say this, than that, then the next. Till now. 

Therefor I search for a way to be able to say ie. 5 different things to
a processor and expect no errors. All would say rise the number of CPUs,
but thats not the thing that support *massive* parallel. So I look to
the good old radio-technique. It is cheap and needs no additional
infrastructure. There it is possible to send more than one signal per
time and it is handeled in a correct way by every radio (and TV). 

But now, how to translate bits for useable radio-signals? State of my
personal simulation is to set bit1 to 288Hz, bit2 to 320Hz, ... (+send
out a wav-file 4fun), go to physik algorithms (lots of sin and cos
there) and do some data processing this way and finally go the way down
to bits to see results. It is very very slow but lisp operates perfect
to that and for me this sim is still funny.  

Thats where the simulation beginns. It works sequentiall on a single
CPU, but you can add as many CPUs you want. It produces signals with a
none yet existing table (standart, something like the ASCI code) and
sends this out, over a cable or a antenna. You need to translate bits
into waves. Now you can mix signals from different CPUs to generate new
signals for further processing. This can be done in magnetic fields or
during transportation.

As long as every CPU givs out one signal (byte, word, dword, ...) after
the other you can take all CPU-signals in one radiosignal (and there are
ca. 3 times more processors out than humans on this planet). Else there
are more than one frequencies available just more as today for
radiosignals. And these signals can be up and down modulated, eg for
better transportation or sorting mechanics. 

Waves have some trickier ways to manipulate themself in real time
(during runtime, as some would say), they have a phase, an amplitude and
some other goodies to work on datas they include - and waves are at
maximum of speed (worldwide)! Bits are so stupied compared to that.

The problem lies in the way how to interpret this, means to find exactly
one signal-group for a processing CPU (or a cluster) and ignore all the
rest (this should be necessary to use bits and waves together, but not
for waves only). To say it clear, I know no other way than sequentially
translate wave-packed information to the input of a single CPU without
loosing the stream(s). So I guess, this can make CPUs obsolete. You get
realtime processing and can store signals like music today or find some
other ways. There will be no old datas, maybe something like the todays
WLANs represent. 

Sure, its not more than an idea, and I'am sure there are other ways
also. These days old radio go to the trash and digitals come in just
like give an old body new clothes, so you do not need to spend more
money to realiese massive paralell processing.

stefan
listen to the sound of my CPUs :)
From: Tim X
Subject: Re: Future of Lisp
Date: 
Message-ID: <873bjo62ls.fsf@tiger.rapttech.com.au>
"justinhj" <········@gmail.com> writes:

> Some of you may have watched Herb Sutter's 1 hour + lecture on the
> future of C++
> 
> http://microsoft.sitestream.com/PDC05/TLN/TLN309_files/Default.htm#nopreload=1&autostart=1
> 
> Funnily enough the first 1/3 of the talk covers the four new features
> which are all already in lisp (familiar theme I know).
> 
> 1) A "for each" keyword that iterates over sequences without doing an
> explicit for( var init, cond, inc) type stuff  (which of course lisp
> has in various forms)
> 2) Automatic type inference via an "auto" keyword (we have dynamic and
> non-explicit types already)
> 3) lambda functions (yep, got those of course)
> 4) concepts (which we don't really need, as they are a mechanism for
> better describing generic template code which we approach differently
> in lisp)
> 
> The rest of the talk has some pretty nice looking code with some high
> level keywords for doing concurrent programming in a future version of
> C++, which allows the creation of objects that run functions
> asynchronously and an explicit "wait" keyword which allows you to see
> where your program will block, as well as declaring return values as
> 'future' which means they only block when accessed.
> 
> The talk made me wonder, what is the future of lisp, if Herb is right
> and the future of high performance applications depends upon being able
> to take advantage of multiple processors or other forms of hardware
> multithreading... what are our current options for writing highly
> parallel code in common lisp, and what options are likely to be around
> in the next few years?
> 

I'm not sure how important concurrent/parallel/threaded processes
really are for lisp or for programming generally. There are certainly
classes of problems which can really benefit from being able to
exploit concurrency, but to some extent, I suspect that many of the
problems which were originally identified as benefiting from
concurrency have already benefited from faster architectures. I think
we are really going to see more immediate benefits from
multi-processor based architectures at the OS level where programs are
more efficiently scheduled between available processes rather than
individual programs themselves taking advantage of multiple
processors.

Writing a program that takes advantage of concurrency adds
considerable complexity and unless there is a real benefit in doing
so, its probably better not to. One of the most interesting
programming experiences I ever had was working on concurrent systems
using occum, concurrent ada (and another language whose name excapes
me) back in the late 80's early 90's. I was also lucky enough to have
access to programming on a hypercube based architecture where bit
arithmetic was used to address individual cpus within the cube. The
one thing I learned from this experience is that concurrent
programming takes a whole different mindset. I've seen many people
come unstuck because of basic incorrect assumptions regarding sequence
of execution, race conditions, deadlocks and starvation. 

So, while threading support and higher level support for parallel
programming would be nice, I don't see it as essential - there will
still be a very large domain of problems which can be adequately
addressed without these features. However, implementing them would be
a very interesting project.

Tim

-- 
Tim Cross
The e-mail address on this message is FALSE (obviously!). My real e-mail is
to a company in Australia called rapttech and my login is tcross - if you 
really need to send mail, you should be able to work it out!
From: justinhj
Subject: Re: Future of Lisp
Date: 
Message-ID: <1137534990.038852.284340@g43g2000cwa.googlegroups.com>
Tim X wrote:
> "justinhj" <········@gmail.com> writes:
>
> > Some of you may have watched Herb Sutter's 1 hour + lecture on the
> > future of C++
> >
> > http://microsoft.sitestream.com/PDC05/TLN/TLN309_files/Default.htm#nopreload=1&autostart=1
> >
> > Funnily enough the first 1/3 of the talk covers the four new features
> > which are all already in lisp (familiar theme I know).
> >
> > 1) A "for each" keyword that iterates over sequences without doing an
> > explicit for( var init, cond, inc) type stuff  (which of course lisp
> > has in various forms)
> > 2) Automatic type inference via an "auto" keyword (we have dynamic and
> > non-explicit types already)
> > 3) lambda functions (yep, got those of course)
> > 4) concepts (which we don't really need, as they are a mechanism for
> > better describing generic template code which we approach differently
> > in lisp)
> >
> > The rest of the talk has some pretty nice looking code with some high
> > level keywords for doing concurrent programming in a future version of
> > C++, which allows the creation of objects that run functions
> > asynchronously and an explicit "wait" keyword which allows you to see
> > where your program will block, as well as declaring return values as
> > 'future' which means they only block when accessed.
> >
> > The talk made me wonder, what is the future of lisp, if Herb is right
> > and the future of high performance applications depends upon being able
> > to take advantage of multiple processors or other forms of hardware
> > multithreading... what are our current options for writing highly
> > parallel code in common lisp, and what options are likely to be around
> > in the next few years?
> >
>
> I'm not sure how important concurrent/parallel/threaded processes
> really are for lisp or for programming generally. There are certainly
> classes of problems which can really benefit from being able to
> exploit concurrency, but to some extent, I suspect that many of the
> problems which were originally identified as benefiting from
> concurrency have already benefited from faster architectures. I think
> we are really going to see more immediate benefits from
> multi-processor based architectures at the OS level where programs are
> more efficiently scheduled between available processes rather than
> individual programs themselves taking advantage of multiple
> processors.
>
> Writing a program that takes advantage of concurrency adds
> considerable complexity and unless there is a real benefit in doing
> so, its probably better not to. One of the most interesting
> programming experiences I ever had was working on concurrent systems
> using occum, concurrent ada (and another language whose name excapes
> me) back in the late 80's early 90's. I was also lucky enough to have
> access to programming on a hypercube based architecture where bit
> arithmetic was used to address individual cpus within the cube. The
> one thing I learned from this experience is that concurrent
> programming takes a whole different mindset. I've seen many people
> come unstuck because of basic incorrect assumptions regarding sequence
> of execution, race conditions, deadlocks and starvation.
>
> So, while threading support and higher level support for parallel
> programming would be nice, I don't see it as essential - there will
> still be a very large domain of problems which can be adequately
> addressed without these features. However, implementing them would be
> a very interesting project.
>
> Tim
>
> --
> Tim Cross
> The e-mail address on this message is FALSE (obviously!). My real e-mail is
> to a company in Australia called rapttech and my login is tcross - if you
> really need to send mail, you should be able to work it out!

Well the point of Herb Sutter's Dr Dobb's article "The Free Lunch is
Over", available at http://www.gotw.ca/publications/concurrency-ddj.htm
, is that we have grown used to processors getting faster fairly
consistently as demands for processing power have increased.

Over the next decade or so this is expected to slow down considerably
unless new architecture breakthroughs are made.

If that is correct then developers will not keep up with increasing
user demand for power unless they are able to take advantage of
concurrent architectures.

How true that is I don't know, but I found the above talk interesting
because it showed many of lisps features are being used in
Microsoft's/ANSI's future C++ compiler, and also because of the whole
rise in interest in concurrency.

One of lisps advantages, it seems, is that it can be adapted to support
concurrency (natively) far more rapidly than C++ can.

Justin