[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Help-smalltalk] Re: Question regarding the parser(s)
From: |
Paolo Bonzini |
Subject: |
[Help-smalltalk] Re: Question regarding the parser(s) |
Date: |
Tue, 14 Sep 2010 10:01:21 +0200 |
User-agent: |
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.10) Gecko/20100621 Fedora/3.0.5-1.fc13 Lightning/1.0b2pre Mnenhy/0.8.3 Thunderbird/3.0.5 |
On 09/12/2010 07:21 PM, Holger Freyther wrote:
Hi Paolo,
I try to come up with a test case for my parser issue and I am a bit confused
and maybe you can help me out.
1.) if I use FileStream fileIn it will end at a primitive and will always
use the internal C Smalltalk parser?!
Unless you use "PackageLoader fileInPackage: 'Compiler'."
2.) Behavior evaluate: 'Object subclass: Foo'. In the default implementation
this will be wrapped by a 'DoIt [ ^ [', code, ']]' and then executed?
Internally this will be passed to compile which should end in
VMpr_Behavior_primCompile?
Now the weird part is, that part does not appear to know about GST Syntax.
Yes, and the fact that is wrapping your code with a method, is exactly
why it doesn't know about the GST syntax. The GST syntax is not valid
in methods.
To parse GST syntax, you can pass a Smalltalk stream to #fileIn, like
st> 'Object subclass: Foo []' readStream fileIn
a ReadStream
st> Foo
Foo
3.)
PackageLoader fileInPackage: 'Compiler'.
Behavior evaluate: 'Object subclass: #Foo3', returns nil and not
Foo3 as without the Compiler.
That's a bug:
st> PackageLoader fileInPackage: 'Compiler'.
...
st> Behavior evaluate: '3'
nil
I added to the issue tracker.
b) Should the Compiler return the (last?) class it created?
Only because it's the return value of #subclass:.
Paolo