[ENH] Message lookup-failure overrides

[Brian Rice]

Ah, technical issues trump everything here. After digging through the  
Parser code, I realize it'll be more appropriate to delay this until  
a new more abstract parsing framework is available, since a change of  
this quality would require too a big restructuring for the value.

However, I did manage to get the statement-separator requirement made  
togglable again. This is the old "feature" / "bug" of the Slate  
Parser that allowed statements or array elements to follow each other  
sequentially without periods when there is no ambiguity, i.e. "[3 4  
(3 + 4)] do." evaluates to 7. Parentheses disambiguate in any case.

Basically the #parseConcatenatively option on Parser will now toggle  
this feature. e.g. "repl parser parseConcatenatively: False" will  
make period-separators mandatory. The new images I'm uploading  
tonight will have this set to True.

On Mar 21, 2006, at 5:09 PM, Brian Rice wrote:

> Hm, in how many ways can I state that this interests me and yet  
> deny that I want to do it? :P
>
> So, consider this flip-flopping email stupid, and I'll take a look  
> at removing this grammatical restriction from the Slate Parser.
>
> End result: in such cases, you'll get MethodNotFound at run-time  
> rather than a Lexer error at compile-time. If possible, I'll make  
> this a switchable mode.
>
> Yell if you don't like the idea or think I'm too obsessed with it.
>
> On Mar 21, 2006, at 4:20 PM, Brian Rice wrote:
>
>> Quickie hack example of this usage:
>>
>> Slate 1> ensureNamespace: #Integers.
>> (traitsWindow)
>> Slate 2> _ at Integers didNotUnderstand: msg at: idx [(Integer  
>> readFrom: msg selector) ifNotNilDo: [| :i | [i]]].
>> [didNotUnderstand:at:]
>> Slate 3> #4 sendWith: Integers.
>> 4
>>
>> "Integers 4" is not valid in Slate grammar right now, hence the  
>> sendWith:, but that'd be the idea of this object. It's the same  
>> with any other literal. This can be changed, but it'd push Slate  
>> towards a Forth-like (aka "concatenative") grammar.
>>
>> If we did this, then a LOT more would be permitted in Slate  
>> grammar. For example, "(some Expression) ( foo bar baz )" would  
>> evaluate the first expression which would then receive #( and then  
>> result in something that receives #foo, #bar, #baz, #), and so on.
>>
>> Honestly, I don't want to do that unless it's optimized-for in  
>> some way using pre-hoc programmatics using Map meta-objects than  
>> with DNU. Just to give an idea, every DNU-based setup requires a  
>> full lookup through the whole delegation tree before DNU is  
>> signaled by the VM and then handled, for each such send. So in  
>> order to make this a normal thing for Slate, it would have to be  
>> supported pre-lookup instead of post-lookup.
>>
>> However, if enough people think this is cool and worth adding,  
>> I'll have second thoughts or at least put more energy into it.  
>> Slate needs a dynamic inlining compiler, more urgently, though, so  
>> don't push too hard unless you don't care about that.
>>
>> In any case, the rationale for this kind of syntax extension is to  
>> give us a more flexible way to make structures of things. Doing  
>> this at the grammar / text-syntax level is troublesome, but lately  
>> I'm getting more and more fed up with Smalltalk-80 syntax  
>> limitations WRT Lisp or Forth.  (Slate's first design had that  
>> kind of grammar but went off the deep end and wasn't easy enough  
>> to read or write, and was scrapped for the PMD + Smalltalk-80-ish  
>> syntax idea instead.)

--
-Brian
http://tunes.org/~water/brice.vcf

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : /archives/slate/attachments/20060322/916157e9/PGP.pgp