Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • S sweet-core
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 62
    • Issues 62
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 4
    • Merge requests 4
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages and registries
    • Packages and registries
    • Package Registry
    • Infrastructure Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • sweet-js
  • sweet-core
  • Issues
  • #615
Closed
Open
Issue created Dec 27, 2016 by Tim Disney@disnetContributor

Too many syntax object types in macros

So it turns out we can't quite remove SyntaxOrTermWrapper like I thought. I'd forgotten about the inner method that returns a new MacroContext, which is necessary because it allows expand inside of delimiters.

So currently a macro can get:

  • a SyntaxOrTermWrapper via ctx.next().value
  • a SyntaxTerm via #``foo``.get(0)

Previously it was:

  • a SyntaxOrTermWrapper via ctx.next().value
  • a Syntax via #``foo``.get(0)

I'm not a fan of macro authors needing to know about two different representations of the syntax, but I'm not really sure what else to do about it. Maybe the distinction can be papered over by a higher-level API macro authors import in? Maybe we modify SyntaxOrTermWrapper to behave a bit more like a Term but with the inner method still being special?

Assignee
Assign to
Time tracking