Re: [Caml-list] "Let"-less syntax for coreML
Gabriel, > I feel I am missing some background. What is this "coreML" Typed lambda calculus with typical sugar http://caml.inria.fr/pub/docs/u3-ocaml/ocaml-ml.html and common basis (intersection) of all ML languages (SML, OCaml, F#, Haskell) > and what is the point of making subtle syntactic changes to it? > I agree with Don Syme that the syntax of MLs could be simplified to make them easier for the masses but I don't like the indentation for block delimitation rule (Landin's off-side rule) he uses in F# to remove the "begin / end" and the "let ... in" constructions. Not saying it is ever going to happen but it is worth thinking about it and maybe giving a try on my side. The underlying question is "how to make ML mainstream" which is what the (broad) ML community has been trying to do for decades with limited success. Among other things we have tried - standards (SML, Haskell 98) with multiple implementations - optimizing compilers (OCaml, MLTon) - education (first language, data structures, books) - (killer) applications - popular virtual machines (Java, CLR) to reuse their code base - web (Caml as browser extension language in MMM, Caml to JavaScript compilation) and many more Agreed that many of these were successful research projects, not specifically meant to take over the world (of programming languages). The result is two folds - a technical success : check the code written by the INRIA teams, almost everyone uses Caml but those with very specific needs (Java rewriting systems, Prolog, high performance Grobner basis, etc). - a mainstream failure : limited industrial usage besides a couple of companies Diego Olivier -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] "Let"-less syntax for coreML
I wrote a memoire about "why language succeed", and my conclusion was people prefers simple concept at first, even if complex problem become intricately more complex with simpler langage than more powerful like ML/Haskell/Smalltalk/whatever. People are lazy, they don't want to think, they want to write lines of code. Plus, IMHO, imperative permit people to construct algorithms step by step, rather FP which oblige to have a precise idea of your algorithm. IT Industry wants programmers as factory worker (especially in France), they don't want educated people with mathematical background (95% of my former business associate don't know what "Turing complete" is). IT industry is not interested by productivity improvment at all, it would reduce their margin... Jacquard-loom syndrome.. So unhappily, ML/Haskell/Smalltalk/Prolog/Whatever will remain an elite language. You can turn around about many topics (syntax, education, etc...), theses languages will gain what ? 1 or 3% ? 2012/1/4 Diego Olivier Fernandez Pons >[cut] > > The underlying question is "how to make ML mainstream" which is what the > (broad) ML community has been trying to do for decades with limited > success. Among other things we have tried > - standards (SML, Haskell 98) with multiple implementations > - optimizing compilers (OCaml, MLTon) > - education (first language, data structures, books) > - (killer) applications > - popular virtual machines (Java, CLR) to reuse their code base > - web (Caml as browser extension language in MMM, Caml to JavaScript > compilation) > and many more > > Agreed that many of these were successful research projects, not > specifically meant to take over the world (of programming languages). > > The result is two folds > - a technical success : check the code written by the INRIA teams, almost > everyone uses Caml but those with very specific needs (Java rewriting > systems, Prolog, high performance Grobner basis, etc). > - a mainstream failure : limited industrial usage besides a couple of > companies > > Diego Olivier > -- - https://twitter.com/#!/ontologiae/ http://linuxfr.org/users/montaigne -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] "Let"-less syntax for coreML
> The underlying question is "how to make ML mainstream" which is what the Am I the only one to be very, very, very, tired of this question ? There's an obvious thing missing in the list of what has been tried. Well-done and maintained libraries you can use for about any programming task you have at hand -- but I highly doubt this will make "ML mainstream" either, I'm just defending my own interest. IIRC you used to be a library designer, please stop fiddle with the syntax of the language. Library design is also language design. Pick a missing OCaml library you'd have interest in implementing (e.g. a good interface to imap protocol but you may not be interested in that) and fill in the void with a great, modular and tasteful implementation. Best, Daniel P.S. If you think syntax is the main answer to the question above maybe you should have a chat with users of "mainstream" programming languages. In my experience, you'll soon see that their tastes and philosophical view points on programming are rather different than yours (which may be due to ignorance, lack of education and marketing influence but that's rather presumptuous for me to say). -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] "Let"-less syntax for coreML
I was once at a talk in which we discussed new programming concepts in a programming language. One person said "a new programming language whose concepts are not understood by ordinary programers is worthless", to which another replied "a new programming language whose concepts are understood by ordinary programmers is worthless". Cheers, Andrej -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
[Caml-list] "let" and "function" not redundant
Consider the following statement: type pet = Cats|Dogs|Rabbits of pet let list = List.map (function Cats -> "cats" | Dogs -> "dogs") [Cats;Dogs];; for a human, it could be said the "let" and "function" are redundant but bearing in mind, to minimize CPU power and memory use, ocamlyacc will only look one symbol ahead to decide which grammar is intended, and in this case without the let it would not be clear whether Rabbits has type pet or type pet list. Likewise function which is not the same as fun if omitted would cause the function reference to end after Cats which result in a different kind of error. If the front-end was switched to a PEG parser such as teerex more flexibility would be possible but also more mysterious errors which would result in even more difficulty for beginners. If you want to do something useful, how about a program which automatically corrects beginner's syntax errors ? For example, by putting in missing keywords ... -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] "Let"-less syntax for coreML
On Wed, Jan 4, 2012 at 6:06 AM, Daniel Bünzli wrote: > > The underlying question is "how to make ML mainstream" which is what the > > Am I the only one to be very, very, very, tired of this question ? > You're not the only one. I think the biggest thing the community can do to improve OCaml is not to tweak around with language design. It's to improve the library packaging situation. Oasis seems to be the effort in this direction that has the most momentum, so I think pushing Oasis to become every bit as good as Hackage and Cabal is really the place to get maximum leverage. y -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] "Let"-less syntax for coreML
Yaron, > > The underlying question is "how to make ML mainstream" which is what the >> >> Am I the only one to be very, very, very, tired of this question ? >> > > You're not the only one. > Mmm... I didn't request or even suggest a syntax change. I only asked what potential issues it could create. > I think the biggest thing the community can do to improve OCaml is not to > tweak around with language design. It's to improve the library packaging > situation. Oasis seems to be the effort in this direction that has the > most momentum, so I think pushing Oasis to become every bit as good as > Hackage and Cabal is really the place to get maximum leverage. > Then just do it. Diego Olivier -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
[Caml-list] Semantic Web Journal: Call for Papers on Big Data: Theory and Practice
Deadline: February 13, 2012 Semantic Web Journal: Call for Papers on Big Data: Theory and Practice http://www.semantic-web-journal.net/blog/semantic-web-journal-call-papers-big-data-theory-and-practice Semantic Web Journal Call for Papers on Big Data: Theory and Practice http://www.semantic-web-journal.net The Semantic Web journal calls for innovative and high-quality papers describing theory and practice of storing, accessing, searching, mining, processing, and visualizing big data. We especially invite papers that describe or demonstrate how ontologies, Linked Data, and Semantic Web technologies can handle the problems arising when integrating massive amounts of multi-thematic and multi-perspective information from heterogeneous sources to answer complex questions that cut through domain boundaries. We welcome all paper categories, i.e., full research papers, application reports, systems and tools, ontology papers, as well as surveys, as long as they clearly relate to challenges and opportunities arising from processing big data - see our listing of paper types in the author guidelines. In other words, we expect all submitted manuscripts to address how the presented work can exploit massive and/or heterogeneous data. Topics include but are not limited to Sensor Semantics and Smart Dust Semantics-based Aggregation and Generalization of (Observation) Data Massive Data Integration for the Digital Earth Semantic Interoperability and Heterogeneity Linked Science Knowledge Discovery from Linked Data Mining the Social and Mobile Web Inductive and Abductive Approaches to Ontology Learning Ontology Modularization Ontology Evolution Knowledge Patterns On-the-fly Ontology Alignment and Matching Semantic Translation Distributed Reasoning Handling Uncertainty, Vagueness, and Inconsistencies Ontology-driven Data Visualization Semantics-enabled User Interfaces to Handle Massive Data Trust and Privacy Issues in Publishing and Reasoning about Big Data The User as Knowledge Engineer Semantics-based Negotiation between Domain Experts Dialog and Question Answering Systems based on Linked Data and Ontologies Connecting the Semantic Web with Spatial Data Infrastructures and the Model Web Internet of Things Applications of Linked Data Important Dates Manuscript submission due: 13. February 2012 First notification: 26. March 2012 Issue publication: Summer 2012 Submissions The special issue on Big Data Theory and Practice calls for original high-quality research on any of the above mentioned topics. Authors are requested to follow the author guidelines, submit online as detailed in the author guidelines, and include the name of the call within the submission letter. All manuscripts will be reviewed based on the SWJ open and transparent review policy and will be made available during online the review process. Best Regards, Pascal Hitzler Krzysztof Janowicz Editors-in-Chief -- Prof. Dr. Pascal Hitzler Dept. of Computer Science, Wright State University, Dayton, OH pas...@pascal-hitzler.de http://www.knoesis.org/pascal/ Semantic Web Textbook: http://www.semantic-web-book.org Semantic Web Journal: http://www.semantic-web-journal.net -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] "Let"-less syntax for coreML
On 01/04/2012 08:30 AM, Diego Olivier Fernandez Pons wrote: I think the biggest thing the community can do to improve OCaml is not to tweak around with language design. It's to improve the library packaging situation. Then just do it. I have, and the result is odb[1]. It backends with oasis-db[2], meaning if you upload your oasis package, it will be installable via odb, including deps. After finding out about barbra[3], a similar project with a different starting point, I stole many of their good ideas, and now have support for a local `packages` file that provides metadata for packages not available through oasis-db. This packages file allows installation of packages available from arbitrary URLs (anything curl-able), git, svn, cvs, hg, darcs, as well as local directories. For a large number of package examples (plus non-examples of packages that fail to auto-install through make/omake/oasis), look here: https://github.com/thelema/odb/blob/master/packages Contributions of additional packages welcome, fixes to the programs that don't auto-install (See the bottom half of the packages file) are doubly welcome. E. [1] https://github.com/thelema/odb [2] http://oasis.forge.ocamlcore.org/oasis-db.html and http://oasis.ocamlcore.org/dev/odb/ [3] still in stealth mode, maybe I shouldn't have stolen their thunder by mentioning them -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] "Let"-less syntax for coreML
On Wed, Jan 4, 2012 at 07:18, Yaron Minsky wrote: > I think the biggest thing the community can do to improve OCaml is not to > tweak around with language design. It's to improve the library packaging > situation. Oasis seems to be the effort in this direction that has the most > momentum, so I think pushing Oasis to become every bit as good as Hackage > and Cabal is really the place to get maximum leverage. I would say that Jane Street is in a unique position to make a difference here. Having by far the largest OCaml team in the world, nobody else is as likely to benefit from and to achieve the goal of improving the library packaging situation. Just being able to attract more people to OCaml and hence potential employees would seem well worth the cost of specifically dedicating resources and pushing this project through. It is not very likely that individuals or small companies will be able or willing to support this project in the long term, and the OCaml team/INRIA understandably has other priorities (= research). Regards, Markus -- Markus Mottl http://www.ocaml.info markus.mo...@gmail.com -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] "Let"-less syntax for coreML
On 2012-01-04, at 14:30, Diego Olivier Fernandez Pons wrote: > Mmm... I didn't request or even suggest a syntax change. I only asked what > potential issues it could create. Here is one: as far as I can tell, it cannot be parsed by an LALR(1) parser. -- Damien -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] Hashtbl and security
On 2012-01-02, at 02:43, oliver wrote: > If the type is an abstract type, which comes from something like > Hashtbl.Randomseed > and has type t, not type int, this problem would vanish. You have to be careful. If we make hash table randomization mandatory, the Frama-C people will hate us, as will all the people who want reproducible results from their programs (for purposes of testing and benchmarking, for example). So, even if randomized is the default, there must be a way to get a plain hash table that does the same thing every time. -- Damien -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] Understanding usage by the runtime
On 2012-01-01, at 13:44, Richard W.M. Jones wrote:
> Is compaction disabled? lablgtk disables it unconditionally by
> setting the global Gc max_overhead (see also the Gc documentation):
>
> src/gtkMain.ml:
>let () = Gc.set {(Gc.get()) with Gc.max_overhead = 100}
Anyone who disables compaction should seriously consider switching
to the first-fit allocation policy:
let () = Gc.set {(Gc.get ()) with Gc.allocation_policy = 1}
This may slow down allocations a bit, but the theory tells us that
it completely prevents unbounded fragmentation of the OCaml heap.
-- Damien
--
Caml-list mailing list. Subscription management and archives:
https://sympa-roc.inria.fr/wws/info/caml-list
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] Understanding usage by the runtime
On 04/01/2012, Damien Doligez wrote:
> On 2012-01-01, at 13:44, Richard W.M. Jones wrote:
>
>> Is compaction disabled? lablgtk disables it unconditionally by
>> setting the global Gc max_overhead (see also the Gc documentation):
>>
>> src/gtkMain.ml:
>>let () = Gc.set {(Gc.get()) with Gc.max_overhead = 100}
>
> Anyone who disables compaction should seriously consider switching
> to the first-fit allocation policy:
>
> let () = Gc.set {(Gc.get ()) with Gc.allocation_policy = 1}
>
> This may slow down allocations a bit, but the theory tells us that
> it completely prevents unbounded fragmentation of the OCaml heap.
I've often wondered what I should do when using lablgtk. It's a pretty
annoying issue and, as far as I understand, OCaml will only return the
memory to the OS upon compactions.
There is however something to do. Quoting lablgtk's README:
> IMPORTANT: Some Gtk data structures are allocated in the Caml heap,
> and their use in signals (Gtk functions internally cally callbacks)
> relies on their address being stable during a function call. For
> this reason automatic compation is disabled in GtkMain. If you need
> it, you may use compaction through Gc.compact where it is safe
> (timeouts, other threads...), but do not enable automatic compaction.
I've never really understood why it worked: I'm surprised the GC would
update addresses stored in the C side of GTK.
If you want to use timeouts, the following should work:
Glib.Timeout.add ~ms:0 ~callback:(fun () -> Gc.compact (); false)
I guess that Glib.Idle.add would work too.
That guarantees nothing about the time the compaction will run however
and in practice, adding a timeout or an idle and starting a long-running
and uninterruptible computation right after will severely delay the
compaction.
I haven't had the time to try it but it should be possible to pump
glib's event loop by hand in order to trigger the compaction. Another
possibility would be to spawn a thread and use a mutex to wait until the
compaction is done. And in case you're using Lwt, well, I don't know but
I'd expect the callback to be callable whenever threads can be switched.
Maybe that if it were possible to have a callback called each time the
runtime would like to do a compaction, this could be automated.
Regards,
Adrien Nader
--
Caml-list mailing list. Subscription management and archives:
https://sympa-roc.inria.fr/wws/info/caml-list
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] Understanding usage by the runtime
> There is however something to do. Quoting lablgtk's README: > > IMPORTANT: Some Gtk data structures are allocated in the Caml heap, > > and their use in signals (Gtk functions internally cally callbacks) > > relies on their address being stable during a function call. For > > this reason automatic compation is disabled in GtkMain. If you need > > it, you may use compaction through Gc.compact where it is safe > > (timeouts, other threads...), but do not enable automatic compaction. > > I've never really understood why it worked: I'm surprised the GC would > update addresses stored in the C side of GTK. I think the problem is, a C function can invoke a callback that calls ocaml code that moves the object being operated on by the C function. Because the C function is precompiled it does not register its copy of the pointer as a GC root. When the callback returns the C function's pointer is invalid. This should be fixable with another level of indirection. Finalization can free the C object. I infer from reading the source that the extra level of indirection is considered an unacceptable penalty. -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] Hashtbl and security
On Wed, Jan 04, 2012 at 06:56:11PM +0100, Damien Doligez wrote: > On 2012-01-02, at 02:43, oliver wrote: > > > If the type is an abstract type, which comes from something like > > Hashtbl.Randomseed > > and has type t, not type int, this problem would vanish. > > You have to be careful. If we make hash table randomization mandatory, > the Frama-C people will hate us, as will all the people who want > reproducible results from their programs (for purposes of testing and > benchmarking, for example). [...] I did not meant it must be mandatory. But provide a way, that makes it easy to use randomization and not-so-easy to use the always-same values e.g. for testing puroposes. If it needs extra effort to make simple seed values, people would prefer the randomized ones, if not they want to write some extra code (maybe applying a functor). > > So, even if randomized is the default, there must be a way to get a > plain hash table that does the same thing every time. Yes, of course. But maybe it should not be encouraged, and the programmer-in-a-hurry would use ready-to-use random initializations, which are provided by the Hashtbl-module and the one who needs it non-randomized would need to write his own addition then. Then the lazy programmer goes safe and the unsafe way needs extra effort. Nevertheless I think optional int value as a first fix would also be ok. And maybe some of you remember the Debian random-device bug (some years ago), where the random-device under certain circumstances ran out of entropy So in any case it needs to be possible to change the random generator. But pseudo-random is always a compromise. Who really needs true random should of course use special hardware that creates wide bandwith noise and uses an ADC to sample the signal. Ciao, Oliver -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
oasis (was Re: [Caml-list] "Let"-less syntax for coreML)
On 4 January 2012 13:18, Yaron Minsky wrote: > I think the biggest thing the community can do to improve OCaml is not to > tweak around with language design. It's to improve the library packaging > situation. Oasis seems to be the effort in this direction that has the most > momentum, so I think pushing Oasis to become every bit as good as Hackage > and Cabal is really the place to get maximum leverage. Agreed, and all my packages will eventually support oasis. This was planned about half a year ago but I was told it would be simpler for me to wait for oasis-db 0.1.0~alpha3 but somehow that never materialized. I see two problems with oasis right now : 1) It seems Sylvain doesn't have much time to work on the system. Oasis tries to solve (IMHO too) many problems and is therefore a significant piece of software. This means it is less easy to contribute to and if Sylvain doesn't work on it, the project grinds to a halt. I think Sylvain, in order to gain acceptance maybe tried to be too inclusive feature-wise w.r.t. to dev practices -- not to mention that as a debian packager he also had ideas to save time there. It is perfectly understandable but it may have had some perverse effects on the complexity of the system. If I may, I would like to suggest to Sylvain that development of the oasis and oasis-db should entirely focus on the infrastructure needed so that a reasonable and useful set of packages are able to work with something like odb.ml. To give an example, oasis-db as the human browsable website is a very nice plus (e.g. I do enjoy browsing on hackage), but it is a significant piece of work and IMHO just shouldn't be a priority. By showing us that something like odb.ml actually solves the problems we have as ocaml developers --- quickly install this (high-quality of course) lib to help me write my program --- I'm sure the supposedly stubborn library devs would be willing to change and standardize their practice around those mandated by oasis and this could lead to a simpler system (vs. trying to please everyone). Just give us something that you have enough confidence in and tell us, this is usable now, use it, it may have limitations, but it already helps. And after iterate on that to eventually get to the big, planned system -- or not. 2) The current documentation is useless. When I did the _oasis file for cmdliner I had to find what the actual value of OASISformat should be by trial/error... The documentation provides a high-level description of all the available fields for _oasis files but it doesn't precisely describe their _syntax_ (types !) and their _effect_. It also doesn't describe how the system works from an architectural perspective. We need a good manual -- and please not a wiki. Best, Daniel -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
