http://permalink.gmane.org/gmane.comp.lang.caml.inria hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.comp.lang.caml.inria/57552 <pre>[...] Where do the non-constant values come from? I don't see there non-constant values. Even a referemce, where the value is mutable, is represented as a name-binding to the reference (container). But in the chapter on page 136 it's about recursive values. That does not mean the values are mutable. So I wonder, why the term variables might be ok there. Why is on the one hand emphasized, that there are name-value bindings, on the other hands variables are the right term? Or am I too picky? Or has my mind be infected at the time when I looked at Haskell and it's pureness? Ciao, Oliver </pre> oliver 2013-05-25T00:40:45 http://permalink.gmane.org/gmane.comp.lang.caml.inria/57551 <pre> On May 24, 2013, at 7:30 PM, oliver &lt;oliver&lt; at &gt;first.in-berlin.de&gt; wrote: If you think of functions as equations, non-constant values are variables. Imperative languages don't get to claim the term just because they misused it for a long time ;) Think of the word "hacker" - it was hijacked and misused for a while, but I feel like it has mostly been recovered these days. Perhaps we can recover the accepted meaning of variables if we consistently contrast them with reference cells. </pre> Siraaj Khandkar 2013-05-24T23:53:33 http://permalink.gmane.org/gmane.comp.lang.caml.inria/57550 <pre>[...] Do you think so? I have thought about making the sentence better, but did not found a better sentence in short time. But name-value-binding is the term that is used in functional languages. I wonder why the term "variable" pops up there. And even I understood the sentence, I'm not sure if this might create confusion to some readers, because the term "variable" is normally not used for functional languages. People new to FP will be said, there are no "variables", and then they maybe will be irritated, if they find that term in a reference-manual. Do you see what I mean? Ciao, Oliver </pre> oliver 2013-05-24T23:30:15 http://permalink.gmane.org/gmane.comp.lang.caml.inria/57549 <pre>[...] [...] Is this really especially for OCaml? or also Haskell and the other languages? I ask, because when looking at the comparison table from page 55, then there are other languages that also have good results. Looks like the type system is the main distinction between the well and the bad languages. And there are OCaml, F#, Scala, Haskell, which have good rates in the table. It would have been nice, if non-functional languages would have been rated also. I think they all would be on the bad side. This would then be a good argument pro Functional languages. But all the languages that were in the table were functional languages. The typical average decider in a company, who does have influence to decide for the one or the other language would not know all the other languages. So, this comparison might be good for certain "insiders", but the mainstream is using C, C++, Java, Perl, Python, Ruby and so on. If these languages would be checked also (and I assuem they would be a bad choice), then this p</pre> oliver 2013-05-24T23:13:45 http://permalink.gmane.org/gmane.comp.lang.caml.inria/57548 <pre> Legally in France, you can also ask financial details about this kind of crap. I did it, we will see the result. I can translate the most brilliant pages in english when I have some time, but I doubt you'll appreciate it as much as we, french taxpayers, far-from-tenured young french researchers ;-) Cheers… Pierre </pre> Pierre-Etienne Meunier 2013-05-24T17:44:58 http://permalink.gmane.org/gmane.comp.lang.caml.inria/57547 <pre> Yes, I just saw that. They could have at least write something on it. A lot has changed since 2011... Esther Baruk </pre> Esther Baruk 2013-05-24T15:36:42 http://permalink.gmane.org/gmane.comp.lang.caml.inria/57546 <pre>Hello, 2013/5/24 Esther Baruk &lt;esther.baruk&lt; at &gt;gmail.com&gt;: I just glimpsed through the documents but some of them seem quite old (2011) and they are referencing OCaml 3.12.0. Regarding the recommendations, they are always debatable. Hopefully they have a rationale that permit to understand why the document author proposed such a recommendation. Nonetheless I find interesting and refreshing[1] the fact that ANSSI is at least seriously considering OCaml for writing security related programs. Regards, david [1] Pun intended regarding the current French weather. </pre> David MENTRE 2013-05-24T15:18:53 http://permalink.gmane.org/gmane.comp.lang.caml.inria/57545 <pre>I agree, and indeed the project I'm currently mostly involved with closely match your description. I was not blaming specifications per se but the idea that programming goal is to implement a pre-existing, fixed, unquestionable set of specifications that stand like revealed truth. How these specifications are formulated, how easy it is to fix and maintain them, is as important as the implementation language IMO. </pre> rixed< at >happyleptic.org 2013-05-24T15:15:38 http://permalink.gmane.org/gmane.comp.lang.caml.inria/57544 <pre>Hi, On Fri, May 24, 2013 at 04:59:41PM +0200, Esther Baruk wrote: [...] Oh, what a short part ;-) Ciao, Oliver </pre> oliver 2013-05-24T15:05:10 http://permalink.gmane.org/gmane.comp.lang.caml.inria/57543 <pre>Le 24/05/2013 16:47, oliver a écrit : Same as OCaml except difficult :-) Here is a rough translation of the subitems of the table on page 55: ** Teaching material ** Integration in IDEs ** Simple syntax ** Easy to write in ** Type inference ** Complex data structures ** Modularity ** Polymorphism ** Strong static typing ** Pattern matching ** Rich pure functional core Efficiency * native code production Interoperability * with C * virtual machines Security </pre> Johan Grande 2013-05-24T15:02:16 http://permalink.gmane.org/gmane.comp.lang.caml.inria/57542 <pre>Hello, I'll just translate for you one of the recommandations of the document "Modèles d'exécution d'OCaml" on page 15 : "Recommandation R-2 : prefer camlp4 as a preprocessor" I didn't read the whole document but reading this simple sentence makes me conclude that this LaFoSec project was done without taking into account all the community "movement" that is going on right now. From my point of view, you cannot analyse a language, or the tools that come with it, without taking informations from experts and from the community around this language. These documents do not even mention the -ppx option and thus the project was done without comparing the two approaches... However, I think these documents are good to give more visibility to OCaml and maybe convince people that are still reluctant to functional languages. Cheers, Esther Baruk On Fri, May 24, 2013 at 4:35 PM, oliver &lt;oliver&lt; at &gt;first.in-berlin.de&gt; wrote: </pre> Esther Baruk 2013-05-24T14:59:41 http://permalink.gmane.org/gmane.comp.lang.caml.inria/57541 <pre>[...] What about Haskell? Did it "perform" well? Ciao, Oliver </pre> oliver 2013-05-24T14:47:06 http://permalink.gmane.org/gmane.comp.lang.caml.inria/57540 <pre>[...] This reasonable critique has lead to a lot of modern forms of development which means to a programmer, to change the overall direction of a project from week to week. "Oh, we have not taken into account the following", because no planning or market research or customer inquiry was done in advance. Instead of this minimal planning, in the middle of the project anything will be changed... ...more than once... and the project will take a multiple of the time that was first talked about. So, it's not always the bad specifications. It also can be missing of specifications, or missing of the overall goal of a project. So, there are many causes, why a project can be handled ugly... To follow a specification is not eveil in itself. Ciao, Oliver </pre> oliver 2013-05-24T14:43:35 http://permalink.gmane.org/gmane.comp.lang.caml.inria/57539 <pre> Hahah :-) I would be happy to have an english version of this study... my language skills are very delimited and french is not in the small bag of languages I know. Possibly the crucial pages can be translated by some people? Ciao, Oliver </pre> oliver 2013-05-24T14:35:00 http://permalink.gmane.org/gmane.comp.lang.caml.inria/57538 <pre> I was very glad to see the release of the Parsifal code onto Github too: https://github.com/ANSSI-FR/parsifal It looks like you have done a lot of the work required towards building a pure OCaml SSL and Kerberos stack, as well as DNS and SSH parsers in there too. We were just discussing the lack of a pure OCaml SSL library for MirageOS (which already has a full reimplementation of device drivers and TCP/IP and HTTP, and is just missing the final SSL piece). best, Anil </pre> Anil Madhavapeddy 2013-05-24T12:46:30 http://permalink.gmane.org/gmane.comp.lang.caml.inria/57537 <pre>Hi everyone, For information, some of the results have been presented last February during the JFLA (Journées francophones des langages applicatifs). The slides presented are available on the conference web site (http://jfla.inria.fr/2013/programme.html). Regards, Olivier Levillain </pre> Olivier Levillain 2013-05-24T12:41:09 http://permalink.gmane.org/gmane.comp.lang.caml.inria/57536 <pre> For non french readers: it's typical project management ideas from the 19th century. The paper describes a vision of programming projects that's old, erroneous but still prevalent amongst many central administrations, where you first have some infallible specification (it's not stated, but this probably comes from a comity of experts) which is passed down to the programmers, and the main question that's studied is "what tools should these programmers use in order to ensure the code comply to the specifications". Of course, anyone with any experience of how real projects fail in practice will know that most often than not the fatal flaws are in the specifications right from the start, or are introduced to circumvent the rigid structure imposed by such specifications, and that if you want a project to met its goal you have to question the overall process and not merely the tools used by the programmers, which, independent on how much some may be nice and others awful, make little difference in most cases. T</pre> rixed< at >happyleptic.org 2013-05-24T12:35:51 http://permalink.gmane.org/gmane.comp.lang.caml.inria/57535 <pre>Why were you astounded? This is a perfectly legitimate/correct use of the word "variable". On 24 May 2013 01:53, oliver &lt;oliver&lt; at &gt;first.in-berlin.de&gt; wrote: </pre> Arnaud Spiwack 2013-05-24T09:01:39 http://permalink.gmane.org/gmane.comp.lang.caml.inria/57534 <pre> The document "État des lieux des langages fonctionnels" is interesting even out of the context of computer security. http://www.ssi.gouv.fr/IMG/pdf/LaFoSec_-_Etat_des_lieux_des_langages_fonctionnels.pdf PS: and, most importantly, page 55 gives good marks to OCaml compared to other languages (so that we can start to troll now) :-) </pre> Francois Berenger 2013-05-24T07:55:34 http://permalink.gmane.org/gmane.comp.lang.caml.inria/57533 <pre>Hello, For those reading French, ANSSI (French agency for information security) published a study on security and functional languages, with a set of recommendations. OCaml is apparently well studied: http://www.ssi.gouv.fr/fr/anssi/publications/publications-scientifiques/autres-publications/lafosec-securite-et-langages-fonctionnels.html """ Cette étude, menée par un consortium composé de Saferiver, Normation, AMOSSYS et du CEDRIC dans le cadre formel d’un marché du SGDSN, avait pour objectif principal d’étudier l’adéquation des langages fonctionnels pour le développement d’applications de sécurité, de proposer le cas échéant des recommandations, et de mettre en pratique certaines de ces recommandations. """ Best regards, david </pre> David MENTRE 2013-05-24T07:02:29 http://permalink.gmane.org/gmane.comp.lang.caml.inria/57532 <pre>Hi, I was astouned to find the term "variables" in the Reference Manual for OCaml 4.00. Found that on page 136 in the sentence with "(...) statically constructive (...)". Did not checked, if this is on other pages also. To tired to check it, and to tired/lazy for a bugreport now... ...but thought it might be something that might better be corrected. Ciao, Oliver </pre> oliver 2013-05-23T23:53:55 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.lang.caml.inria