If processing is a language I would expect to find a grammar
and a semantic description of the language components. But
all I can find in processing ( and wiring and arduino ) is set
of libraries or class files and headers for an existing language
( java or c ). Am I missing something?  Is it really a unique
language? Or just some IDE / libraries for existing compilers?

thanks.

I would say that Processing is a kind of Java slang :-p

I still think dialect is about right (maybe slang works too), though I think it's hilarious that if we haven't documented it properly (or you haven't bothered looking through the source for the grammar) that you don't feel it's a language. It's a bit like saying a spoken language doesn't exist unless there's a dictionary that you're able to purchase.

Since this comes up every few months (in spite of it being in the FAQ), I'll add a bit more:

In Processing, we're talking about a dialect that we've added on top of Java to make things a little easier for a particular work domain (roughly, making visual things). There's also a programming environment that supports doing this kind of work by simplifying significantly from traditional IDEs. There's also a core API set (and a handful of core libraries) that we've built to support this type of work. If we did these in isolation, it's not that useful:

- The language changes are pretty minimal. The big difference is probably how they integrate with the IDE that's built around the idea of quickly sitting down and writing code (what we call sketching).

- The API set is a Java API. It can be used with traditional Java IDEs (Eclipse, Netbeans, whatever) and a Processing component can be embedded into other applications. But without the rest of it (the syntax and IDE), Processing (API or otherwise) would not be as widely used as it is today.

- The IDE is designed to make Java-style programming less wretched. check out the Integration board to see just how un-fun it is to figure out how classpaths, library paths, and embedding with AWT.

If pressed, perhaps the language itself is probably the easiest to let go of--witness the Python, Ruby and now JavaScript versions of the API, or the C++ version that I use for personal work (when doing increasingly rare C++ projects). And lots of people build Processing projects without the preprocessor and PDE.

But for as much trouble as the preprocessor and language component of Processing is (or as irrelevant it might seem to programmers who already code in Java), we're still not willing to give that up--damned if we're gonna make students learn about how to write a method declaration and  "public class Blah extends PApplet" before they can get something to show up on the screen.

I think the question is a bit like the general obsession of people trying to define Apple as a hardware or software company. They don't do either--they do both. They're one of the few to figure out that the distinction actually gets in the way of delivering good products.

Now, whether we're delivering a good product is certainly questionable--the analogy with Apple may end there.

I fully agree with memo.
That's why I, and otherwise good Java programmers, like Processing, beyond the facility to bundle useful libraries: it gives to Java the feeling to have an interpreted language, with the fast development/test cycle that lets the creative juice to flow.
Less plumbing, more fun...