Re: Joe-E

Steven R. Brandt wrote:
>On 04/29/2010 11:42 AM, David Wagner wrote:
>> Why not use org.joe_e.array.PowerlessArray?
>
> No, the point was that I wanted the ability to use String, and
> String (while powerless) does not implement Powerless and
> the code won't compile.

Hmm.  You should be able to use String with
org.joe_e.array.PowerlessArray.  Do you want to check again?

For example, something like this:

String[] ss = new String[] { "foo", "bar" };
PowerlessArray<String> a = PowerlessArray.array(ss);

> But I can't add to it in a convenient way.

See PowerlessArray.with(), which provides a convenient way to
append an item to the sequence represented by a PowerlessArray.

I could imagine introduce a PowerlessArray.push(), to insert the
item to the front.  To date there hasn't been anyone who has pushed
for that (heh).

> A powerless linked list is very useful, it
> is arguably the of the main data structure of Haskell (and with Joe-E
> you are sort of turning Java into a functional language).

Well, I wonder whether it's all that critical that it be a linked list
as opposed to some other representation.  I suspect a more precise
statement would be that a powerless ordered sequence is very useful;
whether it is represented as a linked list or an array seems like an
issue of representation (and performance) rather than semantics, and
I'm not sure why that would be fundamental.

Joe-E is its own language.  Joe-E is not intended as a functional language
in the spirit of Haskell.  And if you come to Joe-E thinking that you want
to write code just like you would in Haskell, you will be disappointed.
For instance, it's a goal of Joe-E to support immutable data structures,
to the extent needed for security, but Joe-E also supports many mutable
data structures as well.  As another example, Joe-E enables you to write
functions/methods that are verifiably pure, if you choose to do so,
but it does not try to push you in that direction or establish purity
as the default.  Moreover, don't expect the same level of support for
first-class higher-order functions.  If you try to think Haskell and
write Joe-E, you'll probably be disappointed.  Joe-E is primarily an
object-oriented language, not primarily a functional language.

Also, beware of another difference: Haskell has great support for
pattern matching, which combines very nicely with Haskell's syntax
for linked lists.  In Haskell, the syntactic convenience afforded by
these two mechanisms makes it a lot easier for programmers to just make
everything a linked list (whether or not that is the best representation).
Joe-E is different.  Joe-E has neither Haskell-like pattern matching,
nor Haskell-like syntax for linked lists.  So I suspect the question of
"linked list vs array vs something else" is going to be less relevant
in Joe-E.

>> Sure, and these would have to be added by hand.
>> Should we add an ImmutableHolder and a PowerlessHolder to the Joe-E
>> library, written along the lines of the ImmutableArray and PowerlessArray
>> implementation?  If so, do you want to propose some code?
> 
> That would be nice! My Holder class was in the email.

Thanks.  Before I'd consider advocating for adoption of your Holder,
I'd like to see the issues I raised fixed.  For example, rather
than hardcoding a few honorarily Powerless classes in the code of
Holder, I'd prefer to see it use a similar mechanism to that found in
org.joe_e.array.*Array, namely, using JoeE.isSubtypeOf(., Powerless.class)
to dynamically check that the element is powerless.  Have you looked at
the code in that package?

>>> The basic problem, I think, is that Powerless is a marker interface. If
>>> it were an attribute instead, then I think things would be nicer.
>>>      
>> Hmm.  I haven't thought about this, but I'm guessing one challenge
>> is that this would require re-implementing Java's type checks, so it
>> might take more work.
>
> It would definitely be tricky to get working, but I think it would
> be worthwhile.

By the way, as I re-read my response, I realize it might sound dismissive.
That wasn't my intent; sorry about that.  I agree that this is a
wart in the language, and it would be nice to have a good solution.
However this would be a non-trivial change and thus would require
some careful thought.  I have not thought through the design issues
or implications of this change.  In any case, given the status of the
project, we aren't likely to be able to consider these changes ourselves
(but if you end up looking at designing and implementing this, let us
know, and I'll try to provide feedback if I can).

That said, in the grand scheme of things, I think/hope this is a
relatively minor wart, and I suspect you should be able to make good
progress within the contraints of the existing language despite it.

> Maybe if that gains some recognition, it might lead to more development
> for Joe-E. Who knows?

That'd be great!  Good luck with your project.