Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Better syntax support for user-defined "functions" #1480

Closed
myitcv opened this issue Jan 17, 2022 · 2 comments
Closed

Better syntax support for user-defined "functions" #1480

myitcv opened this issue Jan 17, 2022 · 2 comments
Labels
FeatureRequest New feature or request

Comments

@myitcv
Copy link
Member

myitcv commented Jan 17, 2022

#484 (reply in thread)

Is your feature request related to a problem? Please describe.

Per #484, user-defined "functions" are somewhat clumsy right now in that they have to be defined via something like:

#udf: {
  #foo: string
  out: "\(#foo)bar"
}

"quux": (#udf & {#foo: "foo"}).out

with named parameter fields and an output field

Describe the solution you'd like

Per @mpvl, something like this could work:

#udf: {
  #0: string
  
  "\(#0)bar"
}

"quux": #udf("foo")

which uses a combination of numbered definitions as parameter fields and an embedded scalar as the result.

Open question: how struct values would work in this case.

Describe alternatives you've considered

The workaround described above.

Additional context

n/a

@myitcv myitcv added the FeatureRequest New feature or request label Jan 17, 2022
@madhadron
Copy link

Would something closer to Prolog be more general and more useful? A first cut:

{
    n: 42,
    paddedN: s |- pad10 & { out: s, n: n }
}

pad10 { n: <10, out: "0\(n)" }
pad10 { n: >=10, out: "\(n)" }

where |- is a "given that" sign. The expression to the left of |- is evaluated after the expression on the right is unified. Then we can write things like

s |- (s<100 & pad10 & { out: s, in: n }) | s="too big"

This kind of layering of guards and conditionals is something we would do in a sequence of expressions in an imperative language. In Cue right now, it has to be moved somewhere else in the program instead of being kept local to the value.

@myitcv
Copy link
Member Author

myitcv commented May 4, 2022

Closing this in favour of #943, specifically the first section "Functions"

@myitcv myitcv closed this as completed May 4, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
FeatureRequest New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants