[Types-sig] A late entry

[John Viega]

On Fri, Mar 17, 2000 at 01:24:09AM -0500, Tim Peters wrote:
> [Barry Warsaw, explaining the problems 'a would create for python-mode.el]
> > ...
> > You could also argue that Py3K shouldn't have to cater to a 20 year
> > old technology like Emacs, and you'd probably be right.
> 
> P3K should cater to Python programmers, though!
> 
>     'a
> 
> simply looks like an unterminated string, regardless of whether pymode or
> Python programmers are looking at it.

The syntactic context in which types are used is more than different
enough for programmers, IMHO.  I think you'd have a much bigger
problem with "=" and "==".  My personal goal for the syntax is to
choose something natural to people with some familiarity with the
concepts coming in, avoiding something really ugly.  I think that
saying the tick isn't very obvious to anyone not familiar with ML and
similar languages is fair.  I think formatting problems are fair.  I
think <> is probably going to be a bit more familiar to people, but
look horrible in source.

Hey, how about the backtick? :) Using that would mess up peoples emacs
formatting in far fewer cases, if you tell emacs mode that ` is just a
regular old operator :) Seriously, though, it's probably not all that
likely that a syntax will be chosen where it's all things to all
people, and that's to be expected.


> The second most likely bad
> interpretation will come from Lispers, viewing it as a symbol.  So it's
> simply poor notation for Python.  'a' would work, though!  

That's almost like saying that people with a lisp background are going
to think there's a function call every time they see a left
parenthesis.  Plus, there are definitely reasons why the tick is
common between types in ML and symbols in lisp.  They both represent
abstractions away from concrete values.  Granted, there are some
significant semantic differences, though :)


> Haskell uses
> unadorned letters for type parameters (i.e., the ML convention isn't
> universal even among its relatives) -- but Haskell doesn't have inline
> function declarations.

Right... there are good reasons why Haskell doesn't need such
syntactic garbage.  You're also right that there isn't a universal
syntax.  ML's is pretty widely known as far as it goes, but the FP
community is really small.  There are all sorts of syntaxes for type
variables... I know some languages start with "*" and then keep adding
"*"'s as they need more vars in a type.

> 
> > ...
> > I'd also be interested in seeing what the IDLE developers think about
> > such syntax changes.
> 
> I expect that context-sensitive literal syntax is a non-starter regardless
> of tool (don't forget PythonWorks, and tokenize.py, and pyclbr.py, and
> kjlint, and untold mounds of homegrown stuff that also expects apostrophe to
> mean string).


Nooo, using a tick in type expressions doesn't do anything to affect
whether that particular piece of syntax is regular, context-free or
context-sensitive.  Context-sensitive is definitely wrong; the entire
type syntax I proposed is context-free, and not because of the ticks.
Replace the ' with a `, + or a ~, and nothing has changed.  The presence
of the :- segregates the type quite distinctly... the tick itself
doesn't even move the syntax into the context-free world... it's the
ability to nest types (e.g., ('x ('y 'z ('x))) ) that brings the type
language in the realm of the non-regular.

> Don't get hung up on the spelling!  As someone else wise once said, Guido is
> a master of syntax, and will pick something *he* likes regardless of what we
> recommend <0.9 wink>.

In this particular case, I'm not really attached to the syntax; I'm
just hard pressed to come up with an alternative that isn't at least
as ugly.  Point well taken, however.

John