Do all programming languages have a clear concept of NIL, null, or undefined?

I am writing a key value store API (like ODBC, just the interface, not the underlying store) in many different languages and while I do not want to transliterate the API between languages, I do not want for example to store a value from Java as a "null" and then read it in another language which does not support a concept of null. I'm not sure if I am explaining this so well, but its my first try :)

See :

Is开发者_运维知识库 this API too simple?

for the discussion about the key-value store API

This is a type system question, so anyone who answers "0" misses the point.

What you're talking about is a sum type (check "Types and Programming Languages").

That is, a type that has n + 1 inhabitants. That is, the type whose elemens are:

• all the values of the type you care about

OR

• an extra value, Nothing.

This is easily described as an algebraic data type, e.g. in Haskell

data Maybe a = Just a | Nothing

Bizarrely, relatively few languages support sum types, so they encode them as products (a pair of the tag Just or Nothing, and the value itself) or by overloading one of the inhabitants of the type (e.g. -1 or 0 becomes Nothing).

This type is usually known as Maybe or Optional.

No. All prodedural languages without pointers I can think of have no such concept. For example, classical Basic (like the one used in 80s' home computers) has no such concept. I don't think that Cobol has it, either.

If not, it's up to the language to provide an alternative convention, like an isAgeNull function. It shouldn't concern you.
All major databased have nulls (and even types of null), and they play nice with different languages.
You should also remember that there's a difference between an object null pointer and a database null value.

No, not all languages support the "null/nil/Nothing" concept; also in some case such support is limited to a simple convention whereby an unknown/undefined value is represented by a particular value.

I suggest you simply handle "NULL / Nothing / nil" as if this was merely a particular "type".
In other words, just like you may find it convenient to provide support for say floating point arithmetic values (even though not all languages support these), if you find NULL useful, you can include it in your data model / API, and simply put the responsibility upon the particular implementations of the API to convert NULL to whatever appropriate value (say zero or an empty string or whatever) would the underlying language not support the NULL concept (or alternatively to throw an exception if it is undesirable to deal with null values in a particular language).

I think I understand. While I would say that knocks on wood most languages off the top of my head that would be used with an ODBC interface would have the concept of a NULL. The further you get from C-like languages though, the more your mileage may vary.