From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: ** X-Spam-Status: No, score=2.0 required=5.0 tests=DNS_FROM_SECURITYSAGE autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by yquem.inria.fr (Postfix) with ESMTP id 46B45BBAF for ; Tue, 4 Nov 2008 23:35:21 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj0BAGpdEEnUnw6Rgmdsb2JhbACCRZFSAQELCwgHEwS3SINT X-IronPort-AV: E=Sophos;i="4.33,545,1220220000"; d="scan'208";a="18859384" Received: from ptb-relay01.plus.net ([212.159.14.145]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/AES256-SHA; 04 Nov 2008 23:34:49 +0100 Received: from [87.115.78.230] (helo=leper.local) by ptb-relay01.plus.net with esmtp (Exim) id 1KxUU3-0000Q0-KT for caml-list@yquem.inria.fr; Tue, 04 Nov 2008 22:34:48 +0000 From: Jon Harrop Organization: Flying Frog Consultancy Ltd. To: caml-list@yquem.inria.fr Subject: Re: [Caml-list] What does Jane Street use/want for an IDE? What about you? Date: Tue, 4 Nov 2008 23:36:48 +0000 User-Agent: KMail/1.9.9 References: <200810200919.41561.ober.14@osu.edu> <200811032311.33989.jon@ffconsultancy.com> <200811041335.46897.ober.14@osu.edu> In-Reply-To: <200811041335.46897.ober.14@osu.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200811042336.48392.jon@ffconsultancy.com> X-Plusnet-Relay: 06393b43d1c3119ad1fe78d28fc367b8 X-Spam: no; 0.00; ocaml:01 bindings:01 ocaml:01 bindings:01 ocaml's:01 iirc:01 lacks:01 callbacks:01 gtk:01 parser:01 cpp:01 parser:01 doable:01 gtk:01 reimplement:01 On Tuesday 04 November 2008 18:35:45 Kuba Ober wrote: > On Monday 03 November 2008, Jon Harrop wrote: > > On Monday 03 November 2008 14:15:38 Kuba Ober wrote: > > > I could port Camelia to OCaml if > > > someone would first develop Qt bindings for OCaml that would allow me > > > to do in OCaml what I'm doing in C++ so far ;) > > > > That may already be possible if you go via more mainstream dynamic > > languages like Python. However, python-qt4-dev has fewer installs on > > Debian and Ubuntu than OCaml does, so you may well find that the Python > > bindings are inadequate as well. > > Python Qt bindings are pretty much feature-complete, but C++'s class syst= em > maps perhaps better to Python/LISP than to OCaml? You'll just be invoking autogenerated Python code using OCaml so OCaml's cl= ass=20 system is only relevant if you want to do some fancy statically-typed shim.= =20 I'd forget about that and just focus on making the whole of Qt4 available=20 safely from OCaml in any form first. Even this is an unsolved problem in th= e=20 OCaml world! > > > That's an undertaking bigger than Camelia itself. I will not develop > > > for gtk-anything as lost feature parity with Qt right around the time > > > when Qt 3 came around, IIRC. > > > > I can well believe that. Another option is to create a new GUI toolkit > > from scratch in OCaml. > > Since Camelia uses so much of Qt's functionality, this is a task on par > with reimplementing Qt. Good luck with that ;) =46rom Qt4's architecture diagram: http://trolltech.com/images/template/product-architecture-diagram-collaps= ed Core, GUI, database, scripting, network, OpenGL, XML, Multimedia, Font=20 Engine and Webkit Of those, only core and GUI might be relevant here but the core lacks=20 first-class functions for events and callbacks and the GUI is unable to=20 express integrated graphics (e.g. OpenGL layers). So the amount of Qt that is objectively beneficial is tiny and the cost of= =20 using it is very high. > > > Qt 4 is leaps and bounds above anything gtk provides, in > > > terms of integrated functionality. This is not meant as a flamebait, I > > > believe it to be an accurate statement of fact. > > > > And WPF is leaps and bounds above anything Qt 4 provides, in terms of > > functionality, integration and performance. Combined with the fact that > > using Qt4 from a decent language is very hard and basically completely > > pointless by design anyway, I think there is a strong argument for > > starting from scratch. > > WPF is just another thing, and it's not really portable in any decent sen= se > of the word. Sure. My point is that you're building on antique technology when you could= be=20 building modern technology instead. > Camelia could be run on a 486 system with perhaps 64MB of=20 > memory when compiled using Qt/Embedded. While one can question whether it= 's > useful or not, Qt has the benefit of targeting all major computing > platforms out there. That sales hype for Qt is just a reflection of the fact that Qt was built o= n=20 sand using a dying technology (C++). In practice, the world moved on to=20 garbage collected virtual machines for GUI programming years ago. Qt was le= ft=20 behind and is desperately trying to catch up by migrating to the JVM but th= e=20 JVM is now dying... > Using Qt4 in a decent language will be easy once there is a C++ parser in > said decent language. You'll be Greenspunning managed C++ from the .NET world. That's a fine idea= if=20 you regard Qt as useful legacy code but I don't see the point myself. Qt wi= ll=20 always have a stone-age API and reimplementing managed C++ is a huge=20 undertaking. In contrast, you can implement a GUI toolkit in OCaml that far exceeds the= =20 relevant limitations of Qt4 with quite easily. > I don't know if I mentioned it, but some time ago I=20 > did a proof-of-concept of machine-translating QObject.cpp and friends to > LISP and it not only worked, but required no moc ;) So I'd say that as so= on > as there's a good-enough C++ parser written in OCaml, and given > availability of a basic AI package (to implement a KB and searches), it > should be perfectly doable to translate Qt4 into human-readable, > not-too-bad OCaml. Then the question is simply whether it is easier to write a C++ parser in=20 OCaml along with the translation code and a sane shim over the whole of Qt4= =20 or just replace it wholesale. > > > I wish I could use gtk > > > since it's easier to bind with, but I'd end up having to either > > > reimplement parts of Qt, or have to deal with lots of 3rd party > > > libraries, each from a different author who had a different API design > > > mindset. Qt takes care of those integration issues internally and > > > provides a relatively > > > self-consistent API -- this saves a metric crapton of time (I use the > > > darn thing). > > > > Swings and roundabouts. The metric crapton of time you save with Qt4's > > functionality is paid by having to use an awful language. > > Let's not flame about it, I would not regard that as flame bait here. I'm sure if OCaml had decent Qt= =20 bindings they would be very heavily used indeed (the OCaml language would=20 excel at GUI programming, which is precisely why so many people here are=20 yearning for such bindings) but Qt4 is nowhere near useful enough to make m= e=20 want to go back to C++ or any language that does have Qt bindings. =46rom what I've heard, a lot of OCaml programming use OpenGL for GUI=20 programming instead of GUI toolkits. > but as a pure exercise I have implemented=20 > everything (as in all presented algorithms/approacheds) for three "major" > courses from www.osu.edu (MATH707/727, CSE630 and CSE680), in LISP, OCaml > and C++. The code in each case has similar readability and uses similarly > high-level concepts. I'd say that if you think in OCaml or LISP and > implement in C++, you can still get pretty good code ;) Of course some > LISP/OCaml-isms are unavailable in C++, but then some other ones can be > implemented with relative cleanliness using available template > metaprogramming. I've no idea what those exercises where but get your OCaml code peer review= ed=20 here before drawing a conclusion. There are very few tasks where C++ is=20 competitively comprehensible. > > > > . Graphical throwback of the documentation related to what is under > > > > the mouse pointer. > > > > > > Easy to do -- goes on my to-do list. > > > > How would you implement it? > > 1. Everything has type annotations. > 2. I know scope of symbols from my simple parser. > > It's easy enough to look things up by name+context and type, right? You require the programmer to write type annotations everywhere? > > > > . Graphical throwback of errors and, in the case of type errors, > > > > optional highlighting of previous unification points. > > > > > > Camelia does that. > > > > Cool. AFAIK, OCaml does not export information about unification points. > > So how do you get hold of that data in Camelia? > > I was probably wrong about unification points. What are they? The points in the program where the type checker unified two or more types = in=20 order to check type correctness, e.g. the two branches of an "if" expressio= n. When the programmer makes a mistake, the type checker can be misled early i= n=20 the code but report an actual type error later in the code. So it can be=20 helpful (particularly for newbies) to see where the type checker unified=20 because the error will almost certainly have been at one of those points. =46or example, a function to sum a list of floats: let rec sum =3D function | [] -> 0 | h::t -> h +. sum t The type error is reported at the "+." operator because the type was=20 incorrectly inferred to be "int" when the type checker came across the "0" = in=20 the first clause. Highlighting the unification points of that type=20 immediately leads the programmer to the point of error. Without this, the=20 programmer has no idea where the error really is. > > > > . Parallel so seven of my cores aren't idle while I'm waiting. > > > > > > Everything is done in one thread right now, but over time it can be > > > spread out. Implementing this properly requires refectoring of the co= de > > > first: right now Camelia is in no shape to attempt that. After 2.0 > > > release there will be time to attack that. > > > > It is trivial if you can pull the sources of the OCaml compiler into yo= ur > > IDE and if OCaml has a parallel GC. ;-) > > Doing even that requires a lot of refactoring. Camelia 1.1 had its OCaml- > awareness spread about everywhere, so before anything major happens I had > to get all language-specific stuff abstracted out anyway. I'm in the > process of doing that. If you want your IDE to support multiple languages, yes. My preference woul= d=20 be to write an IDE specifically for OCaml first. > > It is a logical progression from building your own GUI toolkit. You > > represent graphics using scene graphs. Everything in an interactive > > session is converted into scene graphs for rendering. > > > > So: > > > > val pretty_printer : Expr.t -> string > > > > becomes: > > > > val pretty_printer : Expr.t -> Scene.t > > > > and the resulting Scene.t is fed through a renderer like Smoke. > > 1. How exactly do you see the pretty_printer rendering things? Easiest for me to answer by just posting our code. Here is the code from th= e=20 current version of Smoke that typesets paragraphs of text by overflowing=20 words onto new lines: let rec charsmap =3D function | 'f' :: 'f' :: 'i' :: t -> (`CMR, 177) :: charsmap t | 'f' :: 'f' :: 'l' :: t -> (`CMR, 178) :: charsmap t | 'f' :: 'f' :: t -> (`CMR, 174) :: charsmap t | 'f' :: 'i' :: t -> (`CMR, 175) :: charsmap t | 'f' :: 'l' :: t -> (`CMR, 176) :: charsmap t | c :: t -> charmap c :: charsmap t | [] -> [] let word string =3D let string =3D charsmap(list_of_string string) in let aux x (font1, c1) (font2, c2) =3D let contours =3D Cmfont.glyph font1 c1 in let contours =3D List.map Contour.make contours in let g =3D List.map (Contour.trans (translate x 0.)) contours in let advance =3D if font1=3Dfont2 then Cmfont.advance font1 c1 c2 else Cmfont.advance `CMR 32 32 in x +. advance, g in let rec aux2 x =3D function | [] -> [] | h1::t -> let h2 =3D match t with h2::_ -> h2 | _ -> `CMR, 32 in let x, g =3D aux x h1 h2 in g :: aux2 x t in aux2 0. string |> List.concat |> ContourGeometry.of_contours let word =3D memoize (fun _ -> word) let paragraph ~skip ~justify ~width ~string =3D let words =3D List.map word (String.split ' ' string) in > 2. How easy it is to replace pretty_printer built into OCaml? Already trivial: $ ocaml Objective Caml version 3.10.2 # 3.4;; =2D : float =3D 3.4 # open Format;; # let print_float ff x =3D fprintf ff "%0.20f" x;; val print_float : Format.formatter -> float -> unit =3D # #install_printer print_float;; # 3.4;; =2D : float =3D 3.39999999999999991118 However, I'd rather OCaml carried run-time type information and the pretty= =20 printer associated run-time types with typesetting functions. > I presume that the running OCaml instance (toplevel) would > dump scene graphs, and then a separate OCaml instance would > take those and render them? I would just replace the backend of the current top-level to generate graph= ics=20 instead of text. > > > Processing toplevel output is an issue nicely orthogonal to editor and > > > knowledgebase, so this doesn't block on the major refactoring that has > > > to happen on the editor end. > > > > Yes and no. I assume your editor is completely hard-wired from the grou= nd > > up for editing plain text and maybe even unicode but is completely > > incapable of rendering arbitrary vector graphics. If so, it will need to > > be completely gutted. > > Well, the thing about toplevel is that it's completely separate from the > actual source editor. In the current design, yes. > So I can actually replace toplevel at any time by simply substituting a > different widget for it. The toplevel widget talks to a wrapper around the > real OCaml process, which would be re-used. You really want to preserve information (e.g. types) in the graphical outpu= t=20 for throwback to work so I would go for tighter integration of the top-leve= l=20 and IDE. =2D-=20 Dr Jon Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?e