Proposal: is `@` notation worth it?

General
1

Is the syntactic sugar useful enough to justify its existence? What problems might be caused by including this? Are there more elegant ways to get the same behavior without adding new bells and whistles?

2

By @ notation, are you referring to the part where it’s used to specify the version ? (It looks like it’s also used to prefix the namespace in a few spots in the guide, when the namespace is a string?)

I think it’s useful, but I also can’t imagine using scrapscript and not fixing the version on everything I use. It seems like a lot of trust would be required to have things automatically use latest versions.

Maybe should be a separate topic, but I don’t think a strong type system by itself is enough of a gaurantee to make me comfortable about freely updating all deps to latest in the background. It’s pretty simple to make malicious updates while maintaining a fn signature. e.g. Any function returning a string could easily be updated to return entirely different data while maintaining the type signature.

3

I don’t think the @ and / should be different in function, just have semantic differences. ngp/myfunc/v123 should be functionally the same as ngp/myfunc@v123. I agree, pinning versions should be the norm. I’m hoping there can be tools to make bumping versions and delegating trust to maintainers or specific groups easy, but having things be open by default is a recipe for disaster.

4

I agree with everything you and @ngp said, but I was talking about the @ symbol in this section :slight_smile: sorry for not being more clear.

I’ll post the section here for posterity:

Sending Scraps

Send flat scraps via HTTP using the application/scrap MIME type:

$ brew install httpie
$ echo '"hello"' \
  | scrap eval \
  | scrap flat \
  | http -b POST connie2036.com/echo \
      Content-Type: application/scrap \
      Accept: application/scrapscript

"hello"

If you’re using a platform that supports it (e.g. remote), you can also use do
this:

$ echo '"hello"' \
  | scrap platform remote apply '@connie2036/echo'

(result text remote/error):ok "hello"

If a platform doesn’t know what to do with the remote type, it’ll just treat it
like any other type:

$ echo '"hello"' | scrap eval apply '@connie2036/echo'

@connie2036/echo "hello"

In the following example, connie2036/echo defines a contract between the
systems. Note that the server expects text as its request and response types.
If the server sends a different response type than expected, the scrapscript
runtime will fail gracefully on your behalf.

connie2036/echo

{ location = remote/http-post "https://connie2036.com/echo"
, request = scrap/type:text
, response = scrap/type:text
}

$ echo '123567' | scrap platform remote apply '@connie2036/echo'

remote type error

In these examples, @connie2036/echo is syntactic sugar for building
(remote text text):remote.

$ echo 'remote/fetch ((remote text text):remote connie2036/echo "goodbye")' | scrap platform remote

(result text remote/error):ok "goodbye"
5

I think in that case, I’d personally just go with something else. More room for example code, and I think you could still have it look basically if not exactly the same (could use an ADT, or a function that does the conversion from namespace to remote if it should be explicit, or a wrapper fn that takes the namespace and then calls remote, etc)

1 Like