What to Do About FUNCT (including "Not Calling It That")

Development Naming
3

Red incorporated it for their FUNCTION as well:

red>> f: function [] [do [x: 10]]
== func [/local x][do [x: 10]]

I advocated for FUNCTION taking this behavior when I knew less. Having seen the damage, I think it's a dead-end idea and we need to drop it. So I'm glad you agree it is bad.

However, I still think the following aspects are important:

  • Being able to spontaneously make local variables without communicating with FUNC is important (e.g. something like USE needs to exist)

  • Being more efficient than historical USE is important (R3-Alpha does a MAKE OBJECT! and then has to deep copy and rebind the block to the new variables).

  • Not needing a new level of indentation just to introduce a variable is important.

My goal is to make LET meet these needs.

If you look at the TLS emit example, you'd not be able to use it as a variable declaration surrogate like:

emit ctx [
  TLSPlaintext:
    #{16}
    min-ver-bytes
  fragment-length:
    #{00 00}
]
...
change fragment-length enbin [be + 2] (length of Handshake)
...

You'd have to take a separate block of code as a parameter:

emit ctx [
  TLSPlaintext:
    #{16}
    min-ver-bytes
  fragment-length:
    #{00 00}
] [
    ...
    change fragment-length enbin [be + 2] (length of Handshake)
    ...
]

I feel like variable declaration is something you might commonly want to abstract, and tying such an abstraction to "thou shalt make a new block" doesn't play to the master-of-disguise concept of the language.

Not that you can't choose USE or its ilk. But I think you'd be in the minority for preferring it.

But the devil's in the details...making LET-like functions work is an exploratory and experimental thing that I am only starting to get my head around. I think there's hope for it--although it may force us to rethink the garbage collection method (which needed rethinking anyway).

2 Likes