Fear and loathing of the "perification" of Smalltalk
Peter William Lount
peter at smalltalk.org
Fri Sep 14 18:51:59 UTC 2007
Hi,
Jason Johnson wrote:
> To be honest, I don't think it matters what the format is. It could
> just as well be XML. I think if we have a really good, Smalltalk
> neutral revision system all "file in" work could be done with that
> tool exclusively. At that point all dependency problems, etc. are the
> job of the RCS.
>
The take home point is to eliminate alternative syntaxes for new
capabilities. The alternative capability should be placed in the library.
Yes it may be fine to have a standard XML exchange format for those that
like XML as that would be in the "library" and not in the language itself.
However, it's vitally important to have a Smalltalk based format that is
expressed fully with pure message based syntax. I've shown that that is
not just possible but desirable.
> On 9/14/07, Damien Pollet <damien.pollet at gmail.com> wrote:
>
>> On 14/09/2007, Peter William Lount <peter at smalltalk.org> wrote:
>>
>>>>> Person addInstanceMethod: [firstName: aString | firstName :=
>>>>> aString ].
>>>>>
>>>> Not so easy.
>>>>
>>> Yes, so very easy.
>>>
>>>
>>>> How do you guarantee that "firstName" is in scope when the block is
>>>> compiled?
>>>>
>>> Why would you? Smalltalk is a dynamic language.
>>>
>> Maybe but Smalltalk also has lexical scoping, and here firstName seems
>> to need some kind of dynamic scope. IMHO that's counter-intuitive. The
>> semantics of Smalltalk were made to be simple, better to keep them so.
>>
Obviously the reference to "firstName" in the example above would need
to be tagged as needing resolution: what is it? a parameter? a instance
variable reference? a reference to an enclosing method? What scoping
context does it belong to? That doesn't need to be determined at compile
time! It can be determined and resolved at "construction" time when the
block is added to a class. It can be resolved at runtime. If it can't be
resolved obviously a #unresolvedVariableReference error would need to be
generated.
>> When we brainstormed on Sapphire's syntax, I proposed to add a new
>> literal for parsed-but-not-yet-compiled-syntax. You would then pass
>> those objects to reflective methods in charge of installing that code
>> in the system (and thus resolving variables and such).
Sounds interesting. Can you provide examples?
>> IMHO it's
>> better to clearly distinguish between program text and actual system
>> behavior.
>>
Yes, but it's best to NOT have two or more different syntaxes! Both
program text and system behavior configuration can be implemented with
ONE unified message based syntax using unary, binary and keyword messages.
As a matter of programming style the two concerns can be kept separate
if needed. The IDE can even provide "code review" warnings. This code
review "suggestions" and "warnings" is a highly successful approach at a
major Smalltalk installation.
People want to put all kinds of new syntaxes into Smalltalk. Don't
forget that we have one of the most powerful development environments on
the planet (and as far as we currently know, in the universe ;--)!
Almost all of the syntax enhancements that people suggest are better in
the library and the IDE. Let's put them there!
>> BTW I was also pushing for using an executable form for fileins:
>> filing in a file would be the same making a "do it" on the file's
>> contents, installing code in the system while the doit runs.
That is essentially what I've show can easily be done while using
Smalltalk. Filein's become do its. Certainly for a standard file in
format the language syntax and messages used in the filein need to be
standardized in a library for file ins. I would suggest that that
library be under an open BSD+D license so that all the vendors can make
use of it freely.
>> Now I'm
>> really not sure it's a good idea compared to a declarative syntax that
>> allows tools to manipulate the code as an abstract structure without
>> installing it.
>>
It's way better to use the existing messaging syntax than a special
declarative "syntax". The "declarations" can be made within the existing
Smalltalk message passing syntax of unary, binary and keyword syntaxes.
This has the benefit of eliminating the need for other syntax forms and
enables the extensibility of the declarative system itself! All, I
repeat, ALL META DATA and META OPERATIONS can be achieved with message
syntax!
>> Damien Pollet
>> type less, do more [ | ]
>>
Nice signature statement.
All the best,
Peter
More information about the Squeak-dev
mailing list
|