From what I understand, non-strict semantics are (very informally) about choosing an order of evaluation that, where possible, avoids non-termination or error. Laziness is about evaluating only what's needed.
In any case, I think all of the mainstream Haskell compilers and interpreters implement the non-strict semantics by means of lazy evaluation, so unless you're working on a radical new Haskell implementation, you probably don't need to worry about the difference.

fac 0 = 1
fac n = n*fac(n-1)

делает такой:

fac !0 = 1
fac !n = let t = fac $! (n-1)
         in t `seq` n*t

let fib = 1:1: (zip_with (+) fib (head fib)) - lazy variant, infinite list of fib numbers

let fib n = 
  if n = 0 then [1]
  else
    let _fib_acc n l = 
      if n = 0 then l
      else _fib_acc (n-1) (((head l) + (head (tail l))) :: l) in
    _fib_acc (n-1) [1; 1];;

IEnumerable<TR> Map<T, TR>(IEnumerable<T> seq, Func<T, TR> fun)
{
    foreach(T elem in seq) yield return fun(elem);
}

map f [] = []
map f (x:xs) = f x : map f xs

K>IEnumerable<TR> Map<T, TR>(IEnumerable<T> seq, Func<T, TR> fun)
K>{
K>    foreach(T elem in seq) yield return fun(elem);
K>}
K>

IEnumerable<TR> Iterate<T, TR>(T start, Func<T> fun)
{
    while(true) {
      T next = fun(start);
        start = next;
        yield return next;
    }
}

public class LazyList<T> : IEnumerable<T>
{
    public LazyList(IEnumerable<T> seq)
    {
        _seq = seq;
    }

    IEnumerable<T> _seq;
    List<T> _buff = new List<T>();
    bool _calculated = false;

    private IEnumerable<T> Seq()
    {
        foreach (T elem in _seq)
        {
            _buff.Add(elem);
            yield return elem;

            // для демонстрации
            Console.WriteLine("side effect");
        }
        _calculated = true;
    }

    private IEnumerable<T> Select()
    {
        if (!_calculated)
            return Seq();
        else
            return _buff;
    }

    public IEnumerator<T> GetEnumerator()
    {
        return Select().GetEnumerator();
    }

    System.Collections.IEnumerator System.Collections.IEnumerable.GetEnumerator()
    {
        return Select().GetEnumerator();
    }
}

int[] arr = new int[3] { 1, 2, 3 };

LazyList<int> list = new LazyList<int>(arr);

foreach (int elem in list)
{
    Console.WriteLine(elem);
}

foreach (int elem in list)
{
    Console.WriteLine(elem);
}

1
side effect
2
side effect
3
side effect
1
2
3

public static IEnumerable<double> RandomValues()
{
   Random rnd = new Random();
   while (true) yield return rnd.NextDouble();
}

L>IEnumerable<TR> Iterate<T, TR>(T start, Func<T> fun)
L>{
L>    while(true) {
L>      T next = fun(start);
L>        start = next;
L>        yield return next;
L>    }
L>}
L>

IEnumerable<T> Iterate<T>(T start, Func<T, T> fun)
{
    while (true)
    {
        T next = fun(start);
        start = next;
        yield return next;
    }
}

int x = 0;
for(int i=0; i!=10; ++i, ++x) {} // x = 0..9
for(int i=0; i!=10; ++i, ++x) {} // x = 10..19

int y = x; // клонируем
for(int i=0; i!=10; ++i, ++x) {} // x = 20..29
for(int i=0; i!=10; ++i, ++y) {} // y = 20..29

IEnumerable generator() { .... yield return xxx; ..... }
.....
IEnumerable g = generator();
foreach(i in g) { ..... break; ..... }
IEnumerable h = g.Clone(); // <-- вот это? ну или что-то в таком роде?
foreach(i in g) { ..... break; ..... }
foreach(i in h) { ..... break; ..... }

/// Convert a sequence of one type to sequence of another type.
/// Convertion execute in lazy manner.
public MapLazy[From, To] (
    this source : SCG.IEnumerable [From],
    convert : From -> To
)
    : SCG.IEnumerable [To]
{
    foreach(elem in source)
        yield convert(elem)
}

public ExcludeLazy [T](
  [NotNull] this source  : SCG.IEnumerable [T],
  [NotNull]      exclude : SCG.IEnumerable [T]
)
  : SCG.IEnumerable [T]
{
  def ht = Hashtable();
  foreach (elem in exclude)
    ht[elem] = 0 : byte;

  foreach (elem when !ht.Contains (elem) in source)
    yield elem;
}

def completeOverrides()
{
  def decl = this.Project.GetActiveDecl(fileIndex, line, col);

  match (decl)
  {
    | Type(builder)      => // Retrive overrides.
      match (builder.SuperClass())
      {
        | Some(typeInfo) =>
          def virtMod = NemerleAttributes.VirtualityModifiers & ~NemerleAttributes.New;
          def allOverrides = typeInfo.GetMembers(SR.BindingFlags.Instance 
            | SR.BindingFlags.NonPublic
            | SR.BindingFlags.Public).FilterLazy(m => m.Attributes %&& virtMod);
          def implemented = builder.GetMembers(SR.BindingFlags.Instance 
            | SR.BindingFlags.NonPublic
            | SR.BindingFlags.Public
            | SR.BindingFlags.DeclaredOnly).FilterLazy(m => 
              m.Attributes %&& NemerleAttributes.Override);
          def canOverride = allOverrides.ExcludeLazy(implemented);
          def res = canOverride.MapToArray(e => CompletionElem(
            (if (e is IProperty) GlyphType.Property else GlyphType.Method) :> int,
            e.Name, "info not implemented", array[Elem.Member(e)], 
            CompletionElemFlags.ForOverride));
          res;

        | _ => TopKeywords
      }
    | _ => TopKeywords
  }
}

Какая еще писанина? В C#, например, всё делается очень просто и ненапряжно.

do line <- getLine
   doSomething line

ones :: [Integer]
ones = 1 : ones -- бесконечный список единиц

f :: Integer -> Integer -- реализация не важна

dummy :: Integer -> Integer -> [Integer] -> Integer 
dummy  a b [] = a - b -- для пустого списка вычитаем
dummy  a b _  = a + b -- в остальных случаях складываем

"нулевая писанина" в Хаскеле в реальной жизни вылевается в тормоза и проблемы на ровном месте

L>do line <- getLine
L>   doSomething line
L>

readAndCount filePath = bracket (openFile filePath ReadMode) hClose
    (\handle -> do
        chars <- hGetContents handle
        putStrLn $ show $ length chars
    )

Lazy<int> lint = Lazy<int>(delegate(){ return foo.CalcInt(); }); //тут ничего не считается.

lint = lint.Apply(delegate(int i){ return i + 2; }); // и здесь ничего еще не считается.

lint = lint.Apply(delegate(int i){ return i * 7; }); 
// все еще ничего. Где-то внутри lint продолжает расти очередь делегатов, 
// а может быть работает emit - это все детали реализации.
// еще Lazy<int> может быть футурой и вычисляться в другом потоке, например.

int i = lint.Value; // вот тут оно все и посчиталось.

IEnumerable<Lazy<RT>> Map<T, RT>(IEnumerable<Lazy<T>> seq, Func<T, Lazy<RT>> fun)
{
    foreach(Lazy<T> elem in seq) yield return elem.Bind(fun);
}

doLoooongCalculation `ifFails` doOtherLooooongCalculation

-- ну ка, поглядим сколько монет в сундуках мертвеца, лежащих в трюмах с награбленным.
sum $ map coins $ filter (\chest -> owner chest == deadMan) $ concatMap chests treasures

[]     ++ ys = ys
(x:xs) ++ ys = x : (xs ++ ys)

map      :: dirty(a -> b) -> [a] -> [b ]
map_pure :: (a -> b) -> [a] -> [b ]

LCR>>Согласен, и это вычёркивает Хаскелл из целого ряда задач. Но там уже такая толкотня, что прямо скажем, невелика потеря

G>Угу, а что остается? Назовите полезные, не академические задачи, где Хаскель рвет всех. А то на пустом множестве, сами понимаете, доказать можно все что угодно — на нем верно все.

G>Семантическая простота . Вы в состоянии рассчитать асимптотическую сложность и расход памяти для ленивой программы большого объема, особенно если над кодом поработал strictness analyzer?

The physical causality works as follows. The brain issues the orders which propagate sequentially through the nerves, make the articulations and the limbs move, and finally the end effector — the hand — grasps the kettle and put in on the fire. Anybody protests?

G>А для Хаскеля у нас автоматических распараллеливателей дофига, да? Кстати, фортрановские и сишные программы уже давно параллелят автоматически — это например интеловские компиляторы умеют.

LCR>Получается, что dirty нужно расширять так, чтобы он стал полноправным типом, и систему типов так, чтобы обеспечить комфорт с манимуляцией такими типами. Ты уже понял, куда мы пришли?

G>>Угу, а что остается? Назовите полезные, не академические задачи, где Хаскель рвет всех. А то на пустом множестве, сами понимаете, доказать можно все что угодно — на нем верно все.

LCR> Думаю что с помощью чистого нестрогого языка будет возможно строить сверхбольшие системы — это может быть killer-app. Может быть это будет Хаскелл, может Clean, а может быть и Хаскелл-2

G>>А для Хаскеля у нас автоматических распараллеливателей дофига, да? Кстати, фортрановские и сишные программы уже давно параллелят автоматически — это например интеловские компиляторы умеют.

С их сайта ссылка на более подробную статью о сути дела здесь. Я так понял (пробежавшись краем глаза), что скелетоны — это паттерны для параллельного программирования, не особо oCamlоспецифичные. Так что, вроде, можно и в N. Было бы желание

G>Можно, кстати, шибко далеко не идти, и сразу заглянуть, как это сделано в... С++. Делаем dirty частью сигнатуры (как const), разрешаем описывать generic-функции без указания модификатора.

-- Функция map - она чистая или грязная?
map :: (a -> b) -> [ a ] -> [ b ]

Notice that I have chosen a particularly simple definition of “dirty.” At first sight it might appear that it would be better to recursively define a module as being dirty if any function in the module calls a “dangerous” BIF or a dirty function in another module. Unfortunately with such a definition virtually every module in the system would be classified as dirty.

A function will be considered dirty if a single call is made to unclean BIF.

The bottom line is that laziness and side effects are, from a practical point of view, incompatible.
If you want to use a lazy language, it pretty much has to be a purely functional language; if you
want to use side effects, you had better use a strict language.