Whitespace as syntax (was Re: Python Rocks!)

[Bijan Parsia]

Quinn Dunkan <quinn at zloty.ugcs.caltech.edu> wrote:

> >Bijan Parsia <bparsia at email.unc.edu> wrote:
[snip]
> >> One large advantage that both Perl and Python have is that they fit in
> >> well with a fairly common mindset that stems from certain set
> >> programming/working environments. This is more or less explicit in their
> >> designs. Squeak and Smalltalk are not a smooth fit for that mindset, so
> >> really mastering them typically requires a shift in deeply held habits.
> 
> Ok, this is getting a bit OT, but what the hey:
> 
> This is a good expression of my problem with smalltalk.  I like the language,
> I'm impressed with squeak, but I don't see how I can use it.  The first
> problem is that I don't want to use the built-in editor, I have my own tools
> and I prefer them for a reason.

Sure. It drives me nuts when I *can't* use em :)

>  Although I'm sure I could have squeak import
> source from external files, it seems like that would be fighting the language.

Certainly the implemenation. And probably the langauge, since at least
part of one major strand of (this is for you, Paul ;)) Smalltalk
philosophy is that we will hold all your whitespace hostage until you
see the errors of your ways and embrace left flapping scroll...


er, oops. Sorry, I always get the subliminals mixed up with the, uh,
liminals ;)

...One major strand of Smalltalk is that the real system is a collection
of live objects in memory, and there are various modalites for
interacting and shaping those objects. "Language syntax" is only one of
them, and not typically the dominante one. So, while there is a pure
textual representation of ANSI Smalltalk (which is a somewhat new move,
though the idea of declarative Smalltalk idea goes back several years),
the original "langauge" *required* the manipulation of a "virtual
image". Interestingly, in Smalltalk-76 you could adjust the sytax of
your methods on a class by class basis. (This should give an idea of how
the "langauge" syntax evolved.)

Indeed, the Squeak image still contains unmodifed bits that can trace
their heritage (via copying) back to at least a 1983 copy.

> The other problem is that the things I do usually involve lots of interaction
> between other programs, filesystems, etc. and work non-interactively.  Has
> anyone done a #!/usr/local/bin/smalltalk just-another-scripting-language?
> Would it even be smalltalk?

I think I answered this in another post, but GNU Smalltalk and Little
Smalltalk (which is not active, AFAIK) aim at this. As I said, the ANSI
standard deliberately moved away from *requiring* a image/vm approach,
and indeed, made it possible to write conforming (and thus portable)
programs that will run in an image and in, I guess, an interpreter of
some sort. This isn't a huge priority for me since I'm more interested
in the virtual image approach, but making a "smalltalk scriping system"
is certainly doable.

Oh, yes. Squeak has an XML-RPC implementation (and a, very
incomplete--my fault ;)--LDO one), though it hasn't yet made it's way
into the regular distribution. And, there is a plugin called
"OSProcesses" (with support classes)
(http://minnow.cc.gatech.edu/squeak/708) which allows (only on *nix thus
far, though I've been toying with using the applescript plug in to get
mac support in):

"Current capabilities include:

Inspect the OS process in which Squeak is running: "OSProcess
forThisOSProcess inspect"

Read standard input, and write standard output and standard error
streams.

Create operating system pipes and attach them to AttachableFileStream
streams.

Create Unix child processes with protocol similar to (same as?)
VisualWorks.

Clean up child processes automatically on exit (a Semaphore is set after
receiving a SIGCHLD signal), with child exit status available in Squeak.

Start a second Squeak in a child process, restarting the child from the
last saved image file: "UnixProcess squeak"

Clone the running Squeak image, producing two nearly identical Squeaks
running from the same object memory at the time of cloning: "UnixProcess
forkSqueak"

Clone the running Squeak image, but with no display connection for the
child: "UnixProcess forkHeadlessSqueakAndDo: aBlock"

Clone the running Squeak image with no display connection, execute a
block, and exit (similar to running a command from a Unix shell, except
that the "command" is a Smalltalk block): "UnixProcess
forkHeadlessSqueakAndDoThenQuit: aBlock"

I think this might cover most of your bases.


> >Only-half-a-joke: I think that Squeak's the biggest competitor not to
> >Python, but GNOME and KDE -- the world just hasn't realized it yet.
> 
> It would be interesting to see a squeak system running on hardware ala oberon
> or something (perhaps there is one?). 

At least three:

Bare metal port to a mitubishi chip, arm (and could be gotten up on an
Itsy--note that this was a fork an includes real time support), and a
"dos" port which basically uses dos as a bootloader.

Oh, and an "embedded" version which, I think, forgoes all graphic
support, or graphics requirement, I forget which :)

And it runs on WinCE machines. Rather nicely, actually. The complete
development environment and all.

> And not just aimed at being a
> code-writing environment, but a complete graphical environment. 

Er..Right. "Rather nicely, the complete development environment,
debugger, graphics, networking, etc."

Graphics run bit for bit on every platform Squeak is ported to (well,
*ok* except when we through them away :)). The VM is written in a
restricted Smalltalk subset called Slang. Squeak is self-hosting (i.e.,
you can run a Squeak image on a simulator of the VM running as
bytecompiled Smalltalk---slowly ;) This is the same code which generates
the c for the native vm, so you can debug your VM mods without leaving
Squeak using the standard tools.)

> I'm sure this
> has been done before, but on modern systems?  Hmmm... squeak + ggi + X
> compatibility layer....

There was a ...Qt?..Squeak project which sorta died out. THe codes
around somewhere. Right now a hot item on the Squeak list is a foreign
function interface.

Er..Anything else anyone wants to know? On comp.lang.python, that is.
Feel free to move over to comp.lang.smalltalk ;)

Cheers,
Bijan "Info-glut" Parsia.