On 7 Dec 2008, at 13:41, Günther Noack wrote:
> Hi!
>
> It's fantastic that Pragmatic Smalltalk makes such a good
> progress. :-)
>
> Considering that a 1.0 release is a good time to take a first look at
> a software, I think it would be a good idea to make sure it's really
> polished for that so that the first impression for new developers is
> positive. :-) When programming with Pragmatic Smalltalk, I still
> usually come across language issues that aren't fixed yet, like e.g.
> the 'integers as instance variables' issue I found yesterday,
Integers as instance variables should have been fixed yesterday. It
was a weird bug caused by an LLVM pass removing the boxing and
assignment code. Adding an assignment of the unboxed variable to a
file static in MsgSendSmallInt made it go away as a quick hack, and I
since identified the pass that was responsible for the removal and
deleted it from the ones that are run.
> or the
> segfault when -run only does '1 log.'.
$ cat 1log.st
NSObject subclass: SmalltalkTool [
run [
1 log.
]
]
$ edlc -f 1log.st
2008-12-07 13:47:14.913 edlc[53269] 1
Works for me... Possibly an LLVM bug on Linux?
> Points I'd personally like to see in an ideal 1.0 release:
> * Documentation explaining the deltas between "traditional" Smalltalk,
> Pragmatic Smalltalk and Objective-C
> * Issues like:
> * What is a block and how do I use it?
> * How do the type pragmas work?
> * How does the automatic type conversion work?
> * How to make objects respond to binary messages.
> * This can make transition so much easier for potential new Etoile
> developers! :-)
There's a short tutorial online and I've expanded your README a bit.
Still more to do, contributions welcome...
> * More meaningful error messages
Ah, good point. I want to rewrite the error / warning handling in
SmalltalkKit / LanguageKit to log warnings to a delegate, rather than
fire exceptions or NSLog things. This should be done before 1.0 since
we need it for writing a nice IDE.
The parser now uses a custom NSString subclass which knows its
location in the source string. I want to make sure each of the AST
nodes retains these so that you can easily go from error to token.
> * Basic class libraries:
> * Operators for the classes in FoundationKit and AppKit
> * String concatenation, Set operations, Array concatenation etc
> * These are really easy to write, but we should make sure each
> of
> them is a good idea. When people start to use it, it will be
> harder
> to change.
Good idea.
> * More complete support for blocks in fundamental data structures.
I added a few things to NSArray. Ideally getting these up to parity
with the methods in the Smalltalk-80 collection classes would be good.
> * The relationship between BigInt, SmallInt (and NSNumber?): Can this
> be arranged in a more meaningful way in the class hierarchy, so
> that
> there's a common base class you can extend?
SmallInt isn't really a class at all. If you extend BigInt then you
implicitly get a method on SmallInt. The methods SmallInt supports
are known at compile time (and are inlined). If you send a message to
SmallInt that it doesn't support then it will be promoted to a BigInt
and the message sent instead.
I don't know the best way of integrating NSNumber with this, however.
I would very much welcome any patches to MsgSendSmallInt.m that people
wanted to submit - currently there are lots of missing small integer
messages, in particular things like and: and or:. These are all
simple 3-4 line C functions, but they need writing.
> * General language usability:
> * true and false should be defined
I think Truls was going to do this - they just need mapping to 1 and 0
integer literals in the front end.
> * hexadecimal escape characters in strings
I am not sure what this is useful for - Smalltalk code is unicode so
you rarely need escape sequences. Patches welcome, of course.
> * Preventing future backwards compatibility issues:
> * Fix mapping between binary message names and ObjC message names,
> even if not all of those mappings already work, a consistent naming
> scheme
> may prevent unnecessary complicated mapping code in future
> versions.
> e.g. like prepending 'op' and replacing all '+' by 'Plus', '-' by
> 'Minus', '*' my 'Star' etc.
The mapping here is a bit of a hack. I plan on adding some more stuff
to EtoileFoundation soon for cloning methods and creating classes at
run time. The important thing from Smalltalk's perspective is that
you will be able to do this:
[BigInt aliasMethod:@selector(add:) as:"+"];
This will then add another pointer in the class's dtable so that the
same method is called when it receives + or add: messages. Once this
is done, no mapping is required for any selectors (with the possible
exception of =).
> * Being careful with Smalltalkish extensions to the class library,
> like discussed above
Yup. I also want to move BigInt.m and BlockClosure.m from
SmalltalkKit to LanguageKit, since both of these are referenced
directly from LangaugeKit, while the other things in the SmalltalkKit
support library are just there to make it easier for Smalltalk
programmers.
> I'd suggest bumping it to 0.9 and then take some time to test it and
> make sure it's a sound language for programmers to work in. Especially
> in border cases like when sending messages to nil, Pragmatic Smalltalk
> behaves differently to traditional Smalltalk dialects, which may make
> it worth to do some design decisions right in the first place before
> people pick it up and start to hack around these issues. ( nil =
> anObject ifTrue: [ ... ]. What does this code do? :-> )
I am thinking of modifying this to map nil to NSNull when sending
messages. Thoughts? This will add some overhead when sending
messages, so I might make it tweakable via a pragma.
> However, don't get me wrong, Pragmatic Smalltalk makes an amazing
> progress! :-) I'm really optimistic that it can have a bit of an
> impact when we get the initial 1.0 release right. :-)
>
> Best regards,
> Günther
>
> On 6 Dec 2008, at 18:57, David Chisnall wrote:
>
>> I opened up my 'list of things I wanted to have implemented before I
>> called Smalltalk 1.0' and crossed off the ones that were done. Left
>> on the list was... nothing.
>>
>> So, I would like to bump LanguageKit / SmalltalkKit up to the magic
>> 1.0 for 0.4.1. The current version, however, almost certainly
>> contains many bugs, which means that it needs testing before I do.
>>
>> David
>>
>> _______________________________________________
>> Etoile-discuss mailing list
>> [email protected]
>> https://mail.gna.org/listinfo/etoile-discuss
>
>
> _______________________________________________
> Etoile-discuss mailing list
> [email protected]
> https://mail.gna.org/listinfo/etoile-discuss
_______________________________________________
Etoile-discuss mailing list
[email protected]
https://mail.gna.org/listinfo/etoile-discuss
