Le B ça suxx - Page 3

Y'a la critique de la lib standard, soit, mais elle revient très souvent donc c'était pas forcément la peine de le répéter , et moi je préfère une lib standard petite mais principalement fonctionnelle à la lib .Net.

Ensuite, la surcharge, je suis de ceux qui sont contre dans le cas général, ça crée des confusions, par contre pour les opérateurs standard, là si tu y tiens, ça se fait en 2 lignes de p4.

Ce qui nous mène au point primordial suivant : pas de f#p4.

Et puis, moi quand j'ai besoin de faire un programme certes pas le plus rapide mais avec de très bonnes performances quand même, j'hésite rarement à le faire en ocamlopt plutôt qu'en C. F# pose un problème de perfs quand on utilise beaucoup le style fonctionnel (et ça n'est pas la faute du langage, juste la vm .Net qui n'est pas du tout faite pour).

Tu parles de menhir, il faut voir qu'il n'est pas encore totalement au point, qu'il n'a pas les mêmes perfs qu'ocamlyacc donc il n'est pas ntégrable tout de suite, et puis il utilise un système de types trop expressif qui l'oblige à générer du caml non typable (donc avec des casts).

Quant à l'argument "c'est moins bien sous windows"... ben j'ai eu à faire du caml sous windows, j'ai simplement mis un emacs pour avoir le mode tuareg, et c'est fin

Et puis ocaml, c'est gratuit, c'est libre, emacs et tuareg, c'est gratuit, c'est libre, ...

il est très facile de critiquer ocaml dans pas mal de domaines, mais tu es passé à côté :

LLB (./61) :
F# n'a rien à voir avec C#, par exemple. Il est bien plus ouvert.

LLB (./61) :
Comme... ?

LLB (./61) :
affichage générique des variables [...] introspection

LLB (./61) :
En utilisant des bibliothèques extérieures à la distribution standard ? En faisant un projet avec plusieurs fichiers ? Moi aussi, j'ai souvent utilisé Emacs. C'est un excellent éditeur, mais c'est loin d'être parfait en tant qu'environnement de développement.

LLB (./61) :
mais en utiliser un peu améliore grandement le langage.

BookeldOr (./64) :
http://cs.hubfs.net/forums/thread/3129.aspx

LLB (./61) :
Compare le C et le C++ : l'apport de la surcharge me semble flagrant (même s'ils en ont abusé en C++ ). Surcharger les opérateurs de base , *, - apporte beaucoup en général.

Il ne faut bien sûr pas abuser de la surcharge (au risque d'affaiblir le typage), mais en utiliser un peu améliore grandement le langage. Je trouve ça dramatique de devoir nommer ses fonctions *_int, *_float, *_string, etc.

Ce genre de notation est vraiment néfaste.

  (2+3)%Z   (* les nombres et les opérations sont ceux de Z *)
  (2+3)%nat   (* idem pour nat *)

  (2+3)%int
  (2+3)%float
  (2+3)%Byte.t

Hippopotame (./68) :
Il me semblait bien que tu étais un homme de goût

  type t =
    | Var of int
    | Val of Value.t
    | Bin of Interval.binop * t * t
    | O_acc of t * tfield
    | A_acc of t * t
    | S_acc of klass_name * tfield
    | Array_init of Context.point * Value.t array
  type pat =
    | PAny                                         | PTAny of (t -> bool)
    | PVar of int                                  | PTVar of (int -> bool)
    | PVal of Value.t                              | PTVal of (Value.t -> bool)
    | PBin of Interval.binop * pat * pat           | PTBin of (Interval.binop -> bool) * pat * pat
    | PO_acc of pat * tfield                       | PTO_acc of pat * (tfield -> bool)
    | PA_acc of pat * pat
    | PS_acc of klass_name * tfield                | PTS_acc of (klass_name -> tfield -> bool)
    | PArray_init of Context.point * Value.t array | PTArray_init of (Context.point -> Value.t array -> bool)

  let rec matching pat e =
    match pat,e with
      | PAny,               _                -> true
      | PTAny f,            e                -> f e
      | PVar a,             Var b            -> a = b
      | PTVar f,            Var b            -> f b
      | PVal a,             Val b            -> a = b
      | PTVal f,            Val b            -> f b
      | PBin (op,p1,p2),    Bin (oe,e1,e2)   -> op = oe && matching p1 e1 && matching p2 e2
      | PTBin (f,p1,p2),    Bin (oe,e1,e2)   -> f oe && matching p1 e1 && matching p2 e2
      | PO_acc (p,f),       O_acc (e,fe)     -> f = fe && matching p e
      | PTO_acc (p,f),      O_acc (e,fe)     -> f fe && matching p e
      | PA_acc (pa,pi),     A_acc (ea,ei)    -> matching pa ea && matching pi ei
      | PS_acc (k,f),       S_acc (ke,fe)    -> k = ke && f = fe
      | PTS_acc f,          S_acc (ke,fe)    -> f ke fe
      | PArray_init (p,pa), Array_init (q,a) -> p = q && pa = a
      | PTArray_init f,     Array_init (q,a) -> f q a
      | _ -> false
	  
  let rec subst pat trans e =
    if matching pat e then
      trans e
    else
      match e with
	| Bin (op,e1,e2) -> Bin (op, subst pat trans e1, subst pat trans e1)
	| O_acc (e,f) -> O_acc (subst pat trans e,f)
	| A_acc (e1,e2) -> A_acc (subst pat trans e1, subst pat trans e2)
	| e -> e

Pollux (./70) :
je ne vois pas en quoi l'allocation serait gênante ce qui est gênant, c'est juste les effets de bord...

Pollux (./70) :
par contre ton truc maison est bcp moins général qu'un filtrage normal (et je me demande comment tu comptes t'en servir en pratique ?
subst (PBin Plus (PVal 42) (PTVal (fun x->x0))) (function Bin _ (Val x) -> Val (42 x)) ? c'est un peu crade, tu dois dupliquer le code, tu vas avoir un warning à cause du pattern-matching pas surjectif, etc...)

Pollux (./70) :
(fun x->x<>0)

BookeldOr (./71) :

Pollux (./70) :
je ne vois pas en quoi l'allocation serait gênante ce qui est gênant, c'est juste les effets de bord...

Dans un cas comme dans l'autre ça peut être génant ou non (question perf dans un cas et correction dans l'autre), mais il faut que ça soit explicite ce qui n'est pas possible avec le typage ML (mais je n'ai pas regardé en détail, c'était une remarque à priori, ils ont peut être étendu le typage pour ça).Si tu utilises un motif actif défini par quelqu'un d'autre, il faudrait le savoir.

Pollux (./70) :
par contre ton truc maison est bcp moins général qu'un filtrage normal (et je me demande comment tu comptes t'en servir en pratique ?
subst (PBin Plus (PVal 42) (PTVal (fun x->x0))) (function Bin _ (Val x) -> Val (42 x)) ? c'est un peu crade, tu dois dupliquer le code, tu vas avoir un warning à cause du pattern-matching pas surjectif, etc...)

Pour la généraiité, oui c'était pas le but en l'occurence, c'était juste pour faire des substitutions en fonction d'un critère plus compliqué que l'égalité structurelle sans faire des fonctions ad hoc partout avec du code presque identique.Pour le coup du filtrage dans la fonction de transformation, J'ai une variante avec juste une valeur quand je ne souhaite pas utiliser la valeur à remplacer.

Pollux (./70) :
(fun x->x<>0)

((<>) 0) , tu aimes bien te compliquer la vie ...

Pollux (./72) :
Ouais enfin donc si t'es obligé de faire des hacks à moitié satisfaisants pour éviter les limitations du pattern-matching c'est plutôt un argument en faveur des active patterns

Pollux (./72) :
ah non ça c'est équivalent à (fun x->0<>x)

(ceci dit, ça m'est déjà arrivé de bugger un prog en oubliant d'inverser le sens de l'opérateur )

Pollux (./72) :
Question perf bof, je vois pas où est le pb qu'un déconstructeur

M-backspace troller

BookeldOr (./25) :
Dans F#, le pattern matching ne me convainc pas du tout, et puis de toutes façons, il faut une lib objet et fonctionnelle, pas juste l'accès au framework .Net...

Sinon, il y a un port de OCaml pour .Net qui fonctionne assez bien (mais les sources ne sont pas encore ouvertes, ça ne devrait pas tarder), c'est assez rigolo d'ailleurs comme fonctionnement, ça reconstruit les types du lambda code (en fait les types sont virés dès le passage du typeur dans le processus de compilation d'OCaml).

Kochise

BookeldOr (./73) :
J'ai pas le temps de préciser M-backspace troller mais l'idée c'est que ça peut faire des goulots d'étranglement difficiles à cerner.

LLB (./61) :
Compare le C et le C++ : l'apport de la surcharge me semble flagrant (même s'ils en ont abusé en C++). Surcharger les opérateurs de base +, *, - apporte beaucoup en général.

nEUrOO (./78) :
Si j'ecris:
a + b en C

Pollux (./12) :

naPO (./1) :
La syntaxe est pourrie et on nous force à écrire les prédicats avant d'apprendre cette foutue syntaxe...
Puis après faut tout prouver...

Meme le CAML n'est pas aussi chiant.

Bref, le B, çaydlamerd.

Bah au moins c'est utilisable/utilisé pour faire des vrais programmes, contrairement à ocaml

Manoloben (./82) :

Bah au moins c'est utilisable/utilisé pour faire des vrais programmes, contrairement à ocaml

Ca marche très bien,

BookeldOr (./83) :

Manoloben (./82) :

Bah au moins c'est utilisable/utilisé pour faire des vrais programmes, contrairement à ocaml

Ca marche très bien,

C'est quoi le rapport entre le fait que ça marche bien et celui que ça soit utilisé ?

Manoloben (./84) :
Désolé mais Ocaml c'est utilisable pour faire des vrais programme, et ca marche très bien.