Re: Joe-E

On 04/29/2010 03:13 PM, David Wagner wrote:
> 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?
>
>    
The issue was not that I couldn't do it with PowerlessArray, the issue was
that I couldn't write my own powerless generic types that use String. The
class I was more interested in was a PowerlessMap/Tree, but for the sake
of brevity I used the list which has the same issues.
> 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.
>
>    
Aha, that's useful to know. The method name with() was not what I was 
expecting and I didn't notice it.
> 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).
>
>    
Ugh!
>> 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.
>
>    
The only advantage is, as you say, performance related rather than 
semantic. I don't
think I meant to say it 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.
>    
Of course not. I wasn't trying to say that.
>>> 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?
>
>    
It appears to me that ConstArray uses .safej files to do its magic. I was
looking for a way to create powerless containers that didn't involve 
explicitly
marking things as safe inside safej files. I want to do this only for 
capabilities
I'm specifically enabling (CreateUser, DeleteUser, etc.).

The JoeE.isSubTypeOf() mechanism is not adequate for what I'm doing, as 
I have
to cast it to a known powerless type to avoid having JoeE flag an error. 
Hence,
as near as I can see, it is necessary to enumerate the types as I have done.
> 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.
>    
I did not think it was dismissive.
> 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).
>    
I assume this is with regard to my @Powerless suggestion.
Understood. We all have to get funding for what we do in some way.
> 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.
> _______________________________________________
> e-lang mailing list
> [email protected]
> http://www.eros-os.org/mailman/listinfo/e-lang
>