Building a string from incompatible objects.

Costas Menico wrote in message <[hidden email]>...
>[...]So using #<< for streams means you cannot include, for example,
>literals unless first they are written to a stream.

Why not?  If #<< in Stream is implemented as returning the receiver, in a
chain like

  aStream << 'one' << 1 << #one << one

the receiver of each #<< is the original aStream.  It does not matter
whether an object being written is a literal or not.  Or maybe I don't
understand your point.

But I really wanted to comment on a few points from the "let's extend the
language" argument.   Note "comment" instead of "argue about" because I
don't feel as negative about operators for stream output as I did about
operators for collection creation, but I believe there are more important
things to worry about.

>I can imagine longtime purists don't like this. Newcomers will
>immediately look for these things. I know I did and was dissapointed
>not to find these basic of things.

I guess I would count as a longtime purist.  I still remember my first
impression coming to Smalltalk from a C++ background (because that was
something I would never forget).  "Disappointment" is the word I would never
thought of using to describe it.  I did notice that I had to type
'nextPutAll:' instead of just '<<'.  But I also noticed how it often took a
line of code to do the same it took a screenful or two in C++.  (And that
was in the happy pre-COM days).  So I said, I *love* to be pound-wise and
penny-stupid rather than the other way around.

Of course, mileage varies, but this is exactly what I want to point out.  I
don't believe all newcomers are disappointed.

>I can guarrantee you that a mainstream Smalltalk programmer in the
>heat of meeting deadlines would use the binary operators.

I think this is fighting for productivity gain at the wrong level.  What
ultimately matters for meeting a deadline is how fast you put your objects
into place.  Smalltalk's primary power is the ease of building and combining
objects, and this is what really buys productivity.  When you can do in a
hundred lines of code what you would need a thousand for in another
language, is it that bad if some of those lines are a few characters longer?

Again, I am not writing this to argue against #<< in Smalltalk.  I am
arguing against losing the original focus on what matters more and what
less.  It is nice to be both pound-wise *and* penny-wise, of course.  But
reusable and portable solutions like a standard socket protocol, or a
quality formatted output framework that Bijan just mentioned, are the things
that would buy more productivity than just sticking a few clever operators
in--though clever operators, if they make sense, could indeed be used in
those solutions.

>We should
>be open to extending Smalltalk. I look thru the ANSI document and I am
>surprised how little has changed since 1983. No one is perfect.

I would not confuse Smalltalks that people use and the ANSI.  All the "real"
implementations out there are way richer than the standard and are very
different from 1983.  The standard in its current form has more political
than technical value and was clearly designed to not leave existing
implementations out of the water as severely non-compliant.  With that
philosophy, it simply could not go much beyond the Blue Book.  It does not
mean the real Smalltalk out there didn't.

As for extending Smalltalk, again, things like CampSmalltalk projects are
exactly the kind of extensions that have a lot of real value so I don't
think there are any grounds for pessimism about Smalltalk being stagnant.

>Most languages implement them and
>that's where new Smalltalk blood will come form. And don't worry they
>will learn the other "better" methods  in time.

Yes, this is important.  Smalltalk *is* a different language, yet much of
its power comes from those differences.  Something can and should be be done
to make the transition easier, but not while forgetting other sides of the
issue, which are more about psychology and pedagogy than about technical
stuff.  The answer to "how do I do this in Smalltalk" is not always the code
that looks similar.  It could be the code that looks different, or even it
could be "we don't do this in Smalltalk, and you shouldn't because ...".

Also, there is the attitude.  If someone knows Basic and is not open to
accepting other way of doing things--well, this is a lost case, period.  A
lot depends on the teacher, though.  Playing Yoda saying "You must unlearn
what you have learned" is not really the solution, but helping people do
that is.  Still, if a student is used to another way of viewing things and
is not open to accepting a new one, he/she is not a future Smalltalker and
there is nothing we can do, no matter how many
Basic/Java/whatever-is-the-latest-fad idioms we try to staple onto
Smalltalk.

It is also about what people need.  Some people don't need Smalltalk.  I
like that I can build something experimental in a day or two, play with it
and see if it really is as useful as I thought.  I am not in it for the
coding, I am in it for the result.  Some people are in it for the coding and
they like to twiddle bits and debug memory leaks.  Yet other people are in
it for the paycheck, and would sell used cars with just as much
indifference.  They just don't care and won't read anything but "Learn Java
in 21 Day" because why bother?

What I've been leading to is, drawing new people into Smalltalk is extremely
important.  But the technical side here is secondary.  A lot depends on the
student's willingness to accept change (with the teacher's ability to help
learn new ways) and the student being of the kind able to appreciate what
Smalltalk has to offer.  These are the issues that a few quasi-familiar
operators alone are not going to solve.

(All IMHO, of course).

--Vassili

--
Vassili Bykov
[hidden email]

On Thu, 04 Jan 2001 18:15:21 GMT, [hidden email] wrote:
...

#+ is the standard way of concatenating Strings in Cincom's
ObjectStudio. It automatically converts the parameter object to a
String by sending the message #asString before actually concatenating.
So you can write:
'Please pay the following: $ ' + 10 + ' today ' + Date today.

Additionally, ObjectStudio also provides String>>++ which works like
#+ but automatically puts a space character between the 2 objects.

I think the automatic conversion makes it much more convenient and,
what's even more important, easier to read. And even if you need
special String representation you can always explicitly transform the
parameter object into a respective String before concatenating.

However, #+ is not defined/implemented in Object but in class String
and might sooner or later have to be replaced by the ANSI compliant
#,. Of course, it cannot be in Object since it would clash with
Number>>+. And due to its arithmetic nature people might object to use
#+ for String concatenation at all. While <'Small' + 'talk'> seems
okay, <'ObjectStudio ' + 6> seems rather odd especially since <6 +
'ObjectStudio'> does not work at all. So #++ is probably the better
choice. Still, I would not implement it in Object but in String only
since being able to send #++ to *any* object and expect a String in
return is rather awkward, i.e. it does not communicate its intention
very well or in the case of sending it to a Number it might even be
misinterpreted.

Having that said, I would not consider implementing a new (unofficial)
concatenation method but try to change the implementation of #, in
class String so that the parameter object is first converted to a
String before any further processing is done. This should not break
existing code yet make your life easier.

Regards,
Paul Wallimann

[hidden email] (Costas Menico) wrote (abridged):
> I like the #<< suggestion because it can be generalized for streams
> and programmers get the sense that is a stream. However I thought
> that << is used for bitshift so how would this work if the receiver
> was am integer? And what is wrong with ++ anyway (I know it
> reminds people of C++)

On the choice of concrete operator...

For me #++ has strong associations with #+. #+ has two important
properties:

(1) It is commutative, ie a+b = b+a.
(2) It is side-effect free, ie a+b does not affect a or b.

and I would expect #++ to have them too. Neither property holds for this
new method. (Incidently, using #+ for concatenation, as Java does, is bad
by this principle.)

I strongly feel that any asymmetric operation should have an asymmetric
operator (if it has an operator at all). Here I would only consider
things like #<<, #<+, #+=, #<- and the like. The operation has a side
effect and we want to be very clear which object is the affected one.

I suggested #<< because it is used in C++ and I saw no reason to be
different. Many Smalltalkers, and potential Smalltalkers, know C++. That
said, C++ uses it because it has to; because C++ does not allow new
operators to be defined. We don't have that restriction in Smalltalk.

I now think #<< is a bad choice because of the possible conflict with
shifting. This conflict wouldn't be a major problem - C++ survives it -
but there's no reason to have a problem at all. In code like:
     WriteStream new << '4 = ' << (1 << 2).

the bracketed #<< would have different meaning to the other #<<. The
compiler would be happy but we humans don't need that crap. Also I want
to extend the operation to collections, which raises issues of vector
maths. Eg:
    #( 1 2 3 ) << 2

arguably should mean:
    #( 4 8 12 )
   
or perhaps:
    #( 1 2 3 0 0)

Let's not go there. (Again, using #+ for concatenation raises problems
with vector maths.)

#<- looks too much like assignment and #+= is too much like addition and
assignment. I don't see much wrong with #<+ but I'm open to other ideas.

  Dave Harris, Nottingham, UK | "Weave a circle round him thrice,
      [hidden email]      |   And close your eyes with holy dread,
                              |  For he on honey dew hath fed
 http://www.bhresearch.co.uk/ |   And drunk the milk of Paradise."

[hidden email] wrote:

Paul,

>
>
>#+ is the standard way of concatenating Strings in Cincom's
>ObjectStudio. It automatically converts the parameter object to a
>String by sending the message #asString before actually concatenating.
>So you can write:
>'Please pay the following: $ ' + 10 + ' today ' + Date today.

How come no one else brought this up? Is ObjectStudio not being used
anymore?

>><snip>

>
>Additionally, ObjectStudio also provides String>>++ which works like
>#+ but automatically puts a space character between the 2 objects.

This to me is fluff. Now we are talking beyond reasonable need.

>><snip>

Costas

Costas Menico <[hidden email]> wrote:

>>Additionally, ObjectStudio also provides String>>++ which works like
>>#+ but automatically puts a space character between the 2 objects.
>
> This to me is fluff. Now we are talking beyond reasonable need.

I've found such operators useful in other languages - they've been
similarly named, as && where & is the standard string concatenation
operator.  Next to drawing interface components, string construction
tends to be the source of my longest and ugliest methods, and any small
saving (a + ' ' + b, versus a ++ b) is justified if it improves
readability.

Constructing debugging statements or other human-readable text via
traditional stream messages is painful, as everyone agrees.  I
inevitably use a nextPutAll: when I mean print: or nextPut:, or forget
an intervening space or cr, and have to go through several iterations of
testing.  It's even worse when certain portions of the string are
omitted depending on context.

One alternative is positional format string operators, e.g. the QKS #<<%
discussed elsewhere in this thread, or Python's %, but no matter how
feature-packed, they're susceptible to breaking when you update the
argument list but not the format string, or vice versa.

Referring to arguments by name instead of position helps somewhat.
Without support from your tools, you may still wait until runtime to
discover that the format string doesn't work.  And such schemes often
encode properties of the arguments (string width, number format) within
the format string.  Having to tag the various localized versions of your
strings for revision, because you changed the type conversion for an
argument, is not a good use of anyone's time.

Another possibility is to use named arguments in combination with
interpolation, a la Perl and other scripting languages.  An interpolated
string could be compiled into the equivalent stream messages, possibly
wrapped in a block, without much work.  One could permit temporary
variables within the string:

        ^aStream printMessage: #transactionComplete
         givenFormat: '$|t := logRecord transaction|
          Transaction $id[t id], which began at $start[t startTime], has
          $status[t completionStatus].
 
          $[t errors]
         '.

Localized versions of the message #transactionComplete would just refer
to $id, $status, etc.  It doesn't look much like Smalltalk, but it's
readable and easily modifiable.  Automatic whitespace elimination would
also be a useful thing to have (consider Perl's /x modifier for regular
expressions) - perhaps such strings could be affected by the formatter.
I'm sure I'm not the only person who has to keep adjusting such
constructs as:

        x := 'This is a long string blah blah blah blah foo bla.  ' ,
             'Here is its continuation'.

moving the position of the comma, to get the appropriate wrapping when
altering the string's contents.

One could argue that methods such as the one above really "want" to be
in another class, and would better be rewritten as:

        ^logRecord transaction printCompletionMessageOn: aStream

That's quite a good decision in most cases, but it is often the case
with error and debugging messages, to distribute the code that
constructs the message would complicate tracing control flow far more
than is necessary.  Usually there end up being a lot more objects that
get referenced in constructing a message than in the contrived example
above, too.

--
Nicholas Riley <njriley@uiuc edu>

Dave Harris wrote in message ...
IMHO, both are pretty bad.  The first makes a totally arbitrary assumption
of the type of the array elements.  What about all those arrays that don't
contain integers but still understand #<<?  The second makes the same
arbitrary assumption since it inserts zeros at the end--why not nil, a more
universal no-object?  Even more important, what is the point of this
collection shift at all?  I could understand the argument for #<< in
Collections as a more or less synonym of #addAll: (and even that opens a can
with a few worms if you consider it closer). This shift that fills
collection with junk to me looks like "let's add this cute quasi-graphical
thingie and oh by the way, what should it mean?"

--Vassili

--
Vassili Bykov
[hidden email]

On Sun, 7 Jan 2001, Nicholas Riley wrote:

Heh! It's nice to see Costas in the "anti-fluff" position ;)

>  Next to drawing interface components, string construction
> tends to be the source of my longest and ugliest methods, and any small
> saving (a + ' ' + b, versus a ++ b) is justified if it improves
> readability.

Just to reiterate, this suggests that fundamentally different techniques
are need. Concatination just doesn't cut it.

> Constructing debugging statements or other human-readable text via
> traditional stream messages is painful, as everyone agrees.

No, afaict, the don't all agree. Of course the issue at had is whetehr
they are sufficiently more painful than concatination or operator based
substitutes.

>  I
> inevitably use a nextPutAll: when I mean print: or nextPut:, or forget
> an intervening space or cr, and have to go through several iterations of
> testing.  It's even worse when certain portions of the string are
> omitted depending on context.

Have you every worked with or examined the Common Lisp format system? It
seems to excel at this sort of thing though, I must say, it looks rather
yucky to me.

> One alternative is positional format string operators, e.g. the QKS #<<%
> discussed elsewhere in this thread, or Python's %, but no matter how
> feature-packed, they're susceptible to breaking when you update the
> argument list but not the format string, or vice versa.

Yes, pure positional substitution breaks down pretty quickly. Python's
ability to use a dicitonary for named positions works much better.

[snip]
I haven't quite gotten this example yet. More examples, perhaps of
localized use?

One inherent problem with format strings is that, like regex string
patterns, you end up with an opaque language encoded in the strings. In
general, I like to avoid that. The natural response is something like
"make an object", but I haven't quite figured out the best way to apply
that response :)

A good general pattern for dealing with text heavy situtation is to invert
escaping: i.e., instead of having program text be the defaul and literal
strings being delimited by, say, $'s, you make the literal string
interpretation the default and escape the program bits (a la asp). Squeak
server pages does this, and can do so on a per method basis so it shows up
nicely in your browser. I don't think you can pass arguments in, but that
seems a reasonable extention.

Couple this with SmalltalkAgents pretty cool styled text literals or
WikiWiki like formatting punctuation and you have a pretty handy system.

Indeed, there's no inherent reason to limit it to full method bodies...you
could have something like python's triple quoting, or, more generally,
"here strings".

[snip]

Cheers,
Bijan "Still gathering ideas and data" Parsia.

On Sun, 7 Jan 2001, Costas Menico wrote:

[snip]
> >#+ is the standard way of concatenating Strings in Cincom's
> >ObjectStudio. It automatically converts the parameter object to a
> >String by sending the message #asString before actually concatenating.
> >So you can write:
> >'Please pay the following: $ ' + 10 + ' today ' + Date today.
>
> How come no one else brought this up?

Because none of the other respondants thus far use ObjectStudio much if at
all? Because it's nothing to get excited about?

> Is ObjectStudio not being used
> anymore?

Actually, I would bet that use is growing somewhat now that Cincom is
bundling it with VisualWorks and shifting gears to becoming
a more general Smalltalk vendor. ObjectStudio was much more a vertical
market app.

 From what I've heard, ObjectStudio is quite interesting but often -- for
historical reasons -- rather non-standard. (I dearly hope that
#+ isn't *instead of* #, but I'm not sure.) There is slow movement toward
making it ANSI conformant, I believe.

Cheers,
Bijan Parsia.

On Sun, 7 Jan 2001, Dave Harris wrote:
[snip]
> I strongly feel that any asymmetric operation should have an asymmetric
> operator (if it has an operator at all). Here I would only consider
> things like #<<, #<+, #+=, #<- and the like. The operation has a side
> effect and we want to be very clear which object is the affected one.

Well, #<< the bitshift has no side effects. Nor does #-> the Association
constructor.

I'm curious as to what you thought about my symatry claim about most
Smalltalk binary messages (i.e., that while you don't necessarily get the
same result, swapping the argument and receiver usually *makes sense*)? I
don't know how valuable this property *really* is, but it seems
reasonable.

[snip]
> I now think #<< is a bad choice because of the possible conflict with
> shifting.

I'm still wondering if it's *really* more readable, and what other
operators would work to fill in the rest of operations. I mean, is it
really worth replacing #print: with #<< and that's it?

> This conflict wouldn't be a major problem - C++ survives it -
> but there's no reason to have a problem at all.

*Definitely*!

> In code like:
>      WriteStream new << '4 = ' << (1 << 2).
>
> the bracketed #<< would have different meaning to the other #<<. The
> compiler would be happy but we humans don't need that crap.

Oh yeah yeah yeah yeah!

[snip]
> #<- looks too much like assignment and #+= is too much like addition and
> assignment. I don't see much wrong with #<+ but I'm open to other ideas.

Aren't we now just looking for an operator for operators sake? Given the
untowardness of many of the possibilities, I'm not sanguine of the chances
for getting a decent family of operators going.

OTOH, if one went the format string route, one would have a completely
free hand, since the namespace is completely uncluttered.

Cheers,
Bijan Parsia.

"Bijan Parsia" <[hidden email]> wrote in message
news:[hidden email]...

[...snip...]

Hmm. You guys have really gotten me thinking about this one.

SmallScript defines the $` as an operator for declaring regular expressions.

    `...'

A regular expression is a language in itself ala perl/python etc. A regular
expression is fully compiled to allow references to variables and embedding
of subcontext/closures to be used as filters etc. Just like perl. In simple
terms, you can think of it as a special block format where the language
within the block is regex. The regex language supports escapes to allow you
to declare subcontext (inner blocks) in some other language (usually
SmallScript).

------
SIDEBAR: SmallScript and QKS Smalltalk allow string literals to be declared
with static concatenation. I.e.

    x := 'foo'
         'bar'
         $3
         'Zed'.
    "Is actually compiled as"
    x := 'foobar3Zed'.

Similarly, SmallScript's regex pattern can also be written using this same
static concatenation form:
    x := `...'
         '...'
          ...

I should also mention that within a string, the $` character is an escape
sequence similar to $\ in c/c++; but without the annoying conflicts with
directory path delimiters, etc.

    '`n...' "is the same as" '`x13`x10...'

    "xml and html formatting extensions for <StyledStrings>"
    '`<b>A bold string`</b>'
------

So, with that bit of background, the formatting ideas your discussing are
similar. I believe that formatting and otherwise managing text processing is
VERY important. Especially with regard to my goals for scripting language
services.

You've now gotten me thinking about how the `...' regular expression
operator might be extended to allow declaring a formatter object. A
formatter object, like the <RegEx> object, would be a kind of closure. It
would have direct access to variables declared within the format string.

Hmmm. I'm sure this technique could be more generalized. For example, it
might be very useful to have it for other forms of macro expansion. For
example, it might be useful to be able to support an SQL compiler syntax the
same way.  I wonder if using the standard SmallScript type annotation system
would do it?

    <SQL>`...'.
    <Format>`...'.
    <RegEx>`...'.

Where the default when not specified would be <RegEx>.

Ah, well. I need a lot more time to ponder and think this through.  But the
idea is very intriguing and seems to lead to a generalized mechanism for
providing compiler extensions. (I.e., `...' tokens get passed by the
SmallScript compiler to a (dynamically identified) registered compiler for
the given <type>. That compiler extension then replaces the parse tree node
for the given `...' token with its parse-subtree-form.)

Hmm, maybe this will give lead to an acceptable mechanism for providing a
macro system?

Thanks guys!!!

-- Dave Simmons [www.qks.com / www.smallscript.com]
  "Effectively solving a problem begins with how you express it."


[...snip...]

>
> Cheers,
> Bijan "Still gathering ideas and data" Parsia.
>

Bijan Parsia <[hidden email]> wrote:

I was never a fluffer. On the otherhand I feel Smalltalk is not a
religion either. It's a real computer development environment and does
need some enhancements to fulfill user needs. If Smalltalk's mission
is to develop real world applications then market demand and vendor
competition will make it happen.

Regards,

Costas

> [ snip ]
>
> I was never a fluffer. On the otherhand I feel Smalltalk is not a
> religion either. It's a real computer development environment and does
> need some enhancements to fulfill user needs. If Smalltalk's mission
> is to develop real world applications then market demand and vendor
> competition will make it happen.

You are absolutely right , Costas. Smalltalk *is* an environment which *can*
fullfill *developer* needs. I mean there are lots of possible enchancements
in the minds of many developers , it's just that not all of them can fit
into Smalltalk without making it cryptic and overcomplicated. Extensive use
of ascii symbols and convenience methods in messages and constructions *can*
make Smalltalk overcomplicated. Let's say we all appreciate your efforts and
I am pretty sure that someone will now extend the streams (an strings)
protocols with ">>"s , "++"s etc. But let's try not to make it standart. Why
don't we post those extension on wiki so developers can actually decide
themselves whether they want something like that or no.
The bottom line is - even though some convenience methods are quite good and
useful ( I am not talking about string concatenation protocol only ) we
can't make them the part of a standart right away. Maybe that's not exactly
what I wanted to say, but...

Have a good day

-Boris

P.S. Personally I would never want to see that 'abc' ++ 'def' will be
actually 'abc def'. I would call it "unexpected side-effect"... Anywayz...
:)

[hidden email] (Vassili Bykov) wrote (abridged):
> Dave Harris wrote in message ...
> > Also I want to extend the operation to collections, which
> > raises issues of vector maths. Eg [...]
>
> IMHO, both are pretty bad.  The first makes a totally arbitrary
> assumption of the type of the array elements. What about all
> those arrays that don't contain integers but still understand #<<?

When I say "vector maths", I mean a special kind of object like a matrix
or a 3D point or, well, a physics vector, which by-definition contains
number-like things. Vector arithmetic includes things like dot-product
and cross-product, and loads of stuff that doesn't make sense for
collections.

Arguably the vector protocol is totally different to the collections
protocol and the two shouldn't be confused. On the other hand, we can
think of a vector as an ordered collection of numbers and things like
#do: might be quite handy. Anyway, I think they are close enough that to
have #<< in both protocols would be confusing even if it wasn't
out-and-out dangerous.


> Even more important, what is the point of this collection shift at
> all?

In vector maths, we have things like
    (#( 1 2 3 ) asVector * 2) asArray = #( 2 4 6 )

in other words, multiplication of a vector by a scalar means multiply
each element by that scalar. It would make sense to extend shift to
vectors in the same way.

I omitted the #asVector and #asArray messages in the previous example for
brevity, but perhaps that was a mistake.

  Dave Harris, Nottingham, UK | "Weave a circle round him thrice,
      [hidden email]      |   And close your eyes with holy dread,
                              |  For he on honey dew hath fed
 http://www.bhresearch.co.uk/ |   And drunk the milk of Paradise."

[hidden email] (David Simmons) wrote (abridged):
> A regular expression is a language in itself ala perl/python etc.

Presumably it would be possible to translate that language into normal
Smalltalk syntax. Would that not be a good idea?


> A formatter object, like the <RegEx> object, would be a kind
> of closure.

How much do you know about early (circa 1971) Smalltalk? As far as I can
tell, a message send resulted in the entire message being sent to the
receiver and the receiver effectively parsed it, giving it more control
over the syntax than now. The language syntax could vary on an
object-by-object basis. This proved to be too much flexibility, leading
to the current compromise.

Apologies if you know this stuff better than me - which is quite likely.
Most of what I know comes from Kay's "Early History of Smalltalk" paper,
which I found online recently.

I think the current compromise is a good one, and I should like to see it
more fully exploited. Rules like "operators must be commutative"
undermine it. When we only have 3 levels of precedence we can't afford to
throw one of them away. On the other hand, the early Smalltalk stuff also
sounded pretty cool. It would be interesting to go back to those ideas
with what we have learned over the last 30 years.

  Dave Harris, Nottingham, UK | "Weave a circle round him thrice,
      [hidden email]      |   And close your eyes with holy dread,
                              |  For he on honey dew hath fed
 http://www.bhresearch.co.uk/ |   And drunk the milk of Paradise."

"Dave Harris" <[hidden email]> wrote in message
news:[hidden email]...
> [hidden email] (David Simmons) wrote (abridged):
> > A regular expression is a language in itself ala perl/python etc.
>
> Presumably it would be possible to translate that language into normal
> Smalltalk syntax.

Yes, it could be translated into SmallScript (or even Smalltalk) source.
But, as I'll alude to in subsequent paragraphs, a parse tree form is more
powerful. It enables direct translation by a back end into a wide variety of
languages (not just Smalltalk).

> Would that not be a good idea?

Well, keeping in mind its purpose, this is a rather circuitous route that
also reduces the ability of the compiler to optimize the code.  I.e., the
only consumer of the translated result is the compiler. It is only
interested in a parse tree node from a tokenizer/lexer.

-------------
SOME DETAILS:
The tokenizer/lexer for given language may produce tokens that directly
reference elements in an outer XML parse tree (such as those used for
generating .NET assemblies/modules).

I.e., "SmallScript" source is logically:
Extensible AOS Object Model (and/or XML) Source. The language is really that
of the AOS Object Model -- but for simplicity it subsumed under the term
"SmallScript" source. In actuality the SmallScript source is only that which
is contained within a method.

Within the AOS Object Model (and/or XML) source, a given token type may be a
method in any language, the default language is SmallScript.
-------------

Why tokenize and lex/analyze it twice?

What happens when some constructs don't have suitably equivalent
representations?

NOTE: The parse tree is optimized and then translated directly (by a
pluggable back-end) into platform specific instructions and object model
representations. (I.e., AOS Platform opcodes and object model metadata, or
.NET IL and metadata, or whatever the backends target is). The parse tree
system itself is directly extensible so that the front-end can add new
features for various back-end operations.

I've never read that paper; I'll have to find it (unless you perchance mail
it to me :). But I was aware that the syntax of early Smalltalk
implementations was much more flexible.

My (most likely flawed) understanding was that it had conceptual features
for altering the syntax; like lisp (no surprises here if you're have some
knowledge of the trends of that day and of the Smalltalk developer's
eventually direct rivalry relationship with lisp developer's where Smalltalk
was the younger and significantly less respected sibling). Based on what
you've described it would have been a very slow interpreter -- which I would
guess would have been a significant motivating factor for changing it.

Based on my direct discussion with Alan (in the early-mid 90's) about the
early evolution of Smalltalk, my understanding of the very first versions of
Smalltalk were that it's design/implementation was simple and had very
limited relationship to the Smalltalk's available by the early to mid 90's.

>
> I think the current compromise is a good one, and I should like to see it
> more fully exploited.

I may be confused here :-). Which "compromise" are you referring to?

> Rules like "operators must be commutative" undermine it.

I strongly agree. In general, one of Smalltalk's great strengths is that it
uses messages for a wide range of capabilities for which other languages
hard/code operators. There are a number of circumstances where operators are
more suitable/desireable/appropriate than using an equivalent message.

Operators allow for optimizations and compactness/simplicity of expression,
but often come at the cost of flexibility and generality. So, at least for
me, creating new "operators" for a language like Smalltalk (or SmallScript)
requires a lot of thought and care.

For example, many languages have operators for arrays. I wanted the
flexibility and generality of messages but the syntactic utility of
operators. So, in SmallScript, I chose to extend Smalltalk's messaging
system to accomodate some additional message forms.

  "They have higher precedence than a unary message"

  o    apply-value message
        (...)
  o    array-slice message
        [ : ...] [...
  o    property message
        { , ...} {...

---------------------------------------------
BEGIN array-slice method declaration examples
---------------------------------------------

<?method [<::at:> "The #at: is an alternate selector"
[aKeyOrIndex]()
    ...
]?>

"OR it could have been written equivalently written as:"
<?method [<::[<>]()>
at: aKeyOrIndex
    ...
]?>

<!-- ========== -->

<?method [<::[<>](<>)>
at: aKeyOrIndex put: value
    ...
]?>
"OR:"
<?method [<::at:put:>
[aKeyOrIndex](value)
    ...
]?>

<!-- ========== -->

<?method [<::[<>:<>]()>
copyFrom: firstInclusiveIndex to: lastInclusiveIndex
    ...
]?>
"OR:"
<?method [<::copyFrom:to:>
[firstInclusiveIndex : lastInclusiveIndex]()
    ...
]?>

<!-- ========== -->


<?method [<::[<>][<>]()>
at: index1 at: index2
    ...
]?>
"OR:"
<?method [<::at:at:>
[index1][index2]()
    ...
]?>
---------------
END OF EXAMPLES
---------------

With these new message forms the developer has the freedom to define the
definition of the messages to suit the features of the class. The other
SmallScript features such as type-annotations and multi-methods leave the
decision and power in the hands of the developer. Other than the additional
message form syntax, the messaging use and method design mechanism is
identical to that of any other smalltalk message/method.

"Here are some simple concocted examples of how you might use them"
[
    | aList | := {1,2,7,19}.
    |r| := aList[3] + aList[2].
    |slice1| := aList[2:4].   "equivalent to -> #copyFrom: 2 to: 4"
    |slice2| := aList[2:].    "equivalent to -> #copyFrom: 2 to: aList size"
    |slice2| := aList[:2].    "equivalent to -> #copyFrom: 1 to: 2"

    aList[3] := 12.           "compiled as -> #aList[3](12)"

    "OR for strings..."
    aString[3:19] := 'foo'.   "replace a subrange"

    "Or (leveraging a multi-method) for reg-ex"
    aString[`someRegEx'] :=   'foo'. "a replacement result"

    "Or for supporting matrices"
    |subMatrix| := aMatrix[3][19:].
    |newMatrix| := aMatrix[3:] * someOtherMatrix.
]

My examples are obviously concocted. But they are there to give you a flavor
for what you can do when the message forms.

--------------------------------------------------
The matrix usage, for example could then be
tailored along a number of other characteristics
to design an efficient framework.
--------------------------------------------------
Multi-method argument typed binding allow efficient design and
implementation of generalized linear algebra operations such as the #*
message.

<?method [
* <IMatrix> multiplier
    ...
]?>
"OR for optimized ffi for same types"
<?method class=MatrixOfFloat80[<::MatMulFn(<>);$native>
* <self> multiplier
    "" $native is just an annotation stating that the
    "" method should be jitted to dynamically bind to
    "" an external ffi method in some library or DLL
    "" that is visible from the namespace scope of this
    "" method declaration.

    "" <self> is a parametric type that guarantees that
    "" this method will only be invoked if <multiplier>
    "" is the same type or a subclass of the method's
    "" dictionary type. This <self> type will also be
    "" used to invoke an appropriate marshaller for
    "" passing <receiver> and <multiplier> to the external
    "" function.

    "" ::MatMulFn(<>) is an annotation stating that
    "" this method has an alternate name of 'MatMulFn'
    "" which may be used when dynamically binding it to
    "" an external library/DLL. Or, when invoking this
    "" message in SmallScript.
    ""
    "" I.e.,
    ""    foo * bar
    "" Is equivalent to the SmallScript expressions:
    "" --------------------------------------------
    ""    foo MatMulFn(bar)
    ""    foo.MatMulFn(bar)
    ""    foo::MatMulFn(bar)
]?>

The AOS object model allows declaring a matrix class whose elements are
value-fields (like fields of type extended-float) that are maintained in
their binary form and do not exist as objects.

To create such a class would probably require declaring only a few methods,
the rest coming from the (mix-in behavior) interface capabilities. (i.e., an
IMatrix mixin might allow the behavior of matrix operations to be shared
among all n-dimensional matrices without having to recode it for each
distinct type/variant).

<class name     =MatrixOfFloat80
  extends       =AbstractMatrix
  authors       ="David Simmons"
  version       ="1.0.0"
  interfaces    =IMatrix (* may not be needed if declared in AbstractMatrix
*)
  value-fields  ='<Float80>[...]'
>

The structured storage design/object's-memory-layout would enable writing
methods that transparently callout to external code which could perform the
numerics operations using an existing library. If such a library did not
exist, the ability to declare a SmallScript method with a c++ body would
enable also enable achieving portable hi-performance numerics.

<?method [
someMethodHeader
    <lang=c++>
/*
    code that performs operations in C++ on
    given <receiver> and method arguments.

    -- I use this extensively in building the
       core SmallScript system. It's one reason
       why there are NO primitives in the v4
       SmallScript/QKS Smalltalk.
*/
]?>
--------------------------------------------------
END Matrix Implementation Comments
--------------------------------------------------

> When we only have 3 levels of precedence we can't afford to
> throw one of them away. On the other hand, the early Smalltalk stuff also
> sounded pretty cool. It would be interesting to go back to those ideas
> with what we have learned over the last 30 years.

For the last couple years I've been acquiring and reading a number of books
written in the late 60's and early 70's about what was hot and in vogue in
the CS field. I've found it to be very enlightening in gaining understanding
of the younger (sometimes clearer) ideas in the CS field and how those ideas
may have affected and shaped Smalltalk's evolution.

>
>   Dave Harris, Nottingham, UK | "Weave a circle round him thrice,
>       [hidden email]      |   And close your eyes with holy dread,
>                               |  For he on honey dew hath fed
>  http://www.bhresearch.co.uk/ |   And drunk the milk of Paradise."

-- Dave Simmons [www.qks.com / www.smallscript.com]
  "Effectively solving a problem begins with how you express it."

"Costas Menico" <[hidden email]> wrote in message
news:[hidden email]...

On the otherhand I feel Smalltalk is not a
> religion either. It's a real computer development environment and does
> need some enhancements to fulfill user needs. If Smalltalk's mission
> is to develop real world applications then market demand and vendor
> competition will make it happen.
>

I've been lurking long enough now and thought I'd add my pennysworth. Of
course smalltalk isn't a religion but it is a language of great elegance and
syntactic simplicity . Moving away from this to add ambiguous and cryptic
symbols in order to save a few keystokes or make C programmers feel more at
home seems a fairly retrograde step to me.

The beauty of Smalltalk is that the development environment can be adapted
and messages added to the base image by the individual developer in any way
they see fit so if C , Python or Perl syntax gives you a warm glow then by
all means add it to your image but please don't inflict it on me ( or on
anyone else who has to maintain your code :-) )

David

On Mon, 08 Jan 2001 14:58:51 GMT, "Boris Popov" <[hidden email]>
wrote:

If I read into this is what you are saying is, that we should not
tamper with the language as it exists any further. There is nothing
else we should add or, this language needs. And if we need something
and maybe useful to everyone don't bother just keep it to yourself.

I appreciate all the comments. I just needed a shortcut for my own use
and anyone else who wants to use it. I wanted to know the best way to
implement this. There were many good suggestions. And if people think
it should go in to the standard or not, thats ok too. As long as
Smalltalk lets me do it my way, I am cool. So far I can't complain.

And since no one sees a use for ++, I will use it for myself. Chances
it won't intefrere with any future developments. So I am putting
everyone on notice: Don't use my ++. Its mine and I plan to copyright
it.

>
>P.S. Personally I would never want to see that 'abc' ++ 'def' will be
>actually 'abc def'. I would call it "unexpected side-effect"... Anywayz...
>:)

I never suggested ++ should pad any blanks. I just wanted 'abcdef'.
For that I would suggest ('abc') ++ ' ' ++ 'def' or use messages such
as #padLeft:, #padRight: and #padCenter:

Costas

"Costas Menico" <[hidden email]> wrote in message
news:[hidden email]...
I'll bite, what the heck is a fluffer? And what did Bijan mean when he used
the phrase "anti-fluff"?

> On the otherhand I feel Smalltalk is not a
> religion either. It's a real computer development environment and does
> need some enhancements to fulfill user needs. If Smalltalk's mission
> is to develop real world applications then market demand and vendor
> competition will make it happen.
>
> Regards,
>
> Costas

-- Dave Simmons [www.qks.com / www.smallscript.com]
  "Effectively solving a problem begins with how you express it."

<[hidden email]> wrote in message
news:[hidden email]... *can*
> >fullfill *developer* needs. I mean there are lots of possible
enchancements
> >in the minds of many developers , it's just that not all of them can fit
> >into Smalltalk without making it cryptic and overcomplicated. Extensive
use
> >of ascii symbols and convenience methods in messages and constructions
*can*
> >make Smalltalk overcomplicated. Let's say we all appreciate your efforts
and
> >I am pretty sure that someone will now extend the streams (an strings)
> >protocols with ">>"s , "++"s etc. But let's try not to make it standart.
Why
> >don't we post those extension on wiki so developers can actually decide
> >themselves whether they want something like that or no.
> >The bottom line is - even though some convenience methods are quite good
and
> >useful ( I am not talking about string concatenation protocol only ) we
> >can't make them the part of a standart right away. Maybe that's not
exactly
> >what I wanted to say, but...
> >
> >Have a good day
>
> If I read into this is what you are saying is, that we should not
> tamper with the language as it exists any further. There is nothing
> else we should add or, this language needs. And if we need something
> and maybe useful to everyone don't bother just keep it to yourself.

Costas,

<opinion>
I've monitored this thread pretty much from the beginning. I don't
understand the semi-antagonistic attitude some posters have had to your
ideas (well actually I do, I just wish I didn't). You openly asked for
advice and ideas, you proposed and explored many ideas in the spirit of good
discourse.

In that same spirit some people disagreed with some ideas (some other people
chose to make comments that were not exactly in that spirit, and I for one
wish they wouldn't expose their attitudes so plainly).

It's a great thing to have open hearty debate and discussion and voice one's
opinion on the topic, its a whole other thing to criticize/denigrate the
individuals participating in such discourse.
--

For a long time people have been asking what's the deal with Smalltalk, what
can we do to make it more successful, why hasn't it become successful.

As to community and individual attitude about the Smalltalk language, it is,
in my experience, a very sensitive thing among born-again or longtime users
of Xerox/ParcPlace and/or its direct smalltalk derivatives. Smalltalk has
gone through a lot of painful periods over the last 15 years. I've
personally got my own very sensitive spots regarding the dramatic impact of
both Apple's and the Smalltalk market/communities devastating problems in
the mid-90s.

The passion most smalltalker's feel about their smalltalk is a great
strength; and so too is their healthy resistance to change. As long as that
resistance isn't blind or close minded.

Since ParcPlace supporters found a new home with Cincom, it has been
thriving and Cincom has been getting better and better at supporting and
promoting Smalltalk and their dialect to everyone's benefit.

But I have observed, that as a result, the "vocal" community sometimes
pushes the implicit view that Smalltalk and "ParcPlace/Cincom" Smalltalk are
one and the same thing, and when that happens and/or they implicitly sneer
at any or all the other Smalltalk dialects that exist or treat them as
inferior; the community and the language suffers.

I fully understand and respect when the Cincom Smalltalk employees want to
do everything possible to push Cincom Smalltalk as the leading Smalltalk in
every aspect. It's natural that they or any other Smalltalk dialect's
employees (or developer/designers for open-source versions) want to take
pride in their product and or see it have a successful, perhaps
leading/dominant, position.

OTOH if the Smalltalk community doesn't maintain an open mind about ALL the
Smalltalk dialect's or treats any of the supported dialects with an attitude
of disdain (as I've seen done with Dolphin Smalltalk vis-a-vis Cincom) then
the language and its advocates will continue to suffer as Smalltalk has for
the most recent five years of its long history.

The language itself is not sacrosanct, nor is any given dialect's
implementation or any given dialect's development team an unspoken
authoritative body for what is or is not "proper" for Smalltalk. Cincom is
doing great things for Smalltalk and for the community; but as members of
the community we need to remember they are just one dialect and they have a
valid vested interest in promoting their dialect over all others.

That having been said, the community itself is still not particularly
unified (squeak still stays mostly in its own group). Comp.lang.smalltalk is
not "comp.lang.smalltalk.cincom", and unfortunately we don't see the squeak
community exhibiting any motivation or desire to move to a
"comp.lang.smalltalk.squeak".

I've seen that the Dolphin community felt the need for a separate group and
I believe they are quite sensitive to some of the dialect bigotry that
sometimes rears its head. Smalltalk/MT (which has some really great and
unique features) often gets short-shrift here in this "dialect neutral"
comp.lang.smalltalk group. As does Bistro, or Smalltalk/X, etc.

Often enough, the "vocal" community members have limited awareness, or
experience with these one or another dialects so they promote their primary
dialect as if it were the only Smalltalk (and I'm sure I'm as guilty as
anyone in this area). That response is natural, but it is unfortunate for
Smalltalk as a whole, and in particular for the community of lurkers on
comp.lang.smalltalk.

As the community and its "vocal" members go forward I believe it is
important that they make every effort to allow and even encourage various
ideas, disenting opinions. And that they work to see beyond the
patterns/habits they've acquired/developed in their own particular Smalltalk
of choice.

There are many things inside of current Smalltalk implementations (including
Cincom's, IBM, Squeak, QKS, etc.) that are merely happenstance of their day
and would benefit from being redesigned (that includes both old and new
capabilities).

Unfortunately, some of the criticisms/arguments I've seen about new ideas
are based primarily on familiarity with this happenstance stuff, or just on
the notion that it is different from what the "proscribed" way/philosphy
we've had "forever" is.

Smalltalk is more than just its CS language; which means, all the more, that
continually exploring new ideas and techniques is important to its health
and longevity. It is a system, it is about the frameworks, and it is about
design, and it is about a way of thinking about software.

There are many new ideas that have been explored or provided in various
dialects which might be of value to the community. Overall, in all my years
in this community, it has been very open and good about this kind of thing
and their resistance to change has primarily exhibited a healthy
conservative approach.

But, sometimes, the thoughts and arguments (like some of the ideas they are
about :) are not well founded, deeply considered, or exhibit a backward
thinking or close-minded attitude (a bit of the stick-in-the-mud view).

This thread has, unfortunately, exposed some of these kind of factors in
individual and perhaps "vocal" community sentiment that have likely played a
negative role in Smalltalk's successful growth vis-a-vis other languages.

So, my personal message to you Costas is not to take this too personally. I,
for one, am encouraging you to keep exploring and I thank you for bringing
the line of discussion and your rich exploration of it to this forum.

</opinion>

-- Dave Simmons [www.qks.com / www.smallscript.com]
  "Effectively solving a problem begins with how you express it."
Anywayz...
> >:)
>
> I never suggested ++ should pad any blanks. I just wanted 'abcdef'.
> For that I would suggest ('abc') ++ ' ' ++ 'def' or use messages such
> as #padLeft:, #padRight: and #padCenter:
>
> Costas

David Simmons wrote:
>
> <[hidden email]> wrote in message
> news:[hidden email]...
> > On Mon, 08 Jan 2001 14:58:51 GMT, "Boris Popov"

IMHO, it's not that the language is sacrosanct; it's just that changing
the syntax (rather than adding methods/classes) is (IMHO) not the best
route.  Adding complexity isn't a great idea.


--
James A. Robertson
Product Manager (Smalltalk), Cincom
[hidden email]

<Talk Small and Carry a Big Class Library>