Test for psybas conversation

gistfile1.md

Verifying my understanding of psychotic bastard:

set x: fn (b) : cons : 't (cons 'b ())

is a valid way to say

(set x (fn (b) (cons (' t) (cons (' b) ()))))

Correct?

truthandbeauty.psy

Currently true code samples?

-----

set x: fn (b): cons 't (cons 'b ())    ===>    (set x (fn (b) (cons (' t) (cons (' b) ()))))

set x: fn (b): cons 't: cons 'b ()     ===>    (set x (fn (b) (cons (' t) (cons (' b) ()))))

-----

set def:
    '('name ... 'code
      leak: really name
      set (really name) code)

and

set def:
    '(('name ... 'code):
        leak: really name
        set (really name) code)

(set def 
    (' (((' name) ... (' code)) 
        (leak (really name)) 
        (set (really name) code))))

[MAYBE this, too:
set def:
    '('name ... 'code
    leak: really name
    set (really name) code)]

-----

OK, how far is the reach of an infix operator? Like, what does this translate to:

a: b: c (d) <<operator>> (e: f) g h: i

My first instinct is to call it at the colon and the end of line:

(a (b (operator (c (d)) ((e (f)) g h (i))))

Is that what you're calling the 'logical' line? What about this?

a: b <> c d:
    e f g
    i j k

I'm allowing

a b <<c d e>> f g

to mean

((c d e) (a b) (f g)

am I doing that right?

EDIT: This is called psychotic bastard not because it is a crazy idea but because attempting to parse it makes me want to kill.

Shit, and what about (damnit, pre can't handle << and >>. Substituted [[ and ]])

a b [[operator]] d e:
    f g

is that

(operator (a b) (d e (f g)))?

Also parens are hard, too

abbot and costello (are:
    going to the
    store to buy) some bread

(abbot and costello (are (going to the) (store to buy)) some bread)?
(abbot and costello (are (going to the) (store to buy)) (some bread))?

Or is it illegal? If so, what about:

(\x: 
    do some things
    mostly to x I guess) 5

EDIT: I guess it HAS to be (abbot and costello (are (going to the) (store to buy)) some bread), or else everything falls apart.

Operators really need to be held in by colons on both sides, because the letting them run to the end of the line is wrong in block form. (I have this wrong in my parser right now, and didn't realize it was wrong until I tried to explain how it works. Essentially, an infix operator that comes before a colon and isn't in a paren shouldn't extend past the colon:

embrace [[compose]] extinguish:
    lotus
    novell

# Requires def-syntax
if a > b:
    print blammo

I'm not 100% sold on this; I've written a few snippets and know that there are some cases where you want to have colon syntax fire first:

header  body:
    article1
    article2

but I am about 98% sold.

Your Abbot and Costello edit is exactly right. The other function in that post is legal for me, but I thought not for you. Did you forget parens around the argument list, or have you come around on that one?

I had not considered << and >> wrapping anything other than a single identifier. Interesting.

I don't know if we got this wrong anywhere else, but in your example

a: b: c (d) <> (e: f) g h: i

there is a colon that doesn't do anything (after e). The one after h only has the effect of limiting the scope of the operator. Both f and i don't get parens from the colons because they're already a single expression. IOW,

e: f

and

e:
    f

and

(e f)

are all the same.

Aside: Seriously, how did you people deal with closing parens until the right one flashes for decades? I wonder this every time I translate something back to s-expressions.

I knew I had a better example that's pro colon-fires-first:
rest-of-line <- many: indented-past block-indent >> basic-expr

Here <- is roughly let. The block this comes from is monadic, but that's not important right now, the gist is the let/set/define operator should have the lowest precedence (colon should fire first).

(Also not important is that the line is ugly.)

Hmm.

Easy answers first:

I came around on the arg-list-parens for a single argument; I still think you're crazy for wanting \x y z: x + y + z.

Re (e: f): Yes, there are places where the colon is unnecessary. I've found it useful in test cases to have those --- sometimes for readability and sometimes to try and fool the parser.

Re: aside: I dunno --- I was born at the right time, and always had flashy whatsits (though I hear they have pills for that now). To your credit, I had to write some s-expressions to explain something on G+, and it just about made me throw the keyboard ('cept it was a laptop). Psychotic Bastard is bizarre (and seems more so the more I try and explain it to myself) but it's pleasant to write.

(Oh god, I just realized I've been ignoring infix precedence. Poop. I thought I had this worked out right finally.)

You're going to give : a precedence between operators??? It's not an operator! It's a delimiter! I... ugh... arrgh. We gon' have words, friend.

Every possible method for doing if/else is completely and utterly wrong and I despise each of them, individually, for the hateful snowflakes they truly are.

I had a code sketch for if/else that was a pretty naive 4 lines long. I put in a working but hideous version tonight via def-keyword. It weighed in at around 50 lines, two of which were

                             ; OMG HACKS

and

                             ; END OMG

I'm taking this as a sign that I haven't got def-keyword right yet.