[PRL] annoying types ARGH! -> structure-shy

[Pengcheng Wu]

On Thu, 12 May 2005, Karl Lieberherr wrote:

> And the point is that the details of the data model are not important,
> BOTH to the program and to the test input.

Well, sometimes, the details of the data model does matter. For example,
in your class structure, if each Shape object happens to have a back link
to the Compound object in which the Shape object is stored (this is a
common situation in programs), then your program may enter an infinite
loop and never terminates.

I would like to say this way: in the Adaptive Programming world, when one
writes a traversal strategy, she has to think carefully to which data
model this strategy will be applied, sometimes even including the details;
and the strength of Adaptive Programming is that when in situations
where the details are not important, the generator can automatically
generate traversal code, which otherwise will be tedious and error-prone.

--Pengcheng


> Consider this class dictionary:
>
> Compound = "(" <first> Shape <second> Shape ")".
> Shape : Simple | Compound.
> Simple : Rectangle | Circle common "ref" Point.
> Rectangle = "rectangle" "length" <length> int "width" <width> int.
> Circle = "circle" "radius" <radius> int.
>
> Point = <x> int <y> int.
>
> Both program and test cases also work for this class dictionary:
>
> Compound = "(" <elements> List(Shape) ")".
> Shape : Simple | Compound.
> Simple : Rectangle | Circle common "ref" Point.
> Rectangle = "rectangle" "length" <length> int "width" <width> int.
> Circle = "circle" "radius" <radius> int.
>
> Point = <x> int <y> int.
> List(S) ~ {S}.
>
> Matthias solution does not have this flexibility.
>
> -- Karl
>
>
> > -----Original Message-----
> > From: prl-bounces at lists.ccs.neu.edu
> [mailto:prl-bounces at lists.ccs.neu.edu]
> > On Behalf Of Matthias Felleisen
> > Sent: Thursday, September 01, 2005 9:43 AM
> > To: PRL Mailing List
> > Subject: [PRL] annoying types ARGH!
> >
> > I just wrote this little program for Karl:
> >
> > > type posn = float * float;;
> > >
> > > type shape =
> > >        Circle of posn * float
> > >      | Square of posn * float * float
> > >      | Union of shape * shape;;
> > >
> > > let distance((x1,y1),(x2,y2)) =
> > >     let dx = x1 -. x2 in
> > >     let dy = y1 -. y2 in
> > >       sqrt(dx *. dx +. dy *. dy)
> > >
> > > let rec inShape(s,p)  = match s with
> > >     Circle(c,r) -> distance(c,p) <= r
> > >   | Square(nw,width,height) -> false
> > >   | Union(top,bot) -> inShape(top,p) || inShape(bot,p);;
> >
> > Before I finished, I had_10_ type errors, one was real. Can you guess
> > what went wrong?
> >
> > Next I had one logical error, which would have launched anti-aircraft
> > rockets at anything remotely on the planet. (This is an excerpt from
> > the Hudak-documented DoD programming contest, reformulated a in A
> > Little Java for peaceful purposes :-)
> >
> > Yes, I am on record saying that I'd use OCAML if I worked in industry,
> > but boy this makes me reconsider this one.
> >
> > -- Matthias
> >
> >
> > _______________________________________________
> > PRL mailing list
> > PRL at lists.ccs.neu.edu
> > https://lists.ccs.neu.edu/bin/listinfo/prl
>
>
> _______________________________________________
> PRL mailing list
> PRL at lists.ccs.neu.edu
> https://lists.ccs.neu.edu/bin/listinfo/prl
>