[Grace-core] Syntax questions

[Andrew P. Black]

Here is my take on these questions.

On 8 Nov 2010, at 17:39, Kim Bruce wrote:

> My student Eric (copied on this message) is starting to write Grace code, but we have not nailed down some of the specific syntax yet.  Here are some questions and proposed answers:
> 
> 
> 1. How do we write function types?     S => T  or S -> T
> 	Proposed answer: S => T  (like Scala)

	  I don't see why we don't use →, which has been the standard symbol for function types for many years.   I'm happy for Eric to keyboard this as ->


> 2.  How do we write anonymous n-ary functions?  (x:S,...) => {...}    or    {(x:S,...) => ...}  
> 	Proposed answer: (x:S,...) => {...} 
> 	Default abbreviation:  0-ary functions can be written as () => {...} or in the abbreviated form {...}

I'm assuming that you mean objects with an apply method of the appropriate arity, not functions.   The => notation, or better yet, ⇒, is fine with me.  


> 3.  Pattern matching notation:  myExp match {case ... => ...; ...}    or    match myExp {case ... => ...; ...}
> 	No strong feelings.  The first is Scala syntax.

I would rather that pattern matching is just one way of generating a boolean.

	case
		someBoolean ⇒ someExpression
		anotherBoolean ⇒ anotherExpression
		otherwise ⇒ defaultExpression

So your example would need to be written

	case 
		myExp ~ pattern1 ⇒ …
		myExp ~ pattern2 ⇒ …

I'm OK with ~ setting up bindings that are valid after the ⇒

> 
> 4.  Built-in simple IO:  how do we write simple reads and writes?  We could have a default system I/O object, io, that is visible anywhere and then write output as either:   io.printline(s) or s.printline(io).  Similarly with print, read, readline.
> 	Are you OK with these names, and which order should we write them?
> 	Proposed answer: io.printline(s) as that makes it easier to read if we construct complex strings to print.

As someone said during the panel, line printers are obsolete.  I would rather that the verb we use for the message be display or show, because the default will be to display or show on a screen.  For input, I suggest a method ask(promptString).

The object that these messages are sent to should indeed be globally visible.   I suggest Prompter for input and Script for output.  However, Script does make me think of a rolling typescript.  We shouldn't use Display, because we should reserve that for the main Display.  How about Notifier, where Notifier.new creates and pops up a new (empty) notifier window on the Display, which can then be written to using show messages.  We can also have Notifier.display("a text string") that creates a new Notifer window containing the given string.

So your examples would be

	let response = Prompter.ask("Do you want to play again?")
	case
		response ~ "[Yy]es.*" ⇒ game.again
		response ~ "[Nn]o.*" ⇒ Script.show("Goodbye, thanks for playing\n")
		otherwise ⇒ Notifier.display("Sorry, I didn't understand your answer\n")

Incidentally, Smalltalk started out with a whole bunch of well-known globals, like Transcript, Smalltalk, Sensor, Display, etc.  Over time, people realized that this wasn't very elegant.  The modern trend is to reserve globals to refer to classes, and to use the singleton pattern.

So instead, we would use (in Grace notation) Transcript.default, or Sensor.uniqueInstance, to refer to these objects.  


> 
> I'm still concerned about our numeric types.  See comments on the wiki in the Built-In Types section.  However, if we could just clear these questions up rather quickly, then Eric can make some progress.
> 

Of course, Prompter should probably understand other message, in addition to ask, like a message that takes a menu of patterns and corresponding blocks to execute, but that is in part for Eric to develop.  The important thing is to imagine a student sitting at a display terminal, not at a card punch!

Println is also interesting because the "ln" suffix goes back, I believe to IBM record-oriented  input–output where there was no newline character.  I think that it's time that it went away.  It's familiar to those of us who grew up with line printers and card decks, but it is not something that I should have to explain to CS1.

That's my 2 cents

	Andrew