|
|
Re: imperative, and functional, and oo, ...
|
Posted: Jul 11, 2007 7:46 AM
|
|
> > It's not that, really. It's the fact idea that
> different
> > programs or contexts could have different constraints
> for
> > the same base code. Rather than having, say, generics,
> > you could have a code that appears naked of type
> > annotations and add them on a context by context basis
> to
> > tighten up the checking. I'd imagine that if a
> language
> > was implemented this way, you'd probably want an IDE
> > option where you saw the annotations in the source
> > regardless of the fact that they are held elsewhere.
>
> I had considered that might be one of the goals. I didn't
> see it in your initial post though. I may have missed it.
> I agree that the IDE would definitely be a necessity.
> . I;m not sure if the code would be understandable in a
> large program, however, without it. Personally, I am wary
> of languages with source that cannot be easily read
> without an interpreting tool to the point of dismissing
> them, regardless of how robust the tooling may be.
The difference with this, though, is that the base language just looks like a dynamically typed language. It should be complete in the sense that you can imagine it executing and see the complete algorithm. The annotations in another file would really act as constraints which disallow certain conditions at compile or load time. They would not add functionality.
> Another concern would be whether this form of code reuse
> would actually be realizable. This idea seems reminiscent
> of AOP (which I'm not that familiar with) in one aspect.
> It also seems to be a lot like the basic ideas behind OO
> O design that are often not realized.
I wonder about the code reuse also. It may be that it is not realizable.
> > Beyond that, I think that there are other powerful
> things
> > that could be enabled by having a simple base language
> and
> > annotations held elsewhere. People could write their
> own
> > specific type rules, like, for instance, this class can
> > never be held as an instance of that class. Or, no
> class
> > in this package can have a dependency on a class in
> this
> > package. This blurs the line between testing and typing
> a
> > bit. You can programmatically add constraints on
> > particular methods or constraints on an entire program.
>
> All of this is very provocative and I don't mean to be
> dismissive of them. Have you made made any attempt to
> create such a language; perhaps as a mod on an existing
> one?
Unfortunately, no. Gilad Bracha wrote a while ago about "pluggable type systems" and there has been some research about them, but I haven't kept up. If I remember correctly, one of the systems is called JavaCOP and there was a paper at OOPSLA.
|
|
Previous Topic
