Re: First go at inferring type

Gah sorry, my e-mail got sent half-way.

Here's what I meant to write in the second-to-last part:

When determining the type of mapcar, instead of storing the above, it
would store something like

(lambda ()
  (unify-types '(-fn- (-list- t) ((-fn- t t) (-list- t)))
                    `(-fn- (-list- ,(get-return-type-of-arg1)
(,(get-type-of-arg1)
                                                                      
     ,(get-type-of-arg2))))))


The other problem I referred to is actually a bit far off. It goes
something like this:

If a program has both (mapcar 1+ '(1 2 3)) and (mapcar print '("hi" "bye"))
then the type of mapcar will be (-fn- nil ((-fn- nil (nil)) (-list- nil))).
That is, every argument and return value will have to be wrapped up in
a lisp-type variable. I guess one solution is not determining the type
of a function based on its usage. That means the type of mapcar will
remain
(-fn- (-list- t) ((-fn- t t) (-list- t))) and the compiler can emit
code for all possible argument types.

Yury

On 3/28/06, Yury Sulsky <[email protected]> wrote:
> Hi Ralf,
>
> > So the 't' in a type signature stands for an unknown *t*ype, rather
> > than *t*rue, right? Maybe another symbol would be better here to
> > avoid possible confusion.
>
> I actually was using true to represent unknown types. It works well as
> a special value in places like the -obj- type, since you obviously
> can't have a class called "t". Also it's kind of nice not to have to
> quote it everywhere.
>
> > Pretty cool that it already works for things like the mapcar-onelist
> > example. You have probably thought about this already: the inferred
> > type could be a little more general. You get (I substitute 'a' for 't')
> > (-fn- (-list- a) ((-fn- a a) (-list- a)))
> > whereas the result could be
> > (-fn- (-list- b) ((-fn- b a) (-list- a))).
>
> Right, that's what I'm working on right now. So when determining the
> type of mapcar, instead of storing the above, it would store something
> like
> (lambda ()
>
>    (unify-types '(-fn- (-list- a) ((-fn- a a) (-list- a)))
>                      `(-fn-
>
> The problem that I'm working on right now is taking (mapcar 1+ '(1 2
> 3)) to be of type (-list- (-int-)) instead of (-list- t).
>
> There's also the problem of what to do with under-determined function
> arguments/return values when it comes time to compile. Do we take
>
>
> like:
> (lambda () (unify-types current-type
>   (let ((code (-fn- (-list- a) ((-fn- a a) (-list- a)))
> >
> > btw, is there any good reason to have all the type keywords surrounded
> > by dashes? why not simply write (fn (list b) ((fn b a) (list a)))?
>
> Oh, no reason. I was just going along with -int- -float-, etc. This
> stuff is easy enough to change with a search & replace though.
>


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642