Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > enhance an array's static type by a lower length-bound.

Reply
Thread Tools

enhance an array's static type by a lower length-bound.

 
 
Andreas Leitgeb
Guest
Posts: n/a
 
      08-18-2011
Robert Klemme <(E-Mail Removed)> wrote:
> On 17.08.2011 17:04, Andreas Leitgeb wrote:
>> The point of the idea is, that array variables would be added a static
>> bit of information, namely a lower bound (0 by default) for the length
>> of an array that can legally be stored in that variable.
>> I believe such a change would be source-compatible, but might require
>> some severe changes at the bytecode/class-file-format level, to allow
>> to specify such a lower bound in a type signature. Such a change should
>> be possible in a way, that old class-files can still be used. e.g.:
>> get9th]10I)I (currently without bounds: get9th[I)I )
>> Methods could overload others just for different length-bounds.
>> The one with the largest provably satisfyable length-bound would be
>> chosen among those with otherwise matching signature.

>
> Not sure whether this would work - especially since binding of the
> signature occurs at compile time while you might only learn the real
> length of a parameter at runtime.


That was the point, that the resolution would still be at compile-time,
and based on the particular statically known length bound, not the actual
length.

e.g.:
void foo(int[] ia) { ... }
void foo(int[10] ia) { ... }
void foo(int[20] ia) { ... }
...
foo(new int[25]) -> third
int[5] ia = new int[15];
foo (ia ) -> first, not second!

That would be entirely consistent with

void foo (Object o) { ... }
void foo (List l) { ... }
void foo (ArrayList al) { ... }
...
foo ( new ArrayList() { ... } ) // (subclass of AL) -> 3rd.
Collection c = new Vector();
foo ( c ) -> calls first, not second.

> Also there is probably a whole lot of issues with java.lang.reflect.


Hmm, the Class-instances representing arrays e.g. for a call to
Class.getMethod() likely would need to be specific for each bound.
There'd need to be a way to get a class-object for, say, int[42].
May be tricky, but doesn't seem impossible to me.
If you know of a specific difficulty here, then I beg you to speak up!

>> Another one could be, that ArrayIndexOutOfBoundsExceptions are
>> not currently perceived as a problem that could be alleviated
>> by static checks, anyway.

> I think this is closer to the real reason why this is probably
> not such a good idea.


I don't refute this. I just like to principially think it through,
anyway. Maybe until some show-stopper "that can't ever work" is
brought up.

> What you propose would be useful only if the added
> property of arrays would allow for *compile time* checking -

Well, that's the intention behind it - to some degree.

> because Java has runtime checks already. For compile time checks to be
> reasonable you would need to forbid
> int[] a1 = expr;
> int[10] a2 = a1;


I wrote that in my original post, already. It requires an explicit
cast in the second line, and the cast would mean that a runtime check
on the length occurs. Principially the same story as with object-type
casts.

> because depending on the complexity of expr it might not be possible for
> the compiler to determine the guaranteed min length of a1.


The guaranteed min length of a1 is 0 - because the brackets are empty.

> I have the feeling that
> people would use this as a lazy shortcut for defining a class with n
> integer fields.


That would be an admittedly entirely unwanted dead giveaway, but just
like the imbalance of cost vs practical applicability, I'd like to
keep that out of the technical discussion. It would be relevant, if
it was intended as a serious proposal, but that isn't the case here.

 
Reply With Quote
 
 
 
 
Roedy Green
Guest
Posts: n/a
 
      08-19-2011
On 18 Aug 2011 18:08:47 GMT, Andreas Leitgeb
<(E-Mail Removed)> wrote, quoted or indirectly quoted
someone who said :

>That should/could be compiler's job.


If you are the only person who has this problem, then it should
definitely not be the compiler's job. You can't put features in
languages unless 99% of programmers can understand them. That rules
out quite number of esoteric ideas.

I exaggerate somewhat, but designing computer languages is a bit like
designing control panels for elevators. They have to be obvious.

Your idea is not as hairy as generics, but it is not something that
can be understood even with two readings.

--
Roedy Green Canadian Mind Products
http://mindprod.com
The modern conservative is engaged in one of man's oldest exercises in moral philosophy; that is,
the search for a superior moral justification for selfishness.
~ John Kenneth Galbraith (born: 1908-10-15 died: 2006-04-29 at age: 97)
 
Reply With Quote
 
 
 
 
Joshua Cranmer
Guest
Posts: n/a
 
      08-19-2011
On 8/18/2011 1:12 PM, Andreas Leitgeb wrote:
> Joshua Cranmer<(E-Mail Removed)> wrote:
>> I was actually referring to class file annotations, not Java annotations.

>
> They are called "annotations", too? I thought, they were called "attributes".


I'm running off of my memory here, so I could have been wrong.

--
Beware of bugs in the above code; I have only proved it correct, not
tried it. -- Donald E. Knuth
 
Reply With Quote
 
Andreas Leitgeb
Guest
Posts: n/a
 
      08-20-2011
Robert Klemme <(E-Mail Removed)> wrote:
> On 18.08.2011 23:44, Andreas Leitgeb wrote:
>> e.g.:
>> void foo(int[] ia) { ... }
>> void foo(int[10] ia) { ... }
>> void foo(int[20] ia) { ... }

> How likely is it that you want to have vastly different implementations
> of foo() with different array lenghts?


Very unlikely (see later in this posting about benefits)

>> Hmm, the Class-instances representing arrays e.g. for a call to
>> Class.getMethod() likely would need to be specific for each bound.
>> There'd need to be a way to get a class-object for, say, int[42].
>> May be tricky, but doesn't seem impossible to me.
>> If you know of a specific difficulty here, then I beg you to speak up!

> As far as I can see you would need a Class instance for every
> combination of base type and min length. Plus you would need to ensure
> that type compatibility check methods return the appropriate boolean
> values.

So far so good.
> If you try to make them inherit (i.e. int[4] "is a" int[3]) things get
> really crazy because int[4] is also an int[2] and int[1] and int[0].
> That doesn't fit Java's inheritance model well. Now if you only have
> int[4] and int[1] in the system the superclass of int[4] would be
> different than if you also had int[2] in the system. Now add dynamic
> class loading into the mix...


If, for using (say) int[4200000], the JVM would really need all the
4200000 other array-"superclasses" in memory at once, then this might
just be one such show-stopper that I searched for. Thanks

Maybe it could be fixed with some special case, where the superclasses
of a bounded array-class do not really need to be in memory, but this
would surely require a much deeper change than what I anticipated for it.


>>> What you propose would be useful only if the added
>>> property of arrays would allow for *compile time* checking -

>> Well, that's the intention behind it - to some degree.

> Why only to "some degree"? Compile time type safety would be the only
> benefit compared to the current situation. We do have runtime checks
> already.


"To some degree":
The compiler would only check assignment to bounded arrays. (including
the assignment that kind-of-happens to the formal parameters of the called
method)

Thus, the compiler could make sure, that a method taking a bounded array
would never get called with a smaller one (but could still get null, btw).

The compiler would however *not* check the particular indexing operations,
(therefore I wrote: "to some degree") as the array might be larger and
indices higher than the lower bound might just be legal.

> Why do you want to keep that out of the discussion? When considering
> technical solutions evaluating cost vs. benefit is always an important
> part of the evaluation.


Sometimes these two aspects are evaluated separately. The benefit has
already been evaluated as near-zero, because most arrays in practical
use (those used internally for certain collections) just do not benefit
from a lower bound on length.
The only usecases so far were algorithms on arrays that require a
particular minimum length (such as obtaining the mean value), and
the anti-pattern of mis-using arrays to store separate fields.

Now, I'm evaluating the cost, and it is already higher than what I
expected (due to the JVM requiring complete chains of classes up to
Object).
The quest to find further costs would be less verbose, if the
question about benefit weren't always re-raised.

> I think it's clear that what you propose can be solved technically -


There's changes that (would) take a straight-forward effort to implement,
and there are changes that require some kind of wider refactoring. I'm
curious about the latter ones that would be necessary for implementing
that pseudo-proposal. Just for the sake of the discussion, actually,
as I already pointed out in the first post of this thread.

 
Reply With Quote
 
Andreas Leitgeb
Guest
Posts: n/a
 
      08-20-2011
Roedy Green <(E-Mail Removed)> wrote:
> On 18 Aug 2011 18:08:47 GMT, Andreas Leitgeb wrote:
>> That should/could be compiler's job.

> If you are the only person who has this problem, then it should
> definitely not be the compiler's job. You can't put features in
> languages unless 99% of programmers can understand them. That rules
> out quite number of esoteric ideas.


I entirely agree with you. However, if you didn't really read the
first few lines of the original post, then you're probably just
wasting your time if you read or answer the other posts of this
thread. (You're of course free to do just that - namely waste your
time - if you're in that mood

This thread is neither about a problem to be solved, nor about a
serious proposal for Java - despite certain formulations (picked
out of the context) may make it seem like it was.

 
Reply With Quote
 
Lew
Guest
Posts: n/a
 
      08-20-2011
Andreas Leitgeb wrote:
> Roedy Green wrote:
>> Andreas Leitgeb wrote:
>>> That should/could be compiler's job.

>> If you are the only person who has this problem, then it should
>> definitely not be the compiler's job. You can't put features in
>> languages unless 99% of programmers can understand them. That rules
>> out quite number of esoteric ideas.

>
> I entirely agree with you. However, if you didn't really read the
> first few lines of the original post, then you're probably just
> wasting your time if you read or answer the other posts of this
> thread. (You're of course free to do just that - namely waste your
> time - if you're in that mood
>
> This thread is neither about a problem to be solved, nor about a
> serious proposal for Java - despite certain formulations (picked
> out of the context) may make it seem like it was.


Discussions like this one are incredibly valuable for the evolution of the Java language, and for computer languages in general.

--
Lew
 
Reply With Quote
 
Robert Klemme
Guest
Posts: n/a
 
      08-21-2011
On 20.08.2011 19:50, Lew wrote:
> Andreas Leitgeb wrote:
>> Roedy Green wrote:
>>> Andreas Leitgeb wrote:
>>>> That should/could be compiler's job.
>>> If you are the only person who has this problem, then it should
>>> definitely not be the compiler's job. You can't put features in
>>> languages unless 99% of programmers can understand them. That
>>> rules out quite number of esoteric ideas.

>>
>> I entirely agree with you. However, if you didn't really read the
>> first few lines of the original post, then you're probably just
>> wasting your time if you read or answer the other posts of this
>> thread. (You're of course free to do just that - namely waste your
>> time - if you're in that mood
>>
>> This thread is neither about a problem to be solved, nor about a
>> serious proposal for Java - despite certain formulations (picked
>> out of the context) may make it seem like it was.

>
> Discussions like this one are incredibly valuable for the evolution
> of the Java language, and for computer languages in general.


.... and probably also for the understanding of programming languages.

Cheers

robert

--
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/
 
Reply With Quote
 
Michal Kleczek
Guest
Posts: n/a
 
      08-21-2011
On 2011-08-18 15:34, Patricia Shanahan wrote:
>
> I don't think I've ever seen a language with dynamic array creation that
> has a lower bound on the length of an array a variable can reference.
> I'm not sure how it would work, or how I would use it.
>


Wouldn't any language with dependent typing have it? There are some
academic languages implementing it (actually parts of since such
typechecking is undecidable).

--
Michal
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
upper and lower case static color names in Color ChrisC Java 2 08-23-2007 02:30 AM
Enhance security in big cisco switched network grzybek Cisco 0 05-30-2005 08:55 AM
Something to "enhance" a zoomed in image? Colin Computer Support 5 12-05-2004 02:17 PM
how to enhance the jtidy performance?!......any idea mike Java 0 08-17-2004 04:37 PM
Good image Auto enhance software DonB Digital Photography 0 08-31-2003 02:54 AM



Advertisments