On Fri, Feb 8, 2013 at 4:53 PM, David Brown wrote: > There is not just one gorilla, but things are
certainly changing. The
> big driving force is that developers are moving towards bigger cpu cores
> - with ARM being the big one, but not the only choice. "Small"
compiler
> developers can't make toolchains that can compete with gcc or the
"big"
> vendors (Green Hills, Keil, IAR, etc.) - it is simply infeasible for a
> small company to produce a compiler with the features that customers
> want (including modern C++ support), and that also generates good
> quality code. It's too big, too complex, and has to be ready too
fast.
> The market where the small compiler developers could really shine - the
> weird C-unfriendly 8-bit devices - is getting smaller all the time.
That does not prevent small companies to earn money on them.
Take the example from the PIC side, there are quite some small
3rd party compiler vendors (basic and C) which are still alive.
And actually 8-bit are much more widely used than many
people can imagine. Especially there are a lot of specialized
(not general purpose) 8-bit MCUs for the consumer electronics
market. Small compiler vendors could earn money to partner
with the silicon vendors who give the compiler free to their
customers.
I do not see Cortex M0 to be able to displace many 8-bit MCUs,
be it PIC or AVR or many no-name MCUs (which could be
based on Z80 or 6502 core). Actually even 4-bit MCUs are
still alive...
> So the future for companies like Rowley is to do
/exactly/ as the FSF
> envisioned - take gcc, package it with high-quality libraries,
> easy-to-use IDE and debugger, and top-class support.
Is this really what FSF envisioned? Where do you get this from?
But I agree this is a good business approach for smaller
compiler companies.
> In other words, do
> as Paul /has/ done with his ARM tools - as do most other ARM tool
> vendors (Mentor Graphics / CodeSourcery, Red Hat, Code Red, etc.).
At least for the MCU (bare metal) market, these are small players
compared to Keil and IAR. And the first two are big companies
and earn money on the embedded Linux market rather than the
bare metal toolchain. Not so sure how successful Code Red is.
But again I agree that this could be a good business approach.
> But I agree that it is important to keep
competition and choice.
> Fortunately, there still is - even in the ARM market, there are at least
> four serious non-gcc ARM compilers (Keil/ARM, GHS, CodeWarrior and
> llvm). LLVM in particular is a direct competitor to gcc - and its
> existence has had a clear influence on improving gcc in the past few
> generations.
>
Also IAR.
I believe one of the main attractiveness of LLVM is its
non-GPL license.
For reference, this thread will be interesting, from the perspective
of Walter Banks, president of Byte Craft ( http://www.bytecraft.com/ ).
http://microcontrollers.2385.n7.nabble.com/Byte-Craft-turns-30-td66299.html
"It has not been hard to compete with free software. The
performance increase and support that is provided with
our commercial tools is worth the price. The economics
per seat of our tools is about the loaded cost of two man
days. The question becomes is the benefit that commercial
tools provides worth the cost compared to the cost of
maintaining and supporting free tools.
Thirty years later our customers think it is."
So even though I kind of agree that life for (smaller)
3rd party compilers of proprietary MCUs, there are
still a niche to play if you concentrate on what the
customer needs.
Paul,
You compiler for the msp is flat out the best code generator out there.. I thank
you for it and the continued support..
I remember the first 430 project I took on.. it had to fit into a certain part
(pricepoint) with specific features.. All the other compilers at their highest
optimizations failed miserably and were way over the memory limit... You
compiler gave me room to spare and no functions had to be sacrificed...
> From: Paul Curtis
>To: m...
>Sent: Thursday, February 7, 2013 5:13 PM
>Subject: Re: [msp430] What's the best MSP430 Development Enviroment?
>
>
>
>>> However, when things were driven more state-side, things
>>> deteriorated. :-(
>>
>> I only started using the msp430 with the early flash versions, but
maybe
>> the problems I had heard about were from earlier times. I don't
know
>> how the timing fits with when the msp430 "moved" from Germany
to the USA
>> - I did not even know it had roots in Germany.
>
>Eek!
>
>> At what point did the plans for the MSP430X start? I though it was
relatively recently -
>> certainly long after CCS was available.
>
>Oh dear. No. Long before CCS was available, in fact.
>
>>> You know, I really don't give two hoots about TI + GCC +
MSP430. It
>>> is what it is.
>>>
>>
>> Well, for your sake I hope it doesn't affect your sales. But for
the
>> sake of users, including me, I am glad that Red Hat is adding polish to
>> msp430 gcc. It is an excellent compiler - as I said, I much prefer it
>> to CCS, though I haven't tried your tools for comparison.
Certainly if
>> Red Hat can get the debugger working well with the latest version of
the
>> compiler, I would be very happy. In many ways, my ideal would be the
>> CCS IDE and debugger but with gcc as the toolchain - I think CCS has
got
>> quite good as an IDE now with a modern version of Eclipse (not everyone
>> likes Eclipse, of course, but I think recent versions have become a lot
>> smoother and more usable).
>
>Look, another TI-supported compiler in the world is going to make zero
difference to our MSP430 business. As Richard says, we're fighting over
the scraps left over from IAR and CCS. The reason we maintain our compiler and
bring out new versions is to support existing customers and, if new business
comes along, that is a nice bonus. That's the way it is.
>
>GCC can do some wonderful things, for sure. Heck, even clang and LLVM are
sprouting MSP430 support, and that is a lot easier to maintain than GCC. Having
written our MSP430 compiler and tools, I know what we excel at, and GCC
won't do what our tools can do at the link stage. But GCC can do some neat
tricks when compiling. We don't go in for that -- we generate
straight-forward code with a fast code generation algorithm that has excellent
local code generation and a good register allocator.
>
>>
>> And I don't consider myself a "new-age hippie" for using
gcc on a dozen
>> target architectures (though I might accept that title as a fan of
>> command-line gdb). I'm sure most of your ARM toolchain users also
view
>> themselves as professional developers rather than
"hippies".
>>
>
>The new-age hippie jibe was at the nouveau "engineers" that are
now being churned out using "compile in the cloud" tools, or whatever
is in vogue these days. You know, #include
>
>At least I know how my compiler actually works. All of it. You can't
say that about GCC or LLVM or clang.
>
>I've rambled enough now. I'm firmly in the Wirth camp when it
comes to compilers.
>
>-- Paul.
Reply by David Brown●February 8, 20132013-02-08
On 08/02/13 01:25, Jon Kirwan wrote: > On Thu, 7 Feb 2013 23:11:10 +0000, Paul wrote:
>
>>>
>>> Lambdas are beautiful.
>>>
>>> I HATE the C++ syntax for them, though. Damn the committee
>>> people! Anyone could do better. And why in the heck does one
have
>>> to manually add text to "help" the compiler do
closures?
>>
>> Not having even looked at implementing C++ lambdas, I couldn't
say
>> why the capture list is required.
>> That's a point. Without actually _implementing_ something,
it's hard
> to be sure what motivated them. So I take that point.
>
> But... C# and VB.NET both do the capture without any programmer
> involvement. It seems to me that if the variables are in scope which
> they must be if they are being used, and this should apply to C++ as
> well as the others, then the compiler has all the necessary
> information to know what needs to be captured and how.
Forgive me if I get this wrong - I haven't actually used C++11 lambdas
yet (though I have used them a lot in Python). And I haven't tested
this code at all.
void foo() {
int a, b, c;
[] { return; }; // Capture nothing
[=] { return a + b; } // Capture all used by value
[&] { return a + b; } // Capture all used by reference
[a] { return a; } // Capture a used by value
[&a] { return a; } // Capture a used by reference
[=, a] { return a; } // Capture a used by reference,
// all other used by value
[&, a] { return a; } // Capture a used by value,
// all other used by reference
}
In other words, you can explicitly state the capture list, which is
important if you have a mixture of references and values, or if it makes
your code clearer and prevents accidents. Or you can specify a default
capture method for any other variables that are used, without having to
list them.
Does that answer your question, or am I misunderstanding something?
> When I think about exceptions I'm not so sure
anymore, but then I
> realize that the C++ compiler does it fine when the list is
> hand-coded. So that can't be the problem.
>
> Which leaves me without a paddle, really. What could they possibly
> have been thinking? If expressing a list explicitly makes a
> difference somehow, how then does it? What could possibly be the
> issue, Paul? Can you think of ANYTHING, even hypothetically, that
> could explain how an explicit list would solve something that the
> lack of one couldn't? If the variable is in scope, it's in scope.
If
> not, not. The list changes none of that.
>
> Oh, well.
>
> It bugs me and it does so because I can't think of a good excuse
for
> what passed through committee.
What bugs me most about the committees is why the C guys and the C++
guys can't get together and /agree/ on implementing the same features in
the same way. What possible excuse do they have for one lot picking
"static_assert" (C++0x) and the other picking
"_Static_assert" (C1x) ?
Sure, you can #include <assert.h> to get "static_assert" in C -
but they
should be consistent to start with. And why can you not use designated
initialisers and compound literals in C++?
Still, the C++ people should get credit for the "auto" keyword - it
makes template code /far/ clearer.
>>>> I'm not sure you really
appreciate a language until you write a
>>>> compiler or interpreter for it. And I'm not sure I will
ever
>>>> appreciate the finer details of C++ because I have no
intention
>>>> of writing a compiler for it.
>>>>
>>>> -- Paul.
>>>
>>> But aren't you selling a gnu-based C++ toolset? You must have
>>> some awareness.
>>
>> I understand the concept, of course, from Lisp. And lambdas are a
>> natural accompaniment to STL when you want to do things with a
>> container. Beyond that, I have no interest in their implementation.
>> They are not widely implemented at this time, which means that
>> using them in ostensibly portable software isn't possible.
>
> Hmm.... Well, let's see. Who causes things to become widely
> implemented? I think the answer is... compiler writers. Yup.
>
Outside of the embedded world, "widely implemented" means both gcc
and
MSVC++ support the feature (with Intel having a reasonable third place).
There are other non-embedded compilers, of course, such as LLVM, DM,
IBM, etc., but even together they are only a small fraction of the user
market.
Since gcc, MSVC++, and Intel all support lambdas, and have done for a
couple of years, lambdas /are/ widely implemented in the non-embedded world.
In the embedded world, of course, we are much more conservative. gcc
has supported lambdas since 4.5 (though you would want to avoid them in
their early incantations). I don't know anything about their support in
things like ARM's compilers.
> So I guess this rests on your shoulders, Paul. It
is you and folks
> like you that will either make this happen... or not.
>
> And since we both admit this is great stuff, works well, does good
> things... and it has NOW been incorporated into the standards... then
> either it happens in products like yours and others or gnu moves on
> to the future and leaves everyone else behind.
>
> http://gcc.gnu.org/projects/cxx0x.html
AFAIK, Crossworks is C only - no C++ - except for the ARM tools, which
use the gcc toolchain. So I think Paul has a little more work to do
before he can implement C++ lambdas in his msp430 toolchain! (He has
said he has no plans to implement C++ in his own compilers - he has his
sanity to consider.)
>
> Maybe that is the writing already on the wall that's been discussed
> here and everyone knows the elephant in the room and just doesn't
> talk much about it (until today.)
>
> I'm not happy about the portents mentioned today because I don't
like
> some one-tool gorilla taking over the field. I like choices. But
> perhaps the market won't support that and in the end gnu's tools
and
> the FSF vision has carved out big changes in one section of the
> software world.
>
There is not just one gorilla, but things are certainly changing. The
big driving force is that developers are moving towards bigger cpu cores
- with ARM being the big one, but not the only choice. "Small"
compiler
developers can't make toolchains that can compete with gcc or the
"big"
vendors (Green Hills, Keil, IAR, etc.) - it is simply infeasible for a
small company to produce a compiler with the features that customers
want (including modern C++ support), and that also generates good
quality code. It's too big, too complex, and has to be ready too fast.
The market where the small compiler developers could really shine - the
weird C-unfriendly 8-bit devices - is getting smaller all the time.
So the future for companies like Rowley is to do /exactly/ as the FSF
envisioned - take gcc, package it with high-quality libraries,
easy-to-use IDE and debugger, and top-class support. In other words, do
as Paul /has/ done with his ARM tools - as do most other ARM tool
vendors (Mentor Graphics / CodeSourcery, Red Hat, Code Red, etc.).
But I agree that it is important to keep competition and choice.
Fortunately, there still is - even in the ARM market, there are at least
four serious non-gcc ARM compilers (Keil/ARM, GHS, CodeWarrior and
llvm). LLVM in particular is a direct competitor to gcc - and its
existence has had a clear influence on improving gcc in the past few
generations.
>>> And besides, doesn't gnu support the
new lambda syntax and
>>> semantics now? Don't you spend late evenings reading through
gnu
>>> code that was built up with the hands of thousands of tinkerers
>>> almost like the fabled stone soup? ;)
>>
>> Sorry, no. I have my own interests to pursue and don't need to
be
>> tinkering in that particular area. :-)
>>
>> -- Paul.
>
> You mean you have a life?! Shame on you. What is the software
> priesthood going to do if more priests like you go out and get
> themselves real lives?
>
> Why, the church would as much as crumble into ashes. ;)
>
> Jon
Reply by Xiaofan Chen●February 8, 20132013-02-08
On Fri, Feb 8, 2013 at 3:50 PM, Richard Man wrote: > That's a pretty rosy picture: does anyone
know IAR finance situation? Just
> sayin'
Seems to be not bad. We will need to buy more licenses of IAR EWARM
and maybe their fiance result will be better next year. :-)
IAR Systems Group Year-end Report 2012
Net sales grew by 15% and operating profit up by 47%
The Board proposes a doubled dividend
--
Xiaofan
Reply by Richard Man●February 8, 20132013-02-08
That's a pretty rosy picture: does anyone know IAR finance situation?
Just
sayin'
> I think you mean your are okay to compete withe a
$0 GCC based
> toolchain (eg: AVR GCC, msp430-gcc, ARM gcc, etc) but you
> have problems competing with vendor supported non-gcc (or gcc
> with proprietary bits, like Microchips C30/XC16 and C32/XC32).
>
> I think for proprietary core, it makes sense for vendors to have
> a strong compiler offering from in-house, along with a strong
> 3rd party (eg: IAR) which is highly desirable but not that essential
> as long as the in-house offering can satisfy customer needs.
> This seems to be what MCU vendors like TI, Microchip and
> Freescale are doing (buying strong 3rd party toolchain vendors).
> Renesas also has strong in-house offerings and then IAR is
> the other major force.
>
> This makes smaller 3rd party players' life more difficult.
>
> The open multiple vendor 8051/ARM world are different since
> 3rd party tools are very strong: IAR, Keil. It is difficult for a
> single 8051/ARM vendor to buy a good compiler which is
> used for their own variation of 8051/ARM.
>
> I agree that ARM adoption rate is accelerating. At work, we
> kind of standardizing on ARM architecture for standard
> MCU/MPU and ASIC built-in MCU/MPU core, other than a
> few product facility which is too difficult to move away from
> existing architecture.
>
> At work, we usually do not use $0 tools since the cost
> of the toolchain is really quite small comparing to engineering
> cost. So we choose good ones, like Keil for 8051 and IAR for
> ARM.
>
> On the other hand, it seems to me that the lower end ARM
> Cortex M0/M3/M4 MCU cost gets lower and lower and I
> wonder how those MCU vendors (NXP, ST, TI, Freescale, etc)
> can earn decent money from selling those MCUs.
>
> --
> Xiaofan
On Fri, Feb 8, 2013 at 6:19 AM, Paul Curtis wrote: >>
>>> Customers can endure unending pain when the price point is $0.
>
> I still maintain that a price of $0 is hard to beat, and bean counters
> can easily impose that purchase on an engineering team, I guess.
I think you mean your are okay to compete withe a $0 GCC based
toolchain (eg: AVR GCC, msp430-gcc, ARM gcc, etc) but you
have problems competing with vendor supported non-gcc (or gcc
with proprietary bits, like Microchips C30/XC16 and C32/XC32).
I think for proprietary core, it makes sense for vendors to have
a strong compiler offering from in-house, along with a strong
3rd party (eg: IAR) which is highly desirable but not that essential
as long as the in-house offering can satisfy customer needs.
This seems to be what MCU vendors like TI, Microchip and
Freescale are doing (buying strong 3rd party toolchain vendors).
Renesas also has strong in-house offerings and then IAR is
the other major force.
This makes smaller 3rd party players' life more difficult.
The open multiple vendor 8051/ARM world are different since
3rd party tools are very strong: IAR, Keil. It is difficult for a
single 8051/ARM vendor to buy a good compiler which is
used for their own variation of 8051/ARM.
I agree that ARM adoption rate is accelerating. At work, we
kind of standardizing on ARM architecture for standard
MCU/MPU and ASIC built-in MCU/MPU core, other than a
few product facility which is too difficult to move away from
existing architecture.
At work, we usually do not use $0 tools since the cost
of the toolchain is really quite small comparing to engineering
cost. So we choose good ones, like Keil for 8051 and IAR for
ARM.
On the other hand, it seems to me that the lower end ARM
Cortex M0/M3/M4 MCU cost gets lower and lower and I
wonder how those MCU vendors (NXP, ST, TI, Freescale, etc)
can earn decent money from selling those MCUs.
--
Xiaofan
Reply by Jon Kirwan●February 7, 20132013-02-07
On Thu, 7 Feb 2013 23:11:10 +0000, Paul wrote:
>><snip>
>> Lambdas are beautiful.
>>
>> I HATE the C++ syntax for them, though. Damn the committee
>> people! Anyone could do better. And why in the heck does one
>> have to manually add text to "help" the compiler do
closures?
>
> Not having even looked at implementing C++ lambdas, I
> couldn't say why the capture list is required.
><snip>
That's a point. Without actually _implementing_ something,
it's hard to be sure what motivated them. So I take that
point.
But... C# and VB.NET both do the capture without any
programmer involvement. It seems to me that if the variables
are in scope which they must be if they are being used, and
this should apply to C++ as well as the others, then the
compiler has all the necessary information to know what needs
to be captured and how.
When I think about exceptions I'm not so sure anymore, but
then I realize that the C++ compiler does it fine when the
list is hand-coded. So that can't be the problem.
Which leaves me without a paddle, really. What could they
possibly have been thinking? If expressing a list explicitly
makes a difference somehow, how then does it? What could
possibly be the issue, Paul? Can you think of ANYTHING, even
hypothetically, that could explain how an explicit list would
solve something that the lack of one couldn't? If the
variable is in scope, it's in scope. If not, not. The list
changes none of that.
Oh, well.
It bugs me and it does so because I can't think of a good
excuse for what passed through committee.
>>> I'm not sure you really appreciate a
language until you
>>> write a compiler or interpreter for it. And I'm not sure I
>>> will ever appreciate the finer details of C++ because I have
>>> no intention of writing a compiler for it.
>>>
>>> -- Paul.
>>
>> But aren't you selling a gnu-based C++ toolset? You must have
>> some awareness.
>
> I understand the concept, of course, from Lisp. And lambdas
> are a natural accompaniment to STL when you want to do
> things with a container. Beyond that, I have no interest in
> their implementation. They are not widely implemented at
> this time, which means that using them in ostensibly
> portable software isn't possible.
Hmm.... Well, let's see. Who causes things to become widely
implemented? I think the answer is... compiler writers. Yup.
So I guess this rests on your shoulders, Paul. It is you and
folks like you that will either make this happen... or not.
And since we both admit this is great stuff, works well, does
good things... and it has NOW been incorporated into the
standards... then either it happens in products like yours
and others or gnu moves on to the future and leaves everyone
else behind.
Maybe that is the writing already on the wall that's been
discussed here and everyone knows the elephant in the room
and just doesn't talk much about it (until today.)
I'm not happy about the portents mentioned today because I
don't like some one-tool gorilla taking over the field. I
like choices. But perhaps the market won't support that and
in the end gnu's tools and the FSF vision has carved out big
changes in one section of the software world.
>> And besides, doesn't gnu support the
new
>> lambda syntax and semantics now? Don't you spend late
>> evenings reading through gnu code that was built up with the
>> hands of thousands of tinkerers almost like the fabled stone
>> soup? ;)
>
> Sorry, no. I have my own interests to pursue and don't need
> to be tinkering in that particular area. :-)
>
>-- Paul.
You mean you have a life?! Shame on you. What is the software
priesthood going to do if more priests like you go out and
get themselves real lives?
Why, the church would as much as crumble into ashes. ;)
Jon
Reply by Richard Man●February 7, 20132013-02-07
"Lock in" is probably a poor choice of words. I meant as long as
the
perception that they are satisfying their customer's current needs,
there
is no need for them to provide anything different or better.
I will give one example, we all know there are more and more embedded
projects being done but there's no new tools to help. Compiler tools are
primitive, the IDE can be better - for example - why are we still writing
header files et. al.? Yes, I know the language requires certain syntax and
semantics, but why are the tools not helping? Or even Jon's lambdas.
Lets
say it IS the greatest thing since sliced bread, but what's the chance
of
sliced bread being made by the Si vendors or Open Source? And there is no
ROI for 3rd party to spend money developing products that are obscured by
the "we want free tools" mantra.
On Thu, Feb 7, 2013 at 3:36 PM, Paul Curtis wrote: > **
>
> I'm not sure that Si vendors want to lock anybody in. What they want
is
> more customers to buy their ICs and, to that end, some have decided to
take
> tools back in house. Microchip:HI-TECH, Freescale:Metrowerks, TI:Tartan,
> ADI:EPC, and so on... They don't want to risk their business on a
single
> tools company.
>
> -- Paul
// richard m: richard @imagecraft.com
Reply by Paul Curtis●February 7, 20132013-02-07
On 7 Feb 2013, at 23:08, Richard Man wrote:
> The forebear of MSP430X was whispered about around
as early as 2002, I
> think. Of course, the 430X we have today is neither a fish nor fowl,
> solving problems that no one wants it to solve.
The MSP430X design that we have now is rather problematic in a number of areas.
The design was, as far as I remember, required because one of TI's big
customers for glucose meters was clean out of code space -- you know the thing,
need more functionality, a GUI, and all those good things to compete in the
market and the 16-bit MSP430 had nowhere to go. What TI ended up with was
something that wouldn't scare the horses and would run old 16-bit code, but
would also present a 20-bit world.
You can now get MSP430s with 512K of flash. And how do you develop on that with
a FET430UIF? We're lucky to get maybe 8K/second out of the FET430UIF on a
great day. Compare that to your typical ARM uC that programs flash at 100KB per
second or can download into RAM at 1 MB per second and is not encumbered by
16-bit-only registers. LPC1100s and LPC1300s are amazing devices.
What's more, with the formation of the low-energy benchmarks that EEMBC are
developing, with Horst chairing things, there might be a real answer to just how
an EFM32 compares to an MSP430 for the same task.
>
> Compiler business is at a crossroad, and folks clamoring for free GCC
not
> withstanding, the customers will suffer in the end. Just remember, the
> silicon vendors' goal is to "lock you in," and the Open
Source community
> does whatever strike certain engineers' fancy. Neither of which is
likely
> to solve the "Next Problems."
I'm not sure that Si vendors want to lock anybody in. What they want is
more customers to buy their ICs and, to that end, some have decided to take
tools back in house. Microchip:HI-TECH, Freescale:Metrowerks, TI:Tartan,
ADI:EPC, and so on... They don't want to risk their business on a single
tools company.
-- Paul
Reply by Paul Curtis●February 7, 20132013-02-07
>>
>> 1960s technology to the rescue! Now, how many times have I
>> said that my favourite language happens to come from the
>> Lisp branch of the Language Tree? I love T; I like Common
>> Lisp.
>
> I had known only _some_ of what was out there because of my
> limited exposure. But I knew it was powerful. I just didn't
> know how good it would be when faced with a real project and
> a compiler toolchain that supported the concepts well. (Okay,
> so my experience remains limited... but it has grown a little
> too.)
I'm sure some will think that lambdas are new. Of course, nothing is
really new. I would say that quite a lot of the computer science field that
deals with language design and implementation is "mined out" now.
Logic, functional, declarative, imperative, take your pick!
> Which says three things: (1) the design process
produced a
> correctly aligned design, and (2) traditional language
> limitations were creating a nightmare, and (3) lambdas are
> very powerful tools.
Lambdas are very nice. In Common Lisp, #' is natural and clean.
>
> Lambdas are beautiful.
>
> I HATE the C++ syntax for them, though. Damn the committee
> people! Anyone could do better. And why in the heck does one
> have to manually add text to "help" the compiler do closures?
>
Not having even looked at implementing C++ lambdas, I couldn't say why the
capture list is required. Clearly, in Lisp a capture list is not required and a
closure forms naturally (and there are a number of way of implementing such a
closure, even within the same Lisp system.) >> I'm not sure you really appreciate a
language until you
>> write a compiler or interpreter for it. And I'm not sure I
>> will ever appreciate the finer details of C++ because I have
>> no intention of writing a compiler for it.
>>
>> -- Paul.
>
> But aren't you selling a gnu-based C++ toolset? You must have
> some awareness.
I understand the concept, of course, from Lisp. And lambdas are a natural
accompaniment to STL when you want to do things with a container. Beyond that,
I have no interest in their implementation. They are not widely implemented at
this time, which means that using them in ostensibly portable software
isn't possible.
> And besides, doesn't gnu support the new
> lambda syntax and semantics now? Don't you spend late
> evenings reading through gnu code that was built up with the
> hands of thousands of tinkerers almost like the fabled stone
> soup? ;)
>
Sorry, no. I have my own interests to pursue and don't need to be
tinkering in that particular area. :-)
