Re: no names allowed, we serve types only

On Feb 17, 10:00 pm, Tegiri Nenashi <tegirinena..._at_gmail.com> wrote:
> On Feb 17, 11:36 am, Nilone <rea..._at_gmail.com> wrote:
> >
> > The operators in a typed system are based on inspecting and
> > manipulation the representation of values.  I don't see how anything
> > similar is possible in an untyped relational model.  There's
> > exhaustively generating all operands and results, which is
> > impractical.  With a successor operator defined (again,
> > exhaustively?), we can define plus inductively, which would be highly
> > inefficient.  Is there a way to define these operators without
> > resorting to hidden types or an actor-like model of delegating the
> > work to the operand?
>
> I'm not sure what hidden types or actor-like model of delegating the
> work to the operand, and why it is undesirable. Predicates such as
> "Plus" do have a set of functional dependencies, so why not to allow
> these dependencies be implemented in procedural language? These could
> be considered implementation details, pretty much as indexes belonging
> to physical layer of relational model. This idea is explored in
>
> http://vadimtropashko.wordpress.com/relational-programming-with-qbql/...

Thanks for the reference.

I don't have a problem with such a procedural implementation, but hiding the types you used to implement the system prevents the user from extending the model for their needs, unless they can drop down to the source code and recompile it, but then they can also break it. The ideal would be a system which is both adaptable and safe.

The actor-like model of delegating to the operand is bad because operands can override and implement behaviour as they choose. For example, you won't be able to guarantee that x + y = y + x, since y may be a user-created value in the domain of Plus which (improperly) overrides the logic for addition to concatenate the digits. Received on Thu Feb 18 2010 - 07:23:42 CET