[Types-sig] New syntax?

[Christian Tismer]

Martijn Faassen wrote:
> 
> Paul Prescod wrote:
...
> What about putting this extra information inside the module file itself?
> You need a separate file because you want to come up with your own
> syntax, but even then you can do:
> 
> __types__ = """
> 
> def foo(int, int):
>     hey: int
>     hoi: [int]
>     result: string
... and so on ...

Yes I like that, but tried this earlier in some thread, see here:

[Greg, vaporizing runtime-looking type checks:-]
'''
On Wed, 15 Dec 1999, Christian Tismer wrote:
>...
> It doesn't matter if there is an extra file, or you insert a
> function call into your module, like
> 
> system.interface("""triple quoted string defining interface""")
> 
> without changes to the language but experimental syntaxes for
> these IF files/strings.

The compiler needs the information. This implies that you can't add the
information procedurally. The mechanism must be "transparent" to the
compiler.
'''

So where is the difference. The compiler would have to treat
__types__ as a special keyword and not an assignment target.
In my example, it would need to know what 
"system.interface" kind of animal is. I used this explicitly
to make my point clear, but this doesn't seem to help.

I think people want new syntax since this assures a new meaning
to some characters. I don't share this. If a new construct
just happens to fit into the existing language, why must we
forcibly invent a new escape? Yes this is all about escapes.
We escape into syntax, or escape into different files.
But nobody cares about None, which yet *can* be overwritten,
and which has a special role although not being a special
object. Also nobody cares that we use namespaces to "escape"
semantics. Those __init__ constructs are escaping animals
which are still in the language but have different meaning.
Nobody would refuse to parse a class definition and see if it
has an __init__, but for types we need a real new language?

We escape to justify a wrong idea.


> which incidentally would be a neat Pythonic syntax. :)

Very nice, IMO.

The string looks like a module in the module. But it needn't
be a string. I'm not against a new concept if it fits other
ideas. Opening a new context with new rules, why not?
We have classes, functions etc, which all impose different
semantics with nearly the same language. Now if we define
an interface object which has the exceptional rule that
it can *not* be generated dynamically by some tricks,
but can only be written statically down (which is nonsense
since I can write source code by program), then there would be
just one keyword necessary to tell the type checker that there
is something immutable in this module.
This interface object can btw. of course contain code which is
executed at compile time and be part of the type checking system.
Well, I see an idea coming...

sory, talking at length, I should go to sleep now - chris

-- 
Christian Tismer             :^)   <mailto:tismer@appliedbiometrics.com>
Applied Biometrics GmbH      :     Have a break! Take a ride on Python's
Kaiserin-Augusta-Allee 101   :    *Starship* http://starship.python.net
10553 Berlin                 :     PGP key -> http://wwwkeys.pgp.net
PGP Fingerprint       E182 71C7 1A9D 66E9 9D15  D3CC D4D7 93E2 1FAE F6DF
     we're tired of banana software - shipped green, ripens at home