Re: F#

Rainer Joswig schrieb:
Going back to your list, I find that:
* run-time checking still isn't necessary, though you'd have integration-time type checking (unavoidable);
* late binding is irrelevant to the discussion anyway, you can have it in dynamic or static languages;

Generally it is not irrelevant, since it is a huge difference
what is done by default (late binding or not).

It's relevant for architecture, but it's not too different for efficiency or coding flexibility.

* class changing: not done, no overhead here;
* data layout changes: not needed, no overhead again.

Is that assessment correct?
Does the "convert the data" approach incur problems in areas that I haven't addressed?

I think you give not enough information about what you want to
achieve.

Combine the post-installation flexibility of dynamic languages with static typing.

> Do you want to be able to change data types in
running programs and have a mechanism that deals with the
effects?

Yes.

> What kind of type system?

Static, with generics and at least enough type inference that you don't need to write more type declarations except on external interfaces.

It can't be fully static, of course, since it's unknown in advance what code will be installed. So it would be installation-time type checking. (It's really going beyond "just types", but that's a different story: it broadens the scope of guarantees that you get out of the system, but it doesn't change the problem definition much.)

> What would those changes to data types be?

I'd say it would be extensions to existing types. Old interfaces go into oblivion once they become unreachable, so you can't simply delete a field until the last code that uses it is gone.

> How can you define a conversion and have it type-checked?

Code that expects the old type would get to see a converted value/object (possibly via a wrapper, possibly on-the-fly conversion, possibly a stop-the-world-and-convert-everything conversion).
Whatever the mechanism, you can make sure that code that expects the old type either gets to see the old type, or doesn't exist anymore.

> I would guess that stuff like this
has been discussed in research.

I have seen some research papers on the subject, but most concentrated on the mechanis of an upgrade - not that that would be irrelevant, but there's a definitive lack of papers on the semantics.
E.g. how to preserve identity across an upgrade. And what does it mean to have such an identity (since you can't simply compare fields anymore - I suspect that the concept of identity isn't as clearcut as many people think, at least not when you try to define it axiomatically).

Regards,
Jo
.

Relevant Pages

  • Re: DTS to SSIS lost functionality
    ... have to manually change the data types for all the cols. ... the Field type conversion problems. ... What we found solves all of those problem is to ALWAYS use the wizard to ... We even find that if we create a package with the wizard and then need to ...
    (microsoft.public.sqlserver.dts)
  • Re: problem while receiving negative integer in microblaze
    ... and it should be converted SLV while transferring... ... I don't know that your problem is one of converting data types. ... signals. ... there really is no conversion. ...
    (comp.arch.fpga)
  • Re: What happens after runtime?
    ... E.g. when you add webcontrols to your markup in the designer, ... when you add controls dynamically while the app is actually ... I learnt the term "late binding" from a book which I am using to learn ... runtime but then variables of other data types are also not processed ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: Saw palmetto vs Testosterone
    ... but T has much better binding then ... Deca, and has more conversion to E, but the binding, compared to T, is still ... As for 'funny' "trolls", well we did have Robert Dorf (aka Bob Tokyo, ... We mostly had nasty "trolls" like John Williams, ...
    (misc.fitness.weights)
  • Re: Option Strict
    ... Data types are important, moreso as the bigger and more ... > Option Strict also "disallows late binding". ... > all objects must know their type at design time, because of this, the ...
    (microsoft.public.dotnet.framework.aspnet)