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

[Karl Lieberherr]

Here is my partial program that I wrote for Matthias for the same "free
variable-like problem" that Matthias solved.

class Compound {
int countHits(final Point p) {
   Integer res = (Integer)
   Main.cg.traverse(this,"from Compound to Simple", new Visitor(){
        int containedIn;
        public void start() {containedIn = 0;}
        public void before(Simple host){if (host.contains(p))
containedIn++ ;};
        public Object getReturnValue() {return new
Integer(containedIn);}
   });
   return res.intValue();
};
}

class Simple {
boolean contains(Point p) {
  return true;
     }
}

Here is a sample input

(
  ( rectangle length 7 width 9 ref 3 4
    circle radius 9 ref 6 7)
  ( circle radius 10 ref 8 3
    rectangle length 4 width 6 ref 5 1 )
)

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

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