Handling #rest in the parser is really freaking me out.

[shadowcat-mst]

Is there some logic under which it makes sense that I've missed?

Or is it just a convenient place to stash the functionality until it becomes worth moving to a more permanent home?

[shadowcat-mst]

Context for why I'm wondering: http://agaton.scsys.co.uk/~matthewt/wat-pl.txt

I'll open a separate ticket for "so, do we want to share tests and if so how?" (and give it a proper repo) once it's a little less underwhelming ;)

[manuel]

First of all: I'm delighted you're reimplementing Wat in Perl. That really seems fitting! :)

It's probably a hack to put it (#rest handling) there. Do you have a better place?

[manuel]

Regarding tests, we should probably write them in JSON.

[shadowcat-mst]

My suspicion is that it could move into one or other of the wat_match methods supporting bind (instinct says Cons).

I'll experiment once I finish porting the core; I'm trying to avoid changing much until the whole things works :)

[shadowcat-mst]

Again without having tried it, it seems like a Rest to go with Ign would be more consistent, and (I think?) avoid the need for list* - which would be nice, since I keep tripping over the "the tail of a list may not actually be NIL" thing when doing stuff like pretty printing.

I'll see about pushing my repo to github tomorrow so you can see what I mean; finally got it to work today after a long fight that turned out to be forgetting to create a fresh hash for bindings in make_env (apparently when you accidentally make everything global stuff get's really confused ... who'd'a thunk ... ;)

[shadowcat-mst]

Pushed as shadowcat-mst/wat-pl (apologies for hijacking this issue's comments)

[shadowcat-mst]

Commit 8705d0 on wat-pl master moves #rest handling into Wat::Cons; I think I consider this implementation to be far cleaner but if you disagree I'd be happy to hear why.

[manuel]

So you have a special rest object in the runtime, right? Well, I prefer doing it in the parser, because I then don't need any special handling in the runtime - a cons is just a cons, and matches the way it matches, with no need for special rest handling.

[shadowcat-mst]

Hmm. I wonder if it's simply the fact that I find the distinction between list-ending-in-pair and list-ending-in-nil affecting behaviour this way to be mind bending ... which is entirely possibly lack of familiarity with lisp, given it's been a few years since I've written it regularly enough.

Then again, having it in the parser still feels like a colossal hack, except in that #ignore turns into a special so it seemed clean to have #rest do so too ... but I can see how keeping the match code simple is also nice. Given so far as I can tell your current approach and mine are entirely compatible in use I'm not too troubled.

Although: Ooooh. An alternative thought: what if #rest became a magic symbol still like #ignore but instead of the wat_match methods handling it specially the vau macro handled it there? That would move the specialness from parser and matching code and into wat code, and therefore might possibly annoy us both less.

[manuel]

I'm not going to change it in wat-js. ["foo", "#rest", "bar"] is syntax for denoting a cons with car = "foo" and cdr = "bar", so there's nothing wrong with doing it in the parse step.

[shadowcat-mst]

Fair enough; you started off calling it "probably a hack" so I was trying to find something neither of us thought was a hack.

Am I right in assuming that so long as it doesn't cause some sort of fundamental incompatibility between the two implementations you don't care where the functionality ends up in wat-pl ?

[manuel]

Of course not. However, if you use a special #rest object, then the two languages are already incompatible. Evaluating ["cdr", ["quote", ["foo", "#rest", "bar"]]] will produce "bar" in wat-js, and ["#rest", "bar"] in wat-pl. So I'd recommend against changing it. Especially, since #rest is the same as the dot (.) in Kernel, which is the reference for the Wat language.

[shadowcat-mst]

Right, looking at #rest as pair construction makes it a lot easier for me to make sense of why it lives there.

I've switched it back to being in the parser and am going to studiously ignore any worries about it unless/until I find myself needing a second similar feature, on grounds that half my problem here has probably been premature (and ineffective) generalisation.

Thanks for talking me through it.

[manuel]

Sure. And given all the complex stuff in Wat, I think it's great that such a more or less minor issue is the only thing freaking you out :-)