paste into the interp; string coercion

[Mark S. Miller]

At 02:02 AM 10/19/98 , Ka-Ping Yee wrote:
>> Thank you, I now have my first satisfying answer for why I avoid
>> indentation-significance.
>
>Gee, i was kind of surprised to hear you say this.  If i had
>known that you didn't have a satisfying answer the Python-lover
>in me might even have asked for indentation...
>
>But i really thought the original strongest argument had to do
>with entering arbitrary code on the command line.  If you use
>indentation for block structure and/or scoping, then there is
>only a limited amount you can say on one line.

[+] Thanks, I now have two good answers.


>Do you think it's a good idea to make the E interpreter remove
>leading "?"s and ">"s from lines of input?

[+] Processing the embedded example syntax.
Basically (as worked out with MarcS) an E source file contains three kinds
of text: prose, code, and examples.  Examples are sequences like 

    ? define g(dog) {
    >     dog bark
    > }
    # value: <g>

When interpreting a file as code, both the prose and the examples are
ignored as comments.  When running the examples as regression test, first
the code is evaluated, then the examples are run -- comparing the actual
output with the stated output.  We evaluate all the code before any of the
examples so that an example use of an abstraction defined early can make
use of abstractions defined later.

The current elmer is crap, and doesn't support well this 3-part notion of
the contents of a file.  An interesting project on the E todo list is a new
elmer written in E that does support this well.  (Eventually, I'd love to
see an elmer descendant that's an extension of a wysiwyg html editor, but
first we need one that's an extension of a text editor.)  Any volunteers?


>> On int("4"), introspectively, I only find a surprisingly inarticulate
>> "that's not coercion, that's parsing!".  I may just be confused, I'll stew
>> further.
>
>Hmm.  Well, it is a simple kind of parsing.  But how else
>are you going to get an int out of a string, except by
>parsing?  The strongest argument for me in favour of int("4")
>producing 4 is that string(4) yields "4".  (Similarly i think
>many people would expect that float(string(3.14)) or
>double(string(3.14)) produced 3.14 too.)

[-] Don't confuse coercion and parsing.
What would you have int('4') yield?  When I think coercion I get one
answer; when I think parsing, I get another.  I certainly agree that it
needs to be convenient to parse, I just don't see why it should look like
coercion.


>> how would you feel about 
>> 
>> 	3 -> [3]
>> ?
>...
>Now, does
>
>    intlist(3) -> [3]
>
>seem more reasonable?

[-] No, it's horrible.