Everyone's favorite subject, Syntax (was Re: issues)

[Brian Rice]

On Mar 3, 2006, at 4:09 AM, Waldemar Kornewald wrote:

> Hi Brian,
> first of all, I can't reach the tunes server (but I can wait for  
> the new server to go up), so I can't put this on the wiki. Maybe  
> the routing or DNS entry is broken?

My email account is at the same server, so SOMETHING works. It has  
been acting strangely, though.

> You always want to hear what newbies think about Slate, so I hope  
> you won't find those issues too stupid:

Since these are all deep syntax suggestions that require a lot of  
work, let me clarify something:

Any code I write in this direction delays capabilities you implicitly  
need for more interesting uses. Any one of these things will take  
quite a while off of the more valuable stuff. Plus, as far as  
pleasing many people rather than a few, I'd rather have just a few  
contributors than a ton of idiots.

> * When defining methods, writing "x@(T traits)" instead of "x at T" is  
> very annoying, especially because you almost always use traits.  
> Can't we get rid of it, somehow? For example:
> x@(T traits)           =>  x at T
> x at T                    =>  x@(T itself)
> T traits addSlot: s    =>  T addSharedSlot: s

I'll think about it, but this will be confusing if and when I decide  
to make types-without-prototypes where the proper name goes right to  
the "traits" object, which I have intended for a while but not acted on.

Probably doing the Self thing with a "traits" namespace where you  
dispatch on "traits Foo" might make sense.

> * End-of-statement ('.') is often forgotten. Please make it  
> optional. Indentation and newlines could be used to distinguish  
> between statements.

No, or at least not yet. This changes the Slate grammar too much, and  
is partly covered by another feature:
1) Type "help." at the REPL, you will see "interactiveMode.". Call it.
2) Now you don't have to type periods. Slate will evaluate when you  
enter your first complete expression ended by a newline.

No, it doesn't automatically figure out indentation. Send me a patch  
to do it.

I will not use indentation-based syntax as standard until we are  
using a real UI and can abstract over syntax - even then it would be  
optional, if done at all. I have wanted to make periods-between- 
statements optional, but this requires disambiguation parentheses  
which make it more like lisp.

I am also not going to "join the python camp" - part of the reason  
for Slate's syntax is to alienate small-minded people and take a  
neutral political stance. It might surprise those friends of yours  
that request it that the syntax style it has actually offends and  
gets in the way of others.

> * Blocks and methods have different type annotation syntax ('@' vs  
> '!'). Since you want to change type annotations, anyway, please use  
> the same syntax for both.

Uh, no they don't. @ and ! mean totally different things. @ is  
actually a totally different syntax sugar for role-installation. ! is  
a type-annotation, which may be /inferred/ from a role-installation  
but again has nothing to do with dispatch and is just plain separate.  
If I merged the two, I'd have to figure out a totally different way  
to declare methods. @ is only a stop-gap for decent IDE structured  
editing, though, not that I have figured that out at all.

> * Inheritance model is too complex. E.g.: very difficult to  
> understand collections and streams (especially, ExternalResource  
> streams). It's difficult to follow all those methods (where do they  
> come from, which one is used for this prototype?). Could the Traits  
> framework help? Maybe a good browser could eliminate this problem,  
> too.

Agreed, multiple inheritance sucks to understand. The new Trait work  
PLUS a real browser is my intended solution, but I haven't gotten  
there yet.

Probably the answer to you for now is to try method-query.slate and  
the use of findOn: and so forth to learn about methods and where  
they're installed. There needs to be a better protocol above this  
(lookup.slate to encapsulate a full inheritance path), but I haven't  
made time to finish that.

Also, if you look at the slot-values of an object's traitsWindow, you  
will see the linear order of lookup from the object among its types -  
hopefully that will help for now.

> * It's very annoying and confusing that "2 + 4 * 5" is not  
> understood correctly (even if it's more consistent with other  
> binary messages). Please, at least add precedence for the most  
> basic operations (+,-,*,/).

NO. Use precedence.slate code (and maybe even write an alternative  
parser) if you must. I will not put this into the basic Slate  
language grammar. I will not oppose a /different/ grammar being made  
for those who want it, but there is a very specific reason why this  
lack-of-precedence exists in Smalltalk-80 and I refuse to change it.  
If you do this, you will also get all bug-reports related to syntax  
issues with polymorphic overrides of basic math operators.

> * #return: is much more self-explanatory than #^

That's easy. I'll add it now as an alias, but I will not change the  
default (yet).

However, it does not handle #^-variants like #^^ or others that have  
been envisioned. The best you may ever see is #return:from: but I'd  
need a way to communicate block labels for that.

> (Maybe also consider renaming #raisedTo: to #^).

I will NOT rename #raisedTo: - #^ is a convention for poor keyboards  
and ASCII limits (which I don't care about), and exponentials are not  
that commonly needed in practice.

> * Maybe make := the assignment operator (adjust parser, so it has  
> lowest precedence possible). I know that there already is `:=, but  
> that looks ugly and is too hard to type.

NO. := requires "l-values" in syntax terms, which would F*** up the  
slate grammar entirely. I will not do it. Again, write your own  
parser so you can discover what limits this results in.

I also do not want to make assignment easy.

At best, imagine a bright, shiny future where selector prefixes (`&%)  
are replaced by a "colorforth" style UI where you can see the type of  
usage from visual cues (not sure what to do for the blind, but it  
does have an easy fallback).

> * Block creation syntax is very ugly. Are really two pipes needed  
> for block definitions? Since '|' is reserved, it should be possible  
> to simply have:
> [var1 var2 | ...]

No, because var1 and var2 could be message-sends. I can "un-reserve"  
$| but... how is this going to be worth my time? Send a patch.

> * Array literal syntax is very cryptic and not self-explanatory  
> (newbies would think it is a symbol).

Which array literal syntax, {}, #{}, or #() (I know, I know, that's  
the hard part)?

Why would they think it's a symbol? Real examples and suggestions,  
please.

> Could an extension to macros allow for evaluating strings (or  
> complete blocks) at compile-time?

#[] is a block value evaluated at compile-time. It's explained in the  
manual.

#'' is a compile-time literal string, but I'm not going to put code  
evaluation in strings. Write your code and do (your code) `evaluate.  
It's right there in the manual, which you're probably not reading.

Try rephrasing these suggestions in terms of patches to the manual,  
please. I'll accept those more willingly if they actually make sense.

> Please consider fixing those issues. I've talked to many people  
> about switching to more productive languages and almost always got  
> the response that they can't stand ugly syntax and would rather go  
> with a less powerful language. Nice syntax is also very important  
> if you want to make Slate usable for young kids and people who want  
> to (mostly) program visually, but sometimes must enter a few lines  
> of code.

Actually, I don't /want/ users who are bothered by syntax. I want  
contributors, people who care about writing good code. People who  
care about syntax just want comfort. Slate may eventually allow for  
multiple syntaxes and full IDE support, and then they'll feel  
comfortable in it. And I'll move on.

> Cryptic syntax and the use of non-letter characters are big  
> problems. Compare these:
>
> [| :i k!(Number traits) |
>   k: 5.
>   i > 5 ifTrue: [^ (i + k)].
>   ...
> ].
>
> [ :i k at Number |
>   k := 5
>   i > 5 ifTrue: [return: i + k]
>   ...
> ]
>
> c@(Collection traits) indices: i@(Collection traits)
> [
>   i collect: [| :each | c at: each]
> ].
>
>
> c at Collection indices: i at Collection
> [
>   i collect: [ :each | c at: each]
> ]
>
> To me, the colon in front of parameters (":each") is disturbing,  
> too (probably IDE could help). Maybe you planned more radical  
> syntax changes (going away from Smalltalk)?

Oh, for heaven's sake, which part of "it's a smalltalk dialect" did  
you miss? The colons make visual reading of code easier, by marking  
argument positions and allowing for extensible phrase syntax. But I  
guess you don't care about that.

Just as above, imagine a bright, shiny future where punctuation is  
elided by visual support and turned into big, happy, mouse-sensitive  
blobs. See "tiles mode" for Squeak code - it's a crude start. No, I'm  
not joking - that's part of the vision. Contributing makes that  
vision arrive sooner rather than later - not suggestions that I code  
more for you.

The entire point of Slate syntax for now is that I can easily port  
and compare Slate code from Smalltalk-80 code. I don't care if C/Perl/ 
Java coders find it uncomfortable - frankly, they'll just write C/ 
Perl/Java in Slate, anyway, and the point of Slate is to NOT HAVE  
code like that in it.

If you want another parser, write one.

Until then, help me with the UI code and other supporting code to  
make it work/perform better, because THAT is when I'll decide to mess  
with other syntaxes - NOT A MOMENT before then.

--
-Brian
http://tunes.org/~water/brice.vcf

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : /archives/slate/attachments/20060303/372da94e/PGP.pgp