Re: [stack] impure concatenativity: let without translation

...
> 1. It is necessary to run the program in order to get the definitions.
> This is obviously massively complicates, well, everything really.
>
> 2. Type checking is awkward as you run into errors in the definition
> before you know what the definition will be named. Error reporting
> becomes more difficult.
>
> 3. There's no way to introduce recursive definitions as the recursive
> call needs to be resolved before the name of the function is known.

Why cant we build a tree of tokens (first pass) and work with the tree?
ie, once we assure that the quotes are balanced, it resolves into a pure
expression tree (same as a prefix-lang) right?

> 4. Tool support is largely out the window.
>
> 5. You can't ensure that type checking or compilation will ever
> terminate.
>
>>> Keep in mind that even [a b c] is really (lambda () a b c). Putting
>>> meta-level things like 'define' and 'let' up front also aids in
>>> readability.
>>
>> not entirely. '[a b c]' is really '<quote literal> lambda' :)
>
> The same issues described above apply here. This is actually even more
> problematic as there's no way to guarantee that you can statically
> resolve bindings.

------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/concatenative/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/concatenative/join
    (Yahoo! ID required)

<*> To change settings via email:
    mailto:[email protected] 
    mailto:[email protected]

<*> To unsubscribe from this group, send an email to:
    [email protected]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/