Lisaac*. Tout y est objet, comme en ruby, même le booléen.
En lisaac, le for est un message de INTEGER
1.to 10 do { i.print;};
Justement, je trouve pas ça si génial que ça moi. Avec ta méthode, du point de vue du sens, le for est un truc qui concerne la première borne : c'est sa méthode qu'on utilise, et à laquelle on donne la deuxième borne et le bloc en arguments (c'est pas forcément la bonne terminologie, mais c'est pas grave).
Moi, je trouve ça laid. Je vois pas pourquoi dans un for, il y aurait une asymétrie entre la première et la deuxième borne.
Dans l'idée, je trouve beaucoup plus joli d'exprimer le for comme une fonction qui dépend des bornes et du bloc :
let for debut fin bloc = ...
En Ocaml/Haskell par exemple, on peut faire ça pour pas cher. Si on ne fait pas d'effet de bords, le "for" n'a à priori pas grand sens, mais imaginons que le for fonctionnel renvoie la liste des valeurs générées par le bloc à chaque itération :
let rec for low up bloc =
if low = up then []
else bloc low :: for (low + 1) up bloc
En Haskell, si on crée un alias de for nommé "to", on peut même faire des contorsions syntaxique amusantes, par exemple
1 `to` 10 $ bloc
(On peut faire pareil en OCaml si on donne un nom d'opérateur à for : 1 >> 10 $ bloc, par exemple)
Je pense que cette asymétrie forcée est un des grands problèmes de l'objet.
[^] # Re: Ruby
Posté par gasche . En réponse au journal A mort les boucles. Évalué à 1.
Justement, je trouve pas ça si génial que ça moi. Avec ta méthode, du point de vue du sens, le for est un truc qui concerne la première borne : c'est sa méthode qu'on utilise, et à laquelle on donne la deuxième borne et le bloc en arguments (c'est pas forcément la bonne terminologie, mais c'est pas grave).
Moi, je trouve ça laid. Je vois pas pourquoi dans un for, il y aurait une asymétrie entre la première et la deuxième borne.
Dans l'idée, je trouve beaucoup plus joli d'exprimer le for comme une fonction qui dépend des bornes et du bloc :
let for debut fin bloc = ...
En Ocaml/Haskell par exemple, on peut faire ça pour pas cher. Si on ne fait pas d'effet de bords, le "for" n'a à priori pas grand sens, mais imaginons que le for fonctionnel renvoie la liste des valeurs générées par le bloc à chaque itération :
let rec for low up bloc =
if low = up then []
else bloc low :: for (low + 1) up bloc
En Haskell, si on crée un alias de for nommé "to", on peut même faire des contorsions syntaxique amusantes, par exemple
1 `to` 10 $ bloc
(On peut faire pareil en OCaml si on donne un nom d'opérateur à for : 1 >> 10 $ bloc, par exemple)
Je pense que cette asymétrie forcée est un des grands problèmes de l'objet.