[Grace-core] grace

[James Noble]

On 26/03/2013, at 06:06 AM, Philippe Kruchten wrote:

> Examples of what I had in mind:
> 
> "Boolean operators are written using && for and, || for or, and prefix ! for not"
> why not simply and , or and not ...?

OK yes. 
From my perspective, it's because people need to learn to read those C operators.
I guess the question is *when* they need to read them.

we could special case and && or the way we special case + and * I guess.

Libraries can provide .and and .or but they generally need to be parenthesized on the left.

> Lesson from Ada:
>     	is makes things easier to read thean nothing or : or ->
> 		type Bla is range 1 .. 5

hmm

> 	use of ' for attributes of soemthng
>    		 Bla'image
>    		 table'length  table'size   table'last

versus "."

>         optional parameter association
>  		   func ( param1 => 56, val => xyz)
> 	which in terms allows having default values for parameters, default values which are not necessarily constant.

our caller-side syntax will support this, but not (yet) our declaration side.
The question is complexity vs "power".
This makes the language more powerful but also adds more "implicit" 
behavior to message requests.

> 	Many of the discussions with the original Ada 1982 designer, jean Ichbiah, were about having superficial
>         syntax forms that would avoid ambiguity, limit errors, and make reading other peoples code easier.

which does all sounds good.
Are they documented in an HOPL paper or elsewere?

> Lesson from ABC and SETL
>          method calls without parenthesis
>  		Print myDoc on remotePrinter using twopageFormat
>                 same as  Print (waht => myDoc, on => remote_printer, using => twopageformat)
>  		same as Print (myDoc, remote_printer,  twopageformat)

yeah, we've been around and around on that. 

part of the issue is parsing this without type information:
how do you know whether "using" is the keyword or "twopageformat"

Smalltalk disambiguates with colons, we disambiguate with parens (or literals)

     Print (myDoc) on (remotePrinter) using (twopageFormat)

I'm very keen on code being really clear as to what is going on,
we could even teach students to parse and write ASTs.

Our (caller side) syntax is again nominally more flexible - although again we don't support this yet - in that we could allow boolean options as keywords

print (myDoc) doubleSided inColour 

   rather than

print (myDoc) doubleSided (true)  inColour (true) 

   (or even)

loop  {x := x + 1}  end  

where "end" would be a mandatory keyword.

> You will say: students write code, massage it until it works and then will never read it again... so what...

No, no, we won't...

James