Re: [Help-smalltalk] [RFC] New Smalltalk syntax v2

[Paul D. Fernhout]

It's an interesting objection, but if you support both triple single
quote (''') and triple double quote ("""), then whichever one you use to
define the outside of a method body, you can use the other one in the
body of your method without escaping. :-)

See how Python does it:

$ python
Python 2.4.4 (#2, Jan 13 2007, 17:50:26)
[GCC 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> x = '''"""hello"""'''
>>> x
'"""hello"""'
>>>

It does the same for plain single quote (') and double quote (") by the
way, so you can single quote strings when you want embedded double
quotes, and vice versa, liek this:
  x = 'Mary said, "I love Smalltalk."'
and
  y = "Mary didn't say."

In Smalltalk, it could be used like this to have an embedded triple quote:

===

NullChessPiece addMethodFromSource: '''
    report
      Transcript show: """The report part hasn't been finished yet."""
'''; category: 'enumerating'.

===

Or:

===

NullChessPiece addMethodFromSource: """
    report
      Transcript show: '''The report part hasn't been finished yet.'''
"""; category: 'enumerating'.

====

Some comments might be made into strings in pathological cases though,
like this one: """""""""""""" COMMENT """""""""""""

Yes, I see your point about the triple quote and the pragma.

It would be nice to have an approach which indicates how a regular
method should be compiled. You still might consider making it into a
complete Smalltalk expression though. As in:
  <method Code: '''...'''>
or something like that. So the pragma becomes a piece of Smalltalk to
evaluate to produce the compiled method, rather than defining the method
itself directly. Then you don't need any special pragma evaluator --
it's essentially just later bound Smalltalk.

And then one might generalize this to using a special form of comment. So:

unsafeFastAdd: y
   "<pragma evaluate-after-compile>"
   method cCode: '''
      printf("unsafeFastAdd called\n");
      // the following code may crash the VM
      return int_to_st(st_to_int(x) + st_to_int(y));
      }
  ''' safetyLevel: #mayCrashVM.

So, by adding one special interpretation of a comment, along with triple
quote, we still have valid  standard Smalltalk syntax in the body. We
just need to "evaluate" the result of compiling within a namespace
including the method bound to "method" or something else. You could also
just use "self" but it might be preferable to have code that actually
did not compiler in a standard Smalltalk system. I guess instead you
could consider "method" as a new reserved word, and if it was refereed
to in a method, you would automatically evaluate the method after a
compile.

For example, without the comment, as the reference to method now makes
an implicit second evaluation:

unsafeFastAdd: y
   method cCode: '''
      printf("unsafeFastAdd called\n");
      // the following code may crash the VM
      return int_to_st(st_to_int(x) + st_to_int(y));
      }
  ''' safetyLevel: #mayCrashVM.

Probably more issues I'm not thinking of, of course, like how to pass in
arguments, or mix code at different levels of deferred evaluation.
Perhaps only expressions starting with method are deferred? Anyway,
probably several possible ways to handle that, although in the end, but
perhaps a special syntax like <Code> for immediate evaluation during
compilation might be preferred over implicit evaluation or using comments.

Note however, that the pragma idea is now being generalized to be
evaluation of *arbitrary* Smalltalk code at compile time, where the code
modifies the result of the compilation.

And perhaps that is a bad thing? It might make it harder for various
tools (like refactoring browsers) to do their job.

That problem is Colin Putney discussed here:
http://www.wiresong.ca/air/articles/2006/08/24/scripting-languages-and-ides
The whole piece is worth reading in the context of this thread since he
discusses exactly making a Smalltalk scripting language, but here is the
heart of the matter, in his word from that page:

"""
So, it would appear that we can have either a powerful language, or
powerful tools, but not both at the same time. And looking around, it’s
notable that there are no good IDEs for scripting languages, but none of
the languages that have good IDEs lend themselve to metaprogramming.

There is, of course, one exception. Smalltalk.

With Smalltalk, we have the best of both worlds. A highly dynamic
language where metaprogramming is incredibily easy, and at the same
time, a very powerful IDE. We can do this because we sidestep the whole
issue of declarative vs. imperative syntax by not having any syntax at all.

In Smalltalk, classes and methods are created by executing Smalltalk
code, just like in scripting languages. That code creates objects which
reflect the semantic elements of the program, just like in the IDEs for
compiled languages. One might say that programs in compiled languages
are primarily state, while programs in scripting languages are primarily
behavior. Smalltalk programs are object-oriented; they have both state
and behavior. The secret ingredient that makes this work is the image -
Smalltalk programs don’t have to be represented as text.

And that’s why a Smalltalk-like scripting language wouldn’t be
worthwhile. It leaves out the very thing that makes Smalltalk work so
well - the image. It would have to have syntax for creating classes -
either imperatively or declaratively. We’d end up limiting either the
language or the tools, or if we tried hard enough, both.

"""

[There is a reference to GNU Smalltalk in the first comment. :-)]

I feel that when you take the pragma idea the whole way, you get to
imperative syntax for defining methods. But that breaks a lot of the
goodness about Smalltalk development, as Colin Putney suggests. Perhaps
it can be done, but IMHO Colin Putney rightly lays out the danger.

And in that sense, your approach of adding extra syntax (which is less
general then what I proposed) and having restricted pragma statements is
perhaps better than the more elegant solution involving imperative
evaluation at compile time because it maintains Smalltalk as a
declarative model.

So, I'd say if the suggestion I've outlined was to be rejected (at least
as far as generalizing pragmas), that would be the best grounds for it.
:-) I think one could still use the triple quotes for fileout/filein
format without encountering all the general problems, but obviously it
is heading down that road.

This assumes one cannot find a way past the problem that Colin Putney
outlines in his essay. But if you do want to live dangerously, and
explore that direction, then I'd suggest considering what happens with
the more flexible, but dangerous, path I've outlined, including with
general Smalltalk code pragmas, and see if one could not build tools
that were powerful enough to handle the extra refactoring difficulties
if people start doing unusual things with it. :-) Personally, I'd
probably rather not see the general imperative form widely used in most
methods (as opposed to a declarative form). I like not having to think
at multiple levels of evaluation (like with Forth) when I read plain
Smalltalk code in a browser. Plain old Smalltalk seems powerful enough
for most things -- though I still would like easy ways to embed other
languages (C, Java, Python), in methods, as an implementation convenience.

--Paul Fernhout

Paolo Bonzini wrote:
>> I did not see any discussion of the alternative I proposed, see the
>> details here:
>> http://www.nabble.com/Re%3A--RFC--Smalltalk-scripting-syntax-p9406679.html
> 
> Uh, I thought I had answered that.
> 
> I don't like it because, ironically, I like ''' very much.
> But while you propose adding a useful syntax element, at the
> same time you make it inaccessible to the methods themselves
> (no, escaping is not a solution).
> 
>> Note also that this approach opens up the system for alternative
>> syntaxes. Such as:
> 
> That's a property of ''' in general, not tied to your proposal.
> With pragmas you could write a method like:
> 
> unsafeFastAdd: y
>    <cCode: '''
>       printf("unsafeFastAdd called\n");
>       // the following code may crash the VM
>       // if the arguments are not small integers
>       // no testing is done for performance reasons
>       // which is probably really not very wise in the long term.
>       // But if you can't crash it, you're not doing the driving. :-)
>       return int_to_st(st_to_int(x) + st_to_int(y));
>       }
>   ''' safetyLevel: #mayCrashVM>