symbols/syntax/syntax-match

[jrmithdobbs]

Am I missing it or are the following unimplemented currently?:

string->symbol / symbol->syntax (neither are in r[57]rs but common) syntax-case/syntax (isn't syntax-rules usually a syntax-case macro?)

syntax-case not match. I shouldn't post issues at 3am. :)

[justinethier]

No, you're on the right track:

Husk provides two macro systems: syntax-rules and explicit renaming macros. syntax-rules has been part of the standard since r5rs, and ER macros are a simple lower-level system planned to be part of r7rs-large.

string->symbol is implemented, but symbol->syntax is not. Do you have a reference for it?

syntax-case is a larger more complex system that is not supported, although if it was syntax-rules could be implemented in terms of it.

[justinethier]

Also, syntax-match sounds like a pattern matcher. That would be useful, but is not provided yet.

[jrmithdobbs]

Ah, then I'm not sure that symbol->syntax would actually be useful for what I want it for any how. With symbol->syntax there's MIT impl in gambit and whatever racket/plt's license is but I doubt it's very helpful (to directly lift, at least) since I'm unsure how much of it is scheme vs c.

Without symbol->syntax and syntax-case I think what I really want is this: https://github.com/justinethier/husk-scheme/blob/master/hs-src/Language/Scheme/Core.hs#L1306

:)

[jrmithdobbs]

If you're looking for description instead of implementation there's a good write up in Beautiful Code (isbn#9780596510046 ... it's on safari), but I'm not sure if that was sourced from elsewhere (like the modified STM/beautiful concurrency paper and such also included) or if it was an original work.

[justinethier]

That comment is stale, eval does support an optional environment argument: https://github.com/justinethier/husk-scheme/blob/master/hs-src/Language/Scheme/Core.hs#L1311

That said, explicit renaming macros let you run any scheme code you need at macro expansion time if that is what you are trying to do...

[jrmithdobbs]

I'm basically trying to delay evaluation of (dynamically supplied, quoted/quasiquoted) expressions with free variables until the last possible moment. Eg, the computation is some expression and it's scope the members of which follow mostly(*) letrec semantics at definition time. Whether any given variable is free-and-will-be-bound or results in a bad expression can't be easily determined before execution.

The most straight forward way (to me) would seem to be to use the global env (or a lambda's lexical env and something generator-y) with symbol->string and some delay / force hiding macros to get the cbn(eed) semantics I'm after.

(*) The reason for the seemingly round about approach is because the identifiers of some (not all, but could be normalized with macros) of the lvals also require access to the scope and a possible function application chain.

This is embedded not standalone so I may be missing a more obvious way to do it through ffi. eval taking an environment should mean I can build the scope and then expand/execute.

[justinethier]

OK. Not sure FFI would be the right approach, but (eval _ env) is there if you need it...

[justinethier]

@jrmithdobbs - Just curious, how did this work out for you?