λx.x would turn into (using Lisp notation) (λ x x), (λx.x λy.λz.y) into (CALL (λ x x) (λ y (λ z y))), etc.
It should also give some kind of result like ERROR (no list) if the input doesn't have the right syntax.
If you have any questions about what it should do in some case I've overlooked, just ask me.
I wanted to do that a year ago but failed
The input is a text string? And the output is Snap! code?
Exactly
"So I thought, Maybe I'm just annoying!"
So, like, Lisp notation?
It's from Girl Genius, which considers itself "PG." I can never remember if that's older or younger than PG-13, which is what we aim for, so I don't know if I should post the URL of the page it comes from...
No, actual Snap! lists.
I just Bing'd it and:
PG — Parental Guidance Suggested
[...]
PG-13 — Parents Strongly Cautioned
Oh yeah, of course; Lisp notation is "actual lists," not parentheses. That's just the text form that gets converted by the reader (which is the name for the program you want someone to write: a Lisp reader).
So... PG is milder than PG-13? Okay for ten-year-olds? Okay for eight-year-olds?
pg means "parental guidance" if i remember correct.
pg-13 i assume means "parental guidance for 13+" or something
anything pg or g is acceptable for young ages
Roughly that except "13-", not "13+".
I just made a λ evaluator, but it takes lists of this type as input; I'm going to make a list-to-text thing for this.
Edit: here. BTW it uses normal order evaluation.
Edit 2: Basically what I need is a block that undoes this:
My usual practice for problems of this sort is to turn the text input into a sort of text object that remembers a pointer into itself, so you say (MAKE TEXT OBJECT %string) -> something you can put in a variable. Then you can say (TEXT OBJ %obj NEXT CHAR) -> a character. Also it should be able to UNREAD %char to undo a read, and PEEK CHAR to report the next character without moving the pointer.
Then, you know, it's
SET CH TO (TEXT ... NEXT CHAR)
IF CH=λ ...
ELSE IF CH=( ... // This one has two recursive calls to the parser
Does that help? Or do I have to give you a starter project?
It should help. I'll make a project, then when I'm done, I'll give you the link to check if there's anything wrong with it.
Edit: Should NEXT CHAR and PREV CHAR (my name for UNREAD) report the letter at the pointer before the pointer is changed, or after it?
Edit 2: I have it almost working.
The first time you call it, you get the first char of the string.
About your project: My idea is that, for example, if you see a λ, then you call PARSE LAMBDA EXPRESSION, which reads a variable name, then makes sure the next thing is a dot, then recursively calls PARSE to parse the body, which is an expression. It seems on a quick read that you want to do everything within a character loop, by maintaining state in random variables.
So you should have PARSE EXPRESSION, PARSE LAMBDA EXPRESSION, and PARSE CALL that call each other as needed.
The tricky part is to handle optional parentheses, if you want to allow them. Otherwise "(" -> PARSE CALL.
PS UNREAD doesn't quite mean PREV CHAR, because it can unread a different character from what used to be in the text.
I'm not going to have those.
I've done too much already. (not just with this, but also another few. I have like four more lambda project today. (Edit: technically yesterday, but...)
The "y" key on my new phone's keyboard is in a weird spot, but that's because I'm using QWERTZ, which is because I'm using a German keyboard layout. "Zähler", something that counts.
What do you mean?
Oh, for example, since people mostly don't have lambda keys on their keyboards, you might have
IF (CH = "\") UNREAD "λ"
I still don't get it.
Hmm, how can I explain this? Sometimes you want to send a message to your future self (or your program's future self) by faking the user having typed something.
In principle you might need a message that's several characters long, but it just turns out in practice that often one character is enough.
I dunno, does that help? It's hard to read your mind about this...
