Re: [Caml-list] Width subtyping

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Monday 01 June 2009 10:21:36 am David Allsopp wrote: > Dario Teixeira wrote: > > Thanks -- that is also an interesting solution. I'm guessing it will > > be faster, though it might consume more memory in cases where only one > > field is actually

RE: [Caml-list] Width subtyping

Dario Teixeira wrote: > Thanks -- that is also an interesting solution. I'm guessing it will > be faster, though it might consume more memory in cases where only one > field is actually used. I'll have to try it side-by-side with the > object based solution to see how they compare in the real wor

Re: [Caml-list] Width subtyping

Hi, > If you're willing to give up some of the syntactic > niceties of records (and the ability to pattern-match) you > can get what you want using an abstract type. Thanks -- that is also an interesting solution. I'm guessing it will be faster, though it might consume more memory in cases wher

Re: [Caml-list] Width subtyping

On Sun, May 31, 2009 at 7:08 PM, Dario Teixeira wrote: > > I also meant "heavier" in terms of efficiency. And like David said, it > does > feel wrong to carry the performance penalty of the object system solely > because > I need the structural subtyping features. If you're willing to give up s

Re: [Caml-list] Width subtyping

From: Dave Benjamin > Heavier in terms of efficiency, or syntax? If you mean the latter, I > wonder if a camlp4 syntax extension might help ease the burden; perhaps > something like: > >#{x=5; y=6} > > could be translated to: > >object method x = 5 method y = 6 end > > and then you

RE: [Caml-list] Width subtyping

Hi, > > Heavier in terms of efficiency, or syntax? > > My concern is the former. The extra two fields per "record" and the heavier > runtime calls make them so systemically slower that (to me, at least) it > just feels "wrong" to use objects just to achieve a little syntactic clarity > and a smal

RE: [Caml-list] Width subtyping

> Dario Teixeira wrote: > > You are right. I was probably too fixated on the OOP way of doing this, > > translating record fields into object fields and the functions acting on > > records into object methods. Your solution, where record fields become > > object > > methods and external function

Re: [Caml-list] Width subtyping

Dario Teixeira wrote: Hi, There must be something that escapes me This seems to be an example where ocaml objects really shine because of the structural typing (i.e. an object is defined by the its structure): You are right. I was probably too fixated on the OOP way of doing this, transl

Re: [Caml-list] Width subtyping

Hi, > There must be something that escapes me This seems to be an > example where ocaml objects really shine because of the structural > typing (i.e. an object is defined by the its structure): You are right. I was probably too fixated on the OOP way of doing this, translating record fields

Re: [Caml-list] Width subtyping

There must be something that escapes me This seems to be an example where ocaml objects really shine because of the structural typing (i.e. an object is defined by the its structure): type t1 = type t2 = type t3 = let v1 : t1 = object method a = 1; method b

Re: [Caml-list] Width subtyping

Hi, > I've very tired at the moment, but I think that Garrigue's > polymap syntax extension does what you want: > > http://www.math.nagoya-u.ac.jp/~garrigue/code/ocaml.html > > If not, just ignore me! I should have suspected this discussion would eventually lead to something out of Jacques Gar

Re: [Caml-list] Width subtyping

Hi, > The dual of sums is products.  Open (labelled) sums > are "polymorphic variants".  Their duals are open > (labelled) products are "rows" (which O'Caml already > supports, through its objects). Yes, as I mentioned, for some classes of this particular problem the object system can be put to

RE: [Caml-list] Width subtyping

Hi, > This way you're always dealing with the same product type, > but the sum type tells you which fields are actually valid. > Of course, it relies on there being an obvious sentinel > value for unused fields (otherwise you just end up with 'a > option everywhere) and I still don't think it's t

Re: [Caml-list] Width subtyping

On Fri, May 29, 2009 at 07:10:12AM -0700, Dario Teixeira wrote: > type t1 = {a: int; b: int; c: int;} > type t2 = {a: int; b: int; c: int; d: int;} > type t3 = {b: int; c: int; d: int;} I've very tired at the moment, but I think that Garrigue's polymap syntax extension does what yo

RE: [Caml-list] Width subtyping

> Though it is probably been-there-done-that material for the veterans in > this list, for the sake of the not-so-veterans I have to ask: how do you guys > typically model width subtyping in Ocaml? Definitely not a veteran, but might private types help a little? > Consider for example three recor

Re: [Caml-list] Width subtyping

Dario Teixeira wrote: In other words, polymorphic variants provide a very elegant solution for subtyping with sum types. Is there some brilliant idea that could do the same for product types? The dual of sums is products. Open (labelled) sums are "polymorphic variants". Their duals are o

[Caml-list] Width subtyping

Hi, Though it is probably been-there-done-that material for the veterans in this list, for the sake of the not-so-veterans I have to ask: how do you guys typically model width subtyping in Ocaml? Consider for example three record types that share some of their fields: type t1 = {a: int; b: