[Grace-core] A little bit of the String library

[Kim Bruce]

On May 21, 2011, at 8:48 AM, Andrew P. Black wrote:

> Folks,
> 
> While on a train, with a few hours to kill (and electricity!) I started writing a little bit of Grace code — a start at the String library — because I need more example code to test the parser.  My code is attached.
> 
> I almost immediately found that I was raising language design questions to which I didn't know the answers.
> 
> <Grace String.gce>
> 
> I'm defining a "StringTrait" object from which other objects will inherit.  Do we have a way of putting "abstract methods" in an object?  I used the (new) keyword "required" in place of a method body.   Should the whole object be explicitly flagged as abstract in some way, or if this inferred from the existence of required methods?  

I don't see any reason for having an abstract object.  For me objects are there because I want a singleton, which this can't be -- it's a "nulleton".  Moreover, I can't figure out any reason why an abstract object would be any different from an abstract class.  I believe we can write objects that extend a class (at least I want to be able to!), so it seems like a redundant notion.  Just have abstract classes.  ... and I would require that the word "abstract" or perhaps "incomplete" to be used on the class to signal that it can't be created, just inherited.

> 
> || for String concatenation?
> 
> I wanted to use // for integer division.  But we have already taken it to mean "comment".    Switch to "--" for comments?

Both fine for me, but we should try to lock these minor syntax points up fairly rapidly.

> 
> Can we say
> 
> 		const (a, b, c) := method that answers a tuple
> 
> I think that we have to allow this.  

That's the syntax I had in mind for this

> Are the parens necessary?  
> I think that
> 
> 		const a, b, c := method that answers a tuple
> 
> parses unambiguously, but maybe it's harder to read?

I think it is ambiguous to human readers -- does it mean assign the same value to all three const's or three different values.  I'd require the parens.

> 
> raise <exception object> for raising exceptions?  Or signal?  Or throw (I don't like throw, it makes me think of, well, I would rather not say.)

I like raise, but wouldn't object to signal.
> 
> I wanted an enumeration type TotalComparison = greater | less | equal. I defined it as three objects and a comprises clause.   This is a type issue, which we know that we haven't yet talked about.   Thoughts?

I had been thinking that greater, less, and equal would have to extend some other class or object, but it may be useful to have them implement TotalComparison type (but I'm not yet positive, see below).  I think that we want a little more behavior for these enumeration types, however.  For example, we might want to enumerate through them.

Scala does enumerations in a different way, e.g.:

-------------------------
object Main extends Application {

   object WeekDay extends Enumeration {
     type WeekDay = Value
     val Mon, Tue, Wed, Thu, Fri, Sat, Sun = Value      // Notice this is a multiple assignment, not tuple assignment
                                                                                             // evaluating Value magically adds a new unique value to the enumeration
   }
   import WeekDay._

   def isWorkingDay(d: WeekDay) = ! (d == Sat || d == Sun)

   WeekDay.values filter isWorkingDay foreach println
 }
 // output:
 // Mon
 // Tue
 // Wed
 // Thu
 // Fri

-------------------------------
I'm not a huge fan of that syntax (I'm not sure why you want the extra type def and Value is too magical), but you can see that it does allow ways of iterating through all the values in the enumerated type.  Is there a way we could do that with something closer to your syntax?

As I think through it, it seems like we might need TotalComparison to be an object that extends a library class Enumeration, which itself would be a class that would have an instance variable something like "valueSet" that we could iterate through.  While we could build this by hand, it might be nice to have it automatically built because of the word "comprises".  We would probably want a reasonable default for toString methods as well (though they could be easily defined in your object definitions).  

So, ... not a definitive answer yet .. just stream of consciousness weighing alternatives.

> 
> As yet, I haven't put any of these into the grammar.
> 
> 	Andrew
> 
> _______________________________________________
> Grace-core mailing list
> Grace-core at cecs.pdx.edu
> https://mailhost.cecs.pdx.edu/mailman/listinfo/grace-core