Improve Slang? (was Re: [Vm-dev] RE: To FFI or not to FFI)

Michael Haupt mhaupt at gmail.com
Tue Oct 5 19:54:38 UTC 2010


Casey,

there's Apple's GCD extensions to the gcc family.
http://developer.apple.com/library/ios/#documentation/Cocoa/Conceptual/Blocks/Articles/00_Introduction.html%23//apple_ref/doc/uid/TP40007502

Best,

Michael

On 5 October 2010 21:45, Casey Ransberger <casey.obrien.r at gmail.com> wrote:
>
> Ooh, I'm liking 4! I didn't know there were C compilers with built-in support for closures. I'm going to have to google on that.
>
> On Oct 5, 2010, at 10:43 AM, Eliot Miranda <eliot.miranda at gmail.com> wrote:
>
> Hi Casey,
>
> On Tue, Oct 5, 2010 at 9:04 AM, Casey Ransberger <casey.obrien.r at gmail.com> wrote:
>>
>>
>> If you could make Slang suck less, what would you change?
>
> Four ideas:
> 1. a ground-up rewrite to clean up the code, and remove all the hacks, using method tags for metadata and eliminating class side things like mustBeGlobal:.  The inlining code is particularly difficult to understand and modify.  Inlining doesn't unify variables elegantly, introducing way too many copies.  Lots of this could be cleaned up.  Some type analysis (see below) would help.
> 2. generate code from an initialized instance (of Interpreter, StackInterpreter, CoInterpreter etc) which I expect will significantly simplify things like declareCVarsIn:, and would provide type analysis with a lot to go on.
> 3. replace the default object type sqInt with both an immediate type for SmallInteger (& eventually Character & SmallFloat) and a proper oop struct type that accesses header fields via message sends to the oop, not via bit masks applied by the Interpreter (see e.g. CogMethod CogBlockMethod and their simulators CogBlockMethodSurrogate32 et al).
> 4. start migrating to C compilers that have support for closures so the VM can be rewritten using Smalltalk control structures.
> best,
> Eliot
>>
>> On Oct 4, 2010, at 8:47 PM, Eliot Miranda <eliot.miranda at gmail.com> wrote:
>>
>>
>>
>> On Mon, Oct 4, 2010 at 1:04 PM, Colin Putney <colin at wiresong.com> wrote:
>>>
>>> On Mon, Oct 4, 2010 at 11:56 AM, Andreas Raab <andreas.raab at gmx.de> wrote:
>>>
>>> > In practice, there is a *huge* advantage for porting if all you need is a C
>>> > compiler and a bit of knowledge about the underlying OS support.
>>>
>>> This brings up a question that I've been wondering about for a while.
>>> How useful is Slang these days?
>>>
>>> I can totally see how it would have been faster to get the new VM up
>>> and running in Apple Smalltalk in the first place, but I'm wondering
>>> if these days it's more trouble than it's worth. Most dynamic
>>> languages (eg, Ruby, Python, Perl, Javascript) are implemented in
>>> straight, idiomatic C and benefit a lot from the fact that many, many
>>> people already have the skills needed to work with the language and
>>> toolchain.
>>>
>>> In contrast, the Squeak VM is written in a language that almost nobody
>>> knows, using tools that almost nobody understands. Outside of the
>>> current maintainers it's a very short list, and many of the people on
>>> it aren't active in the community anymore. "Implemented in its self"
>>> is kind of neat, but as a practical matter, Slang is not Smalltalk,
>>> and a developer skilled in both C and Smalltalk still has a lot to
>>> learn before he can contribute to the VM.
>>>
>>> So here's a question to the folks that are actively hacking on the VM:
>>> is Slang still beneficial in your day-to-day work? Do you write and
>>> debug using the simulator? Is it worth the high barriers to entry for
>>> the uninitiated?
>>
>> Slang sucks. Developing in Smalltalk is great.  I like using Slang to being continually hit over the head by an ungiving guru; plenty of pain but no enlightenment.  The problem is you write Smalltalk that works, push it out and when it doesn't work due to some internal Slang issue you're in a lot of pain.  Do you try and fix Slang, do you mangle your Smalltalk to function within its limitations (and forget to comment why, e.g. ::
>> loadNewPlugin: pluginString
>> | plugin plugins simulatorClasses |
>> transcript cr; show: 'Looking for module ', pluginString.
>> "but *why*??"
>> (#('FloatArrayPlugin' 'Matrix2x3Plugin') includes: pluginString) ifTrue:
>> [transcript show: ' ... defeated'. ^nil].
>> Seriously, if anyone knows why these two are disabled *please* let me know.
>> Yes I write and debug using the simulator.  Yes it is worth the high barriers.  But Slang is still a massive, fragile hack.
>> HTH
>> Eliot
>>
>>
>>>
>>> Colin
>>
>>
>
>
>


More information about the Vm-dev mailing list