What is the difference between a design pattern and a language idiom?

From common usage, a "design pattern" seems to be a way of organizing part of a program that cannot be directly expressed once in the language and then pushed into a library, but instead needs to be mostly rewritten whenever used. (Polyglot programmers usually recognize this as a kind of language weakness. (See: http://weblog.raganwald.com/2006/01/finding-signal-to-noise-...) ) If one could just say,

  require "visitor.lib";

and move on, then would people make such a big deal about them?

Along similar lines, FP has currying, pattern matching / destructuring-bind, higher-order functions, and monads, among other things. The only one of these I've heard referred to as a design pattern is the monad. Most FP languages just let you do all of the others, but monads require rewriting some (relatively small) infrastructure code. In Haskell, the compiler (via typeclasses) recognizes that you are writing an instance of a known general concept, though, so you don't need to duplicate most of the infrastructure.

If this isn't the case, then why aren't general OO design concepts such as e.g. delegation or inheritance considered design patterns?