* to have labels or not @ 2000-03-17 19:30 Jan Brosius 2000-03-19 4:39 ` Brian Rogoff 0 siblings, 1 reply; 19+ messages in thread From: Jan Brosius @ 2000-03-17 19:30 UTC (permalink / raw) To: caml-list Hi, I am looking around to have a good , free and very easy language , portable and so on, producing fast code. Objective Caml was and still is for me a serious candidate among the many free portable languages on the net. I realise that it is not up to me to enforce a decision . I also realize that credits always should be given to the implementors and France's research institute INRIA. My personal choice is not to use labels at all because it makes the readable code too big, it is better I think to use meaningful words and within comments to clarify the types of the functions. I think I would never use the "label on " option. function x -> .. could be shortened by : \x ->..... I think and the use of [`a] instead of `a list and the use of list comprensions as in Haskell could shorten the readable code and maintain readability. friendly et amicalement Jan Brosius ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: to have labels or not 2000-03-17 19:30 to have labels or not Jan Brosius @ 2000-03-19 4:39 ` Brian Rogoff 2000-03-22 2:30 ` Markus Mottl 0 siblings, 1 reply; 19+ messages in thread From: Brian Rogoff @ 2000-03-19 4:39 UTC (permalink / raw) To: Jan Brosius; +Cc: caml-list On Fri, 17 Mar 2000, Jan Brosius wrote: > My personal choice is not to use labels at all because it makes the readable > code too big, it is better I think to use meaningful words and within > comments to clarify the types of the functions. I don't believe this argument. I got the labeled and nonlabeled versions of Markus Mottl's PCRE library and looked at their respective sizes; the labeled versions had significantly less code (10-20% I think) than the unlabeled. It also dealt better with that name mess caused by optional parameters in the old PCRE interface causing it to read better IMO. I agree that labels seem heavy for some uses, and depending on your coding style they may not be for you. Making the labels single letter names seems like a bad idea. How do we distinguish "file" and "function" for example? I like "fn" but "func" is OK too. I like ":", and I'm not sure I want to give up $, %, or & for labels. Its nice to be able to use these as infixes, whether or not infixes are good for programming-in-the-large. I also agree that the error messages are difficult, but that's orthogonal to labels, call it the "price of type inference". Whatever happened to those other O'Labl features that haven't made it into OCaml yet? In particular, polymorphic methods. > I think I would never use the "label on " option. Never say never. > function x -> .. could be shortened by : \x ->..... I think and the use > of [`a] instead of `a list and the use of list comprensions as in Haskell > could shorten the readable code and maintain readability. Actually `a is another issue, and elsewhere it was rightly suggested that it be made illegal ;-). OK, seriously, you can use CamlP4 to get comprehension syntax, and but it doesn't work yet with labels so you won't have a chance to try them if you need P4. -- Brian ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: to have labels or not 2000-03-19 4:39 ` Brian Rogoff @ 2000-03-22 2:30 ` Markus Mottl 2000-03-23 0:57 ` Max Skaller 2000-03-28 1:04 ` labels, Hash.create Julian Assange 0 siblings, 2 replies; 19+ messages in thread From: Markus Mottl @ 2000-03-22 2:30 UTC (permalink / raw) To: Brian Rogoff; +Cc: OCAML > I don't believe this argument. I got the labeled and nonlabeled > versions of Markus Mottl's PCRE library and looked at their respective > sizes; the labeled versions had significantly less code (10-20% I think) > than the unlabeled. It also dealt better with that name mess caused by > optional parameters in the old PCRE interface causing it to read better > IMO. The PCRE library was my first "guinea pig" for using labels - and I think that it was a fairly successful experiment. At least in my opinion (and Brian's above) it made the code much more transparent - not only to me as developer but especially to the users. I think that there are some specific domains where labels are really most helpful: applications that can be heavily parameterized clearly benefit from both default arguments (makes function application much less painful) and label names (makes use of functions with fat interfaces much more understandable). It seems obvious to me that GUI-libraries (though, I don't know much about GUI-programming) and many others that are tailored for a specific purpose (e.g. string matching) belong into this domain. On the other hand, I have to admit that I never use labels with the standard library. This may be partly due to accustomization to "classic style", but definitely also, because the standard library is not "specialized" enough (it wouldn't be "standard" then): there are only very few functions that take numerous "flags" and "options". The "implicitely agreed on" order of parameters seems to be clear enough to me. Additionally, I also find labels a bit cumbersome to use with higher-order functions. That's why I generally prefer "classic mode" over "label mode". Since there were some voices that nearly seemed to ask for taking out labels as a whole, I wonder what alternatives there are for, e.g., implementing optional arguments, which I consider as a very big "complexity saver". I have experimented a bit now with other ways, but haven't found anything only closely as convenient as "labels" to do it. I have tried objects (painraiser for the developer and also a bit slow due to dispatch for each method call to change "parameters") and also functions with lists of parameters, where the parameters are polymorphic variants (no need to define an extra type). The latter also requires some amount of masochism on the side of the developer and application is still noticably slower. I also tried to find other additions to the language that fit better to the "core", but whenever I wanted to refine an idea (e.g. something similar to records that allow default values), it "converged" towards labels... It is fully understandable that many people are happy with the core language + module language alone and want it to stay untouched. When I started using OCaml (having used C++ before), I knew nothing about functional programming and came up with stupid questions like "why don't you implement the standard library using objects?". Thanks to this mailing list and this wonderful language, my point of view underwent a dramatic shift (also raising my interest in theory to a level which made me take a course on formal semantics *voluntarily* (!) ;-) But what I also like about this language is that it is a dynamic process: it does not stand still! (SML looks like a boring snail in comparison). And somehow magically, neither the "OO"-addition nor the "label"-addition seem to require any "incompatible" change to the core. So I really do not understand the point of the quarrel on labels here - whoever needs them (and wherever) can use them, but nobody is forced to do so! Though I avoid them with the standard library, I do not see where anybody could be harmed by them. I guess the growing heat in this thread is mostly due to irrational fears that somebody might enforce labels in the default mode, which, I think (and hope ;-), will never happen... Best regards, Markus Mottl -- Markus Mottl, mottl@miss.wu-wien.ac.at, http://miss.wu-wien.ac.at/~mottl ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: to have labels or not 2000-03-22 2:30 ` Markus Mottl @ 2000-03-23 0:57 ` Max Skaller 2000-03-23 3:46 ` Markus Mottl 2000-03-24 2:41 ` Jacques Garrigue 2000-03-28 1:04 ` labels, Hash.create Julian Assange 1 sibling, 2 replies; 19+ messages in thread From: Max Skaller @ 2000-03-23 0:57 UTC (permalink / raw) To: Markus Mottl; +Cc: Brian Rogoff, OCAML Markus Mottl wrote: > So I really do not understand the point of the quarrel on labels here - There's no quarrel. Instead it is 'give people an inch and they want a mile'. Instead of two languages, ocaml and olabl, we now have one language with two modes. This is much better for the compiler developers, and classic mode ocaml users have some benefits, but the olabl system is somewhat compromised. So now, we want something better: a _single_ language, not two variants. The arguments about the standard library seem to me to be this: some of the ocaml (classic) users like myself would prefer to move to the modern/strict/label mode and get rid of the classic mode. But we're not willing to do so if it clutters our use of the standard library. I hope this represents the reason for the 'arguments' here, especially ones for removing labels from the standard library (or, keeping the old unlabelled one). I do not feel I gain the real advantage of labels with GUI/PCRE type libraries _unless_ the labelled optional argument things commute. I also don't want to clutter use of simple standard library functions with labels. So here's a suggestion. Get rid of classic mode. But have TWO complete standard libraries: module Classic = .. put classic modules here .. module Olabl = put labelled versions here and now we can choose libraries in the usual way with open Classic or open Olabl IF -classic or -label is specified on the compiler command line, one of these open statements is inserted into each module 'by magic', this is a compatibility hack for legacy code. Now, we have two libraries, but one language. This is not ideal, but it is better, because now we can ague about how to merge the libraries, and because libraries are generally under _user_ control, whereas compilers are not. -- John (Max) Skaller at OTT [Open Telecommications Ltd] mailto:maxs@in.ot.com.au -- at work mailto:skaller@maxtal.com.au -- at home ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: to have labels or not 2000-03-23 0:57 ` Max Skaller @ 2000-03-23 3:46 ` Markus Mottl 2000-03-23 23:22 ` Max Skaller 2000-03-28 1:07 ` Julian Assange 2000-03-24 2:41 ` Jacques Garrigue 1 sibling, 2 replies; 19+ messages in thread From: Markus Mottl @ 2000-03-23 3:46 UTC (permalink / raw) To: Max Skaller; +Cc: OCAML > So now, we want something better: a _single_ language, not two variants. I agree that having a single language should be a medium-term goal. > The arguments about the standard library seem to me to be this: some of > the > ocaml (classic) users like myself would prefer to move to the > modern/strict/label > mode and get rid of the classic mode. But we're not willing to do so if > it > clutters our use of the standard library. I also agree here: use of the standard library should not become inconvenient. If this requires to remove labels from part or even all of it - well, then so be it. Though, I wouldn't like seeing them to be removed from the language itself. > I do not feel I gain the real advantage of labels with GUI/PCRE > type libraries _unless_ the labelled optional argument things > commute. I also don't want to clutter use of simple > standard library functions with labels. Optional arguments can also be used to pass the "same" argument in different forms (by using different labels on them), as is the case in the PCRE: you can pass regular expressions as a string, in which case it will be compiled for you, or as a precompiled regular expression, useful if matching happens in a loop. This can be done by having two optional arguments, one overriding the other if present. There is no commuting involved (not necessarily), but this "trick" still gives the user a great deal more of flexibility: he can choose whether he wants the "readable" or "efficient" form without having to memorize more function names. If I had wanted to do something similar with the previous (unlabeled) version, this would have required me to invent a new prefix for the "readable" form of the function and to *double* the number of all access functions for all of the already existing forms, which was already perversly high. With each similar new "feature", the number of special functions grows exponentially - a horror for both the user and the maintainer... > So here's a suggestion. Get rid of classic mode. > But have TWO complete standard libraries: I do not think that this is the way to go: this will just shift the problem of "two styles" from the compiler to the library. > IF -classic or -label is specified on the compiler > command line, one of these open statements is inserted > into each module 'by magic', this is a compatibility hack > for legacy code. But where is the difference then if you still can (have to) specify a flag on the command line to switch between styles? The aim should be to get rid of such a flag and still satisfy all (at least: most of the) users. I really believe it is a good idea to have two modes know, allowing people to adapt to new styles of programming (or not). In any case, more experience among the users will make it easier to take a final decision. Regards, Markus Mottl -- Markus Mottl, mottl@miss.wu-wien.ac.at, http://miss.wu-wien.ac.at/~mottl ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: to have labels or not 2000-03-23 3:46 ` Markus Mottl @ 2000-03-23 23:22 ` Max Skaller 2000-03-28 1:07 ` Julian Assange 1 sibling, 0 replies; 19+ messages in thread From: Max Skaller @ 2000-03-23 23:22 UTC (permalink / raw) To: Markus Mottl; +Cc: OCAML Markus Mottl wrote: > I do not think that this is the way to go: this will just shift the problem > of "two styles" from the compiler to the library. Yes. > > IF -classic or -label is specified on the compiler > > command line, one of these open statements is inserted > > into each module 'by magic', this is a compatibility hack > > for legacy code. > > But where is the difference then if you still can (have to) specify a flag > on the command line to switch between styles? You don't have to. This is a compability hack. There's only one language. > The aim should be to get rid > of such a flag and still satisfy all (at least: most of the) users The hack remains until everyone updates their code to select the desired libraries (which now have new names). This can be done by adding one line to every ml file. -- John (Max) Skaller at OTT [Open Telecommications Ltd] mailto:maxs@in.ot.com.au -- at work mailto:skaller@maxtal.com.au -- at home ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: to have labels or not 2000-03-23 3:46 ` Markus Mottl 2000-03-23 23:22 ` Max Skaller @ 2000-03-28 1:07 ` Julian Assange 1 sibling, 0 replies; 19+ messages in thread From: Julian Assange @ 2000-03-28 1:07 UTC (permalink / raw) To: Markus Mottl; +Cc: Max Skaller, OCAML, proff Markus Mottl <mottl@miss.wu-wien.ac.at> writes: > Optional arguments can also be used to pass the "same" argument in > different forms (by using different labels on them), as is the case in the > PCRE: you can pass regular expressions as a string, in which case it will > be compiled for you, or as a precompiled regular expression, useful if > matching happens in a loop. This can be done by having two optional > arguments, one overriding the other if present. There is no commuting > involved (not necessarily), but this "trick" still gives the user a great > deal more of flexibility: he can choose whether he wants the "readable" or > "efficient" form without having to memorize more function names. Welcome to dynamic lisp. Cheers, Julian. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: to have labels or not 2000-03-23 0:57 ` Max Skaller 2000-03-23 3:46 ` Markus Mottl @ 2000-03-24 2:41 ` Jacques Garrigue 2000-03-25 3:12 ` Markus Mottl 2000-03-25 3:57 ` John Max Skaller 1 sibling, 2 replies; 19+ messages in thread From: Jacques Garrigue @ 2000-03-24 2:41 UTC (permalink / raw) To: maxs; +Cc: mottl, bpr, caml-list From: Max Skaller <maxs@in.ot.com.au> > The arguments about the standard library seem to me to be this: some of > the > ocaml (classic) users like myself would prefer to move to the > modern/strict/label > mode and get rid of the classic mode. But we're not willing to do so if > it > clutters our use of the standard library. This is a reasonable argument. However, by discussing with olabl users (many of them being originally ocaml users) I really got the feeling that the fact to have to write labels for standard library functions didn't bother them. I wouldn't be honest if I don't admit that there are some exceptions, but then everybody cannot agree on everything. And olabl didn't provide anything similar to classic mode, just a raw compatibility mode in which you couldn't use optionals at all. So before deciding whether you want to stay classic or go to commuting label mode, you might just give it an (extensive enough) try. By the way, it seems that there will be less labels in the standard library in 3.00. > I do not feel I gain the real advantage of labels with GUI/PCRE > type libraries _unless_ the labelled optional argument things > commute. I also don't want to clutter use of simple > standard library functions with labels. Here is probably the biggest misunderstanding. In classic mode, optional arguments _do commute_. Only non-optional and unlabelled ones do not. And I would say that for most people (at least those with a pure ocaml background), the only commutations that matter are those between optional arguments. Remark for instance that Markus Mottl himself explained that he was using only classic mode. > So here's a suggestion. Get rid of classic mode. > But have TWO complete standard libraries: > > module Classic = .. put classic modules here .. > module Olabl = put labelled versions here We thought about that. And even tried it before releasing 2.99. I am the one who pushed against this solution, because I felt this would really cause a community split. The problem is not just the standard library. If you do not have classic mode, then it means that everybody will have to write all labels. If you have a look at LablGL, you will see that I use there plenty of non-optional labels, and very few optional ones. I'm pretty sure people would start asking me to remove them. On the contrary, if you have classic mode, even classic mode users can add documenting labels to their interfaces. And then commuting label mode users can use these labels to pass arguments in the order they prefer. The whole point is: the user (not the implementor) should decide. And in practice it is better to decide on a program-wide rather than a per-module basis (as some suggested). In extreme cases where you want to mix both modes in the same program, you can do it on a per-file basis. This is not encouraged, but there are well-defined semantics as long as you write a .mli file (or check types in the .cmi file). I really think that being able to switch in the middle of a file would be dangerous. I'm already sometimes confused by such uses of "open". The only weakness of this approach is if you copy some code from a file in classic mode to one in commuting label mode (or reverse). Then you have to add/remove labels by hand. But then this is also a way to understand the code better :-) It might also be possible to develop a tool to do that semi- automatically. In fact Jun Furuse has been asking for it for a long time, but I think he is big enough to be able to do it himself :-) Best regards, Jacques ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: to have labels or not 2000-03-24 2:41 ` Jacques Garrigue @ 2000-03-25 3:12 ` Markus Mottl 2000-03-25 3:57 ` John Max Skaller 1 sibling, 0 replies; 19+ messages in thread From: Markus Mottl @ 2000-03-25 3:12 UTC (permalink / raw) To: Jacques Garrigue; +Cc: OCAML > Remark for instance that Markus Mottl himself explained that he was > using only classic mode. Currently ;-) I'll see whether commuting arguments is sufficient enough an incentive to switch modes: but what concerns the problem with HOFs, there should really be a solution - at least what concerns the standard library. > I really think that being able to switch in > the middle of a file would be dangerous. I'm already sometimes > confused by such uses of "open". I agree: "open" is potentially dangerous. It is not only confusing at times, it can even break modules (e.g. if you add functions to one module which shadow definitions in another module). Best regards, Markus -- Markus Mottl, mottl@miss.wu-wien.ac.at, http://miss.wu-wien.ac.at/~mottl ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: to have labels or not 2000-03-24 2:41 ` Jacques Garrigue 2000-03-25 3:12 ` Markus Mottl @ 2000-03-25 3:57 ` John Max Skaller 2000-03-29 20:32 ` Brian Rogoff 1 sibling, 1 reply; 19+ messages in thread From: John Max Skaller @ 2000-03-25 3:57 UTC (permalink / raw) Cc: caml-list Jacques Garrigue wrote: > This is a reasonable argument. However, by discussing with olabl > users (many of them being originally ocaml users) I really got the > feeling that the fact to have to write labels for standard library > functions didn't bother them. It bothers me, because it will create a lot of extra clutter, and force me to 'fix' thousands of lines of code. I'm having enough trouble coping with the weak error messages in classic ocaml, without being confused by additional ones. I often make systematic changes (replace one type with another), and I rely on compiler diagnostics to find all the uses to allow me to upgrade the relevant code. This works well in C and C++, but not so well in ocaml (for a variety of reasons). My small experiment with polymorphic variants sent me running for my backup copy. :-( [I replaced a large 'type X = | v1 .. | v2 .. ' with three smaller (non-polymorphic) variants, and created three polymorphic variants each covering two of theses cases. Had this worked, it would have greatly improved my code, since many functions are only interested in 2/3 of the cases -- the other 1/3 cannot occur dynamically, and it is really bad writing default handlers like '| _ -> assert false' because this prevents the compiler diagnosing missing cases. Anyhow, I couldn't get it to work after two days, so I gave up. I couldn't make head or tail of the error messages half the time FYI: the case involed is a language 'term', of which there are three kinds: ones that only exist at compile time and are replaced on evaluation (sugary constructions), ones that are the same at compile and run time (things like integers), and ones that only exist at run-time (like dictionaries represented as hashtables). ] > So before deciding whether you want to stay classic or go to commuting > label mode, you might just give it an (extensive enough) try. How? The modes are incompatible. > > So here's a suggestion. Get rid of classic mode. > > But have TWO complete standard libraries: > > > > module Classic = .. put classic modules here .. > > module Olabl = put labelled versions here > > We thought about that. And even tried it before releasing 2.99. > I am the one who pushed against this solution, because I felt this > would really cause a community split. The community started out split, and has been brought closer together by the ocaml/olabl merger. But the community is _still_ split because the usage of the modes is incompatible: we have two languages and one library. The way I see it, two libraries and one language reduces the split again. I do _not_ see this as idea -- OR permanent. But having two libraries is a temporary hack to allow a full merger of the languages, and to focus on an acceptable compromise to get one library. > The problem is not just the standard library. > If you do not have classic mode, then it means that everybody will > have to write all labels. If you have a look at LablGL, you will see > that I use there plenty of non-optional labels, and very few optional > ones. I'm pretty sure people would start asking me to remove them. I don't think so. The greatest feeling here is with the standard libraries, because we all have a vested interest in out current code, and our programming habits. > The whole point is: the user (not the implementor) should decide. > And in practice it is better to decide on a program-wide rather than a > per-module basis (as some suggested). I don't agree: I do not wish to choose between two 'almost the same' languages. But I regularly chose which library components to use in an application, so this is just the same choice I usually make. > The only weakness of this approach is if you copy some code from a > file in classic mode to one in commuting label mode (or reverse). > Then you have to add/remove labels by hand. But then this is also a > way to understand the code better :-) In a production environment, one is NOT interested in understanding 'the code', one is trying to USE the code WITHOUT understanding it. This is the very point of abstraction and information hiding. For example, I use Pcre, I do NOT understand the code, and I don't want to. I'm too busy to waste time on such details, I prefer to trust Markus -- complain if something doesn't work as advertised, or ask for help if I don't understand. BTW: I'm not claiming two libraries is the right solution either. I really don't know. I am glad a first step has been made to merge the two systems. Thank you! -- John (Max) Skaller, mailto:skaller@maxtal.com.au 10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850 checkout Vyper http://Vyper.sourceforge.net download Interscript http://Interscript.sourceforge.net ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: to have labels or not 2000-03-25 3:57 ` John Max Skaller @ 2000-03-29 20:32 ` Brian Rogoff 2000-03-30 9:56 ` John Max Skaller 2000-04-04 6:53 ` Jacques Garrigue 0 siblings, 2 replies; 19+ messages in thread From: Brian Rogoff @ 2000-03-29 20:32 UTC (permalink / raw) To: John Max Skaller; +Cc: caml-list On Sat, 25 Mar 2000, John Max Skaller wrote: > Jacques Garrigue wrote: > > > So here's a suggestion. Get rid of classic mode. > > > But have TWO complete standard libraries: > > > > > > module Classic = .. put classic modules here .. > > > module Olabl = put labelled versions here > > > > We thought about that. And even tried it before releasing 2.99. > > I am the one who pushed against this solution, because I felt this > > would really cause a community split. > > The community started out split, and has been brought closer together > by the ocaml/olabl merger. But the community is _still_ split because > the usage of the modes is incompatible: we have two languages and one > library. > The way I see it, two libraries and one language reduces the split > again. > I do _not_ see this as idea -- OR permanent. But having two libraries > is a temporary hack to allow a full merger of the languages, and to > focus on an acceptable compromise to get one library. I agree with John Skaller on this. Two libraries seems like a better compromise than two modes. There is also some precedent here in that the standard libraries were never "OO-ized" after an object system was added to Caml. There just doesn't seem to be a good solution to this problem, i.e., one which will leave everyone happy. This is the human engineering part of programming language design, and since it appears a lot of Caml programmers find labels too heavy for their programming style I think we should go with the rule "When in doubt, leave it out". Out of the standard library that is. I'm not happy with this, as I prefer the labeled style, but it appears that the community is already somewhat split. Of course, some people may complain (as Jacques suggested) about the labels in certain libraries infecting their code if modern/labeled mode became the only mode but I think that's a minor problem that can be solved by those people by writing wrappers. > BTW: I'm not claiming two libraries is the right solution > either. I really don't know. Yes, it's certainly not a solution that makes you slap your head and go "Why didn't I think of that?" but it seems to be an improvement. -- Brian ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: to have labels or not 2000-03-29 20:32 ` Brian Rogoff @ 2000-03-30 9:56 ` John Max Skaller 2000-04-04 6:53 ` Jacques Garrigue 1 sibling, 0 replies; 19+ messages in thread From: John Max Skaller @ 2000-03-30 9:56 UTC (permalink / raw) To: Brian Rogoff; +Cc: caml-list Brian Rogoff wrote: > There just doesn't seem to be a good solution to this problem, i.e., one > which will leave everyone happy. Never say die -- see Christophe Raffalli's posting. This is looking promising to me. The idea that labels can be optional on use provided they're mandatory on definition seems exactly the right balance to me. -- John (Max) Skaller, mailto:skaller@maxtal.com.au 10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850 checkout Vyper http://Vyper.sourceforge.net download Interscript http://Interscript.sourceforge.net ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: to have labels or not 2000-03-29 20:32 ` Brian Rogoff 2000-03-30 9:56 ` John Max Skaller @ 2000-04-04 6:53 ` Jacques Garrigue 2000-04-04 13:04 ` John Max Skaller 2000-04-04 16:39 ` Brian Rogoff 1 sibling, 2 replies; 19+ messages in thread From: Jacques Garrigue @ 2000-04-04 6:53 UTC (permalink / raw) To: bpr; +Cc: skaller, caml-list From: Brian Rogoff <bpr@best.com> > I agree with John Skaller on this. Two libraries seems like a better > compromise than two modes. There is also some precedent here in that > the standard libraries were never "OO-ized" after an object system was > added to Caml. Finding a mode which would allow OO-izing the standard library while keeping backward compatibility would be a nice challenge :-) We could discuss very long on the two library vs. two mode approaches, without reaching a conclusion. Both have their own merits. However an important point in this choice is just practical implementation problems: * using the current OCaml techniques, like MD5 identification of module interfaces, linking of codes based on different libraries is not possible. Moreover, making it possible without code duplication is not trivial. * maintaining concurently two different standard libraries would be a pain. It was already with olabl. And what about Str, Dbm or Unix, which can naturally profit from similar labellings. * on the other hand, the two mode scheme only requires a few lines in the compiler. Basically switching on or off some checks, and a slightly different treatment of function application. So I believe that having 2 modes was a rather natural first choice. Now, if we realize after some time that this was not a good choice, it will still be possible to change it for another approach. Of course with a transition as painless as possible, and with the core language preserved. > There just doesn't seem to be a good solution to this problem, i.e., one > which will leave everyone happy. This is the human engineering part of > programming language design, and since it appears a lot of Caml programmers > find labels too heavy for their programming style I think we should go > with the rule "When in doubt, leave it out". Out of the standard library > that is. I'm not happy with this, as I prefer the labeled style, but it > appears that the community is already somewhat split. Keep cool, we are not talking about divorce :-) If we let conservatism decide on all subjects, there is no possible progress. Are we going to have people to vote about what scientific theories they like, or (more accurate) which novel writers should be published and which not? Let's leave people more time to decide what they want for themselves. Then at that point there may be a better solution, which an early decision would not have discovered. Best regards, Jacques P.S. If I remember correctly, you asked a while ago about what would happen of olabl polymorphic methods. In fact, there is no progress since last Christmas, and I still view it the same way. When 3.00 is released, I may start writing a quick patch based on olabl code. If after a while I can come out with something stable enough and that would not slow down the compiler, I think there would be no specific problem in including it in the main compiler. But I have no idea of when. For the time being, either you have to stick to olabl 2.04, or find a workaround without polymorphic methods. My experience is that for most non-theoretical uses there are workarounds. --------------------------------------------------------------------------- Jacques Garrigue Kyoto University garrigue at kurims.kyoto-u.ac.jp <A HREF=http://wwwfun.kurims.kyoto-u.ac.jp/~garrigue/>JG</A> ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: to have labels or not 2000-04-04 6:53 ` Jacques Garrigue @ 2000-04-04 13:04 ` John Max Skaller 2000-04-04 16:39 ` Brian Rogoff 1 sibling, 0 replies; 19+ messages in thread From: John Max Skaller @ 2000-04-04 13:04 UTC (permalink / raw) To: Jacques Garrigue; +Cc: bpr, caml-list Jacques Garrigue wrote: > We could discuss very long on the two library vs. two mode > approaches, without reaching a conclusion. Both have their own > merits. > > However an important point in this choice is just practical > implementation problems: > > * using the current OCaml techniques, like MD5 identification of module > interfaces, linking of codes based on different libraries is not > possible. Moreover, making it possible without code duplication is > not trivial. My specification does not create any problems. It cannot, it requires the client to choose the libraries _exactly_ as they do now, by 'open'ing the required modules. The compiler switch hack is _exactly_ like inserting magical 'open' statements at the beginning of each source file. Therefore, this argument is not effective against my two libraries proposal, although it may knock out others using a different selection mechanism. > * maintaining concurently two different standard libraries would be a > pain. It was already with olabl. And what about Str, Dbm or Unix, > which can naturally profit from similar labellings. This argument cannot be knocked out, but I can knock its effectiveness down to a quite tolerable minimum using a powerful tool you've heard of before, namely interscript, my literate programming tool. Using interscript, you create a _single_ body of 'code' which is used to _generate_ the two libraries .. in such a way they're quite easy to keep synchronised .. and documented .. since the code .. and documentation .. is generated from a single specification. > * on the other hand, the two mode scheme only requires a few lines > in the compiler. Basically switching on or off some checks, and a > slightly different treatment of function application. This is a strong argument to retain the current system until a _clearly_ superior proposal surfaces. I'd agree that is not the case. Yet :-) > So I believe that having 2 modes was a rather natural first choice. > Now, if we realize after some time that this was not a good choice, it > will still be possible to change it for another approach. Of course > with a transition as painless as possible, and with the core language > preserved. Agreed. > Keep cool, we are not talking about divorce :-) > If we let conservatism decide on all subjects, there is no possible > progress. Are we going to have people to vote about what scientific > theories they like, or (more accurate) which novel writers should be > published and which not? > Let's leave people more time to decide what they want for themselves. > Then at that point there may be a better solution, which an early > decision would not have discovered. I agree. But are we not covering the obvious .. and not so obvious .. nearby territory so as to ascertain at least that there is not an immediately accessible superior solution? Isn't this also not good science? Indeed, if this discussion were NOT occurring one might judge ocaml a failure, for failing to inspire creative thought. But no, it has succeeded :-) -- John (Max) Skaller, mailto:skaller@maxtal.com.au 10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850 checkout Vyper http://Vyper.sourceforge.net download Interscript http://Interscript.sourceforge.net ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: to have labels or not 2000-04-04 6:53 ` Jacques Garrigue 2000-04-04 13:04 ` John Max Skaller @ 2000-04-04 16:39 ` Brian Rogoff 2000-04-05 16:02 ` Control inversion John Max Skaller 2000-04-06 13:43 ` to have labels or not Pierre Weis 1 sibling, 2 replies; 19+ messages in thread From: Brian Rogoff @ 2000-04-04 16:39 UTC (permalink / raw) To: Jacques Garrigue; +Cc: skaller, caml-list On Tue, 4 Apr 2000, Jacques Garrigue wrote: > From: Brian Rogoff <bpr@best.com> > > So I believe that having 2 modes was a rather natural first choice. > Now, if we realize after some time that this was not a good choice, it > will still be possible to change it for another approach. Of course > with a transition as painless as possible, and with the core language > preserved. John Skaller already answered your points, and anyways since having two libraries is in no way an elegant solution I'll leave it alone. I still think that having two modes makes it harder to explain OCaml and much harder for me to promote it in industry to my colleagues, which is my main concern. > > There just doesn't seem to be a good solution to this problem, i.e., one > > which will leave everyone happy. This is the human engineering part of > > programming language design, and since it appears a lot of Caml programmers > > find labels too heavy for their programming style I think we should go > > with the rule "When in doubt, leave it out". Out of the standard library > > that is. I'm not happy with this, as I prefer the labeled style, but it > > appears that the community is already somewhat split. > > Keep cool, we are not talking about divorce :-) I'm certainly trying to tread carefully, since I've noticed that this topic is rather inflammatory. Hopefully I wrote nothing offensive and if I did I apologize. > If we let conservatism decide on all subjects, there is no possible > progress. Are we going to have people to vote about what scientific > theories they like, or (more accurate) which novel writers should be > published and which not? Sure, but programming language design is unlike physics in that there is a strong human component which should not be suppressed. That's what I mean by "human engineering". And programming languages are like novels in that unpopular writers will have a harder time getting published and read than popular ones, so, in a sense, we do get to vote on who gets published, and more to the point, on which programming languages gain acceptance. It's also clear to me that there is rarely a unique solution to the problems raised by human engineering issues; witness how some large set of programmers really like indentation that matters (Haskell,Clean, Python, ...) while some hate it, and others can go either way. I should note that most functional programming languages are designed by people with a strong academic/theoretical bent, rather than an industrial bent, and so issues like the type system get a lot more attention IMO than human engineering issues. I think the Modula-3 book by Nelson had a nice section on the language design with the different types of designer given colorful names like "Lambdaman", "Hackwell", etc. FPs appear to be designed by entire teams of "Lambdamen". (OK, perhaps I'm being a little bit provocative here ;-) > P.S. > If I remember correctly, you asked a while ago about what would happen > of olabl polymorphic methods. > In fact, there is no progress since last Christmas, and I still view > it the same way. When 3.00 is released, I may start writing a > quick patch based on olabl code. If after a while I can come out with > something stable enough and that would not slow down the compiler, I > think there would be no specific problem in including it in the main > compiler. But I have no idea of when. > For the time being, either you have to stick to olabl 2.04, or find a > workaround without polymorphic methods. My experience is that for > most non-theoretical uses there are workarounds. Yes, that's my experience too with polymorphic methods. Still, I hope the OOP capabilities continue to expand, I've recently been looking at some problems where Eiffel style multiple inheritance with feature replication and renaming work nicely and the OCaml workarounds don't seem as nice. Hopefully Didier and Jerome are hard at work on it (and didn't take my jab at type theorists too seriously ;-). -- Brian ^ permalink raw reply [flat|nested] 19+ messages in thread
* Control inversion 2000-04-04 16:39 ` Brian Rogoff @ 2000-04-05 16:02 ` John Max Skaller 2000-04-06 13:43 ` to have labels or not Pierre Weis 1 sibling, 0 replies; 19+ messages in thread From: John Max Skaller @ 2000-04-05 16:02 UTC (permalink / raw) Cc: caml-list Given a 'functional/procedural' program which does blocking read operations, usually modelled by threading constructions, can we transform this program into one which operates entirely synchronously using callbacks from a message dispatcher (where the messages are the same data that the blocking read would have fetched? I call this process 'control inversion', because it turns master into slave, and vice versa: the read 'subroutine' called by the master algorithm, is turned inside out so that the code is executed by returning control, and then continuing via a callback (making the code a slave of the dispatcher). The requirements for control inversion are to save the state of the environment and point of control, and to restore the state, modified by the presence of the 'read' message, at the next point of control. With 'heavyweight' threads, function programs using the machine stack are control inverted by operating system level stack/register saving. With (ultra) lightweight threads, we cannot use the machine stack, except temporarily, so we must maintain a 'stack' manually, which is difficult to implement .. by hand. But it should not be so hard to add 'control inversion' to a bytecode machine. This has been done for Python (by Chritian Tismer, called Stackless Python). But it should also be possible for generated code. I have a clue that for Haskell, the notion of 'arrows' was invented to replace monads (these arrows correspond to arrows of categories) for just this purpose (the application here was thousands of concurrent interactive web sessions, where existing technology requires 'recording' the state between interactions in an extremely clubsy ad hoc (usually perlish) way. My application is different, but the requirements seem the same. I'm currently using ocaml to implement a simplistic language which provides 'automatic' control inversion (allowing programmers to write threaded programs instead of event driven ones). Unfortunately, the technique is to generate C++ code. I'd be very interested to hear more from those that know more about the inner workings of ocaml, whether there is a possible 'native' solution to this problem. I imagine this would require language constructions to specify threads (rather than just a library function call/calls). -- John (Max) Skaller, mailto:skaller@maxtal.com.au 10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850 checkout Vyper http://Vyper.sourceforge.net download Interscript http://Interscript.sourceforge.net ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: to have labels or not 2000-04-04 16:39 ` Brian Rogoff 2000-04-05 16:02 ` Control inversion John Max Skaller @ 2000-04-06 13:43 ` Pierre Weis 2000-04-06 16:33 ` Andrew Conway 1 sibling, 1 reply; 19+ messages in thread From: Pierre Weis @ 2000-04-06 13:43 UTC (permalink / raw) To: Brian Rogoff; +Cc: caml-list > I should note that most functional programming languages are > designed by people with a strong academic/theoretical bent, rather > than an industrial bent, and so issues like the type system get a > lot more attention IMO than human engineering issues. I think the > Modula-3 book by Nelson had a nice section on the language design > with the different types of designer given colorful names like > "Lambdaman", "Hackwell", etc. FPs appear to be designed by entire > teams of "Lambdamen". (OK, perhaps I'm being a little bit > provocative here ;-) You certainly are provocative, as far as the Caml team is concerned: we consistently insisted on practicability and usability of the language, writing theoretical articles on better handling of side-effects features, better design of modules to allow separate compilation, better compilation of floating point numbers and operations, etc; and then we implemented all those nice ideas into fairly usable compilers. Last but not least ``concession'' to praticability: this entire set of new basic types and operations for integers and big arrays... Best regards, -- Pierre Weis INRIA, Projet Cristal, http://pauillac.inria.fr/~weis ^ permalink raw reply [flat|nested] 19+ messages in thread
* RE: to have labels or not 2000-04-06 13:43 ` to have labels or not Pierre Weis @ 2000-04-06 16:33 ` Andrew Conway 0 siblings, 0 replies; 19+ messages in thread From: Andrew Conway @ 2000-04-06 16:33 UTC (permalink / raw) To: Pierre Weis, Brian Rogoff; +Cc: caml-list > > ... > > "Lambdaman", "Hackwell", etc. FPs appear to be designed by entire > > teams of "Lambdamen". (OK, perhaps I'm being a little bit > > provocative here ;-) > > You certainly are provocative, as far as the Caml team is concerned: > we consistently insisted on practicability and usability of the > language, ... I agree that the CAML team works really hard to make Caml practical. Indeed the reason that I chose CAML to work with over other languages was its pragmatism. It gave the impression of a "C" type language [no insult intended], with the help of a whole lot of experience in modern language design, to make a really good language. ^ permalink raw reply [flat|nested] 19+ messages in thread
* labels, Hash.create 2000-03-22 2:30 ` Markus Mottl 2000-03-23 0:57 ` Max Skaller @ 2000-03-28 1:04 ` Julian Assange 1 sibling, 0 replies; 19+ messages in thread From: Julian Assange @ 2000-03-28 1:04 UTC (permalink / raw) To: Markus Mottl; +Cc: Brian Rogoff, OCAML, proff In regards to backwards compatability, ocaml2.99+13 frequently refused to compile many 3rd party sources (compiled without -modern) which use: Hash.create n instead of Hash.create size:n ^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2000-04-09 23:28 UTC | newest] Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2000-03-17 19:30 to have labels or not Jan Brosius 2000-03-19 4:39 ` Brian Rogoff 2000-03-22 2:30 ` Markus Mottl 2000-03-23 0:57 ` Max Skaller 2000-03-23 3:46 ` Markus Mottl 2000-03-23 23:22 ` Max Skaller 2000-03-28 1:07 ` Julian Assange 2000-03-24 2:41 ` Jacques Garrigue 2000-03-25 3:12 ` Markus Mottl 2000-03-25 3:57 ` John Max Skaller 2000-03-29 20:32 ` Brian Rogoff 2000-03-30 9:56 ` John Max Skaller 2000-04-04 6:53 ` Jacques Garrigue 2000-04-04 13:04 ` John Max Skaller 2000-04-04 16:39 ` Brian Rogoff 2000-04-05 16:02 ` Control inversion John Max Skaller 2000-04-06 13:43 ` to have labels or not Pierre Weis 2000-04-06 16:33 ` Andrew Conway 2000-03-28 1:04 ` labels, Hash.create Julian Assange
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox