Re: Support of lists in PRD

On Sat, 11 Apr 2009 13:05:09 -0400
Sandro Hawke <> wrote:

> > > If so, would expect some kind of type/class constraints on these objects?
> > 
> > BLD does not have any kind of type constraints (or any kind of constraints 
> > at all).
> Indeed.  Michael, do you have an ideas for how to add/remove the kind of
> constraints the PRD folks want, between dialects?

I'd say, introduce types (through the front door).

> One relatively painless option is a builtin which does recursive
> type-checking on a list.
> I expect they want a violation to generate an error, though, not just be
> false, and want it to be somehow automatic.

I don't see how the builtin can help. In PRD they can add types as an extension.

> > > Can you construct a list?     Something like:
> > >          if p(?x) and q(?y)=20
> > >          then=20
> > >             create new list x : [?x ?y]
> > >             assert pq(x)
> > 
> > In PRD? I suppose yes.
> To cover both PRD and BLD, I guess we'd want an n-ary "func:list"
> constructor builtin.  In BLD you'd use it like this:
>             if p(?x) and q(?y) 
>             then pq(list(x,y))
> and I think there are corresponding ways to do it in Core and PRD.

I don't understand. The list proposal has an n-ary SEQ list construct (which
should have been probably called List instead).

> > > In terms of functions/operators (getFirst, ...) how does this look:
> > >
> > 
> > In BLD these functions are not needed, but they might be needed in PRD.
> They're not needed because they're easy to write, but there's no harm in
> providing them, is there?  (getFirst is trivial, of course, but reverse
> isn't something people want to write every time.)

of course, they can be provided. I just wanted to say that in BLD
they can be defined in the language itself, but in Core you can't
write all of them and be safe. For example, append cannot be defined by safe

    -- michael

Received on Saturday, 11 April 2009 23:09:16 UTC