Isn't scrypt the hash function itself?
No. scrypt is not a hash function as SHA-256 is a hash function. Depending on who speaks, scrypt is a [password-based | memory-hard | purposely slow] [[key] derivation] | [function | hash]. The main difference with a standard hash is that scrypt has parameters CostFactor, BlockSizeFactor, ParallelizationFactor controlling the difficulty of computing the function. Also there are two data inputs Passphrase and Salt rather than one in a standard hash, and a parameter DesiredKeyLen controlling the output size. And further parameters.
Internally, scrypt uses PBKDF2-with-a-low-number-of-rounds as a building block, with PBKDF2 using the HMAC construction, with HMAC using a (typically Merkle–Damgård) hash such as (typically) SHA-256.
Why would having hLen of 32 bytes make scrypt in any way associated with SHA-256?
The hLen parameter of scrypt is the output width (in bytes) of the standard hash used by HMAC, used by PBKDF2-with-a-low-number-of-rounds, used by scrypt. Only when hLen is 32 can SHA-256 be used as the standard hash.
With hLen set to 64, the hash can be changed to e.g. SHA-512, and that increases the security of HMAC, and of PBKDF2-with-a-low-number-of-rounds. Typically on 64-bit machines that increases the speed of these for large input (or/and output for PBKDF2), and of scrypt with a large DesiredKeyLen (or/and large input). That also increases the security of scrypt from some standpoint, but not (at least, not much) from the standpoint that typically motivates the use of scrypt, which is key stretching (that is giving some level of protection against search of a password/passphrase by brute force: password cracking).
Note: we typically use
- Some standard hash (SHA-256, SHA-512, SHA-3, Blake2) to make a small, fixed-size representative of some message, in a public manner.
- a Mask Generation Function such as MGF1 when we need a hash with arbitrarilly wide output (and perhaps add a parameter in addition to the message).
- HMAC or SHA-3 for a keyed hash/MAC. The main functional difference with a hash is that there is a secret key.
- HKDF or PBKDF2-with-a-low-number-of-rounds for a fast key derivation function, when we need to add a parameter in addition to the message (e.g. to turn a Diffie–Hellman shared secret into multiple session keys), and/or perhaps extend the width of the result. This sort of combines the features of the above two extensions of standard hashes.
- scrypt or Argon2 as a purposely-slow key derivation function for key stretching, e.g. for construction of a password hash/token for access control. At equal computing time, scrypt and Argon2 are vastly superior to PBKDF2 from the standpoint of key stretching. The only two sound reasons I can discern to use PBKDF2 for that purpose are compatibility with legacy software, and purposely weakening a new system against password search.
