Enums

[Capt0rr]

Curious why there is no enum of any kind in Rye? Was this intentional or just hasn't arrived yet? If intentional what's the rationale?

[refaktor]

a very very short answer is that enums a sometimes times replace string and integer constants, but Rye (like REBOL) has first class words, which are indexed items (integers behind the scenes).

Enums are also used to enforce selection and exhaustive selection (for example some languages require you to switch on all possible values of enum, to prevent bugs). Since Rye is not statically typed, there are less mechanisms or convention to do that, since other things are not checked at "compuile time" either since there is no compile time.

Havin a way to determine, X must be one of these { a b c } would also add information and be a tool in Ryelang, but it's a question if that if solved with sort of setup early binding way, like enums is. Or in a more late-binding way, what is more a direction of Rye and other dynamic languages. We would want to have a way to make sure certain value is of a limited set of values, but probably it would be solved in a Rye-ish way by using validation dialect. Validation dialect can be tied to kinds (something I haven't demonstrated much so far, but it's there, the whole kinds , validators , convertors thing) and Kinds sort of enable something like early bind enums, with possibility of all the other validation rules also.

This means we should add to validation dialect something like validate { one-of { a b c } } (or any-of) and probably also { some-of { a b c } } for "multichoice" values.

Then I should document kinds more, with examples how to use this.

Do you have any Rye example where enums would benefit you? If you have, I would be glad to see it, so I can think about this more ...

Thanks for making me think about this ... sometimes I need some external motivation!

(I wanted to write a short answer first but got carried away) :)

[Capt0rr]

thanks for the detailed response :).

I was just playing around with tables and realised there's no nice, and safe, way to specify valid table field values:

; using strings
scopes: table\rows { 'id 'kind 'text } {
	{ "S1" "in" "{What's included}" }
	{ "S2" "out" "{What's explicitly excluded}" }
}

; using free-floating/global vars:
in: 1
out: 2
scopes: table\rows { 'id 'kind 'text } {
	{ "S1" in "{What's included}" }
	{ "S2" out "{What's explicitly excluded}" }
}

; using context
scope-dir: context {
	in: 1
	out: 2
}

scopes: table\rows { 'id 'kind 'text } {
	{ "S1" scope-dir/in "{What's included}" }
	{ "S2" scope-dir/out "{What's explicitly excluded}" }
}

context is too heavy for this, but even if there was a lightweight namespace word it's still too cumbersome to spell out scope-dir/in every time, or wrapping everything in do\in scope-dir everywhere.

You make a good argument though. And I do like the idea of a validation dialect. But enums to me are too ubiquitous so I always reach for them. And they are a very simple and powerful way to write safer code by default, which is what Rye aims for. A validation dialect you still need to remember to call it everywhere.

I need to think about this some more.

[refaktor]

Thanks for the example and additional info and thoughts. Do you want the column in the background to literally be 1 and 2 (ints) or can it just hold symbols?

// update:
With kinds ... to you define a certain table kind, you define a validation rules for the columns. And then the validation is applied automatically to that table. I don't have it implemented for tables yet, but I did have it for contexts years ago. Didn't use it that much yet, because that is one level higher feature above the base language and I was mostly still dealing with language.

[Capt0rr]

symbols is fine for some cases but for other cases it is often useful to be able to treat them as ints as well. Standard C style stuff.

[Capt0rr]

Ah I remembered that there was an issue with symbols in table values. I got AI to drill into it and summerise as it's a tricky non-obvious behaviour, perhaps even a bug or misfeature:

The issue: literal table data and query

arguments live at different evaluation levels

In a table literal:

  table { "state" } { pending }

the row block is data, so pending is stored as a
Word.

  table { "state" } { 'pending }

stores a Tagword (Rye’s literal-symbol form).

But a normal filter argument is evaluated. For
example:

  ... |where-equal "state" 'pending

evaluates 'pending into a Word before where-equal
compares it. Equality is type-sensitive: a Word is
not equal to a Tagword, even if both spell
pending.

Fresh runtime check:

  table { "state" } { pending }  -> cell type:
word
  table { "state" } { 'pending } -> cell type:
tagword

  table { "state" } { pending  } |where-equal
"state" 'pending -> 1 row
  table { "state" } { 'pending } |where-equal
"state" 'pending -> 0 rows

So a tagword-valued table cell is awkward to query
through the ordinary table API: the query
naturally supplies a word, not a tagword.

Why bare words are also a poor choice for

ordinary categorical values

Bare words in a literal table happen to be
queryable using a quoted/tagword query value, but
they still encode syntax/runtime identity, not
plain data:

• pending is a Word, rather than text.
• It can be confused with a variable reference
  when moved into evaluated code.
• Query authors must know the non-obvious
  convention: use 'pending to produce the query
  Word.
• Comparisons, serialization, and transformations
  can preserve or alter Word/Tagword identity
  rather than just the apparent spelling.

Recommended convention

Use strings for row values that are labels/enums:

  items: table { "id" "state" } {
      "T001" "pending"
      "T002" "done"
  }

  items |where-equal "state" "pending"

Use tagwords/words for column references, where
Rye’s table API expects them:

  items |where-equal 'state "pending"
  items |where 'state { = "pending" }

Column headers themselves may be strings or
tagwords—the table constructor normalizes headers
to string names—though strings are generally
clearest:

  table { "id" "state" } { ... }

The relevant implementation is in:

• env/object.go — Word.Equal and Tagword.Equal
  require matching types.
• evaldo/builtins_table.go — where-equal uses
  type-sensitive val.Equal(...).
• env/spreadsheet.go — table rows retain their
  supplied values rather than normalizing them.

So the precise statement is:

│ Do not use symbols/tagwords as ordinary Rye
│ table cell values unless you deliberately want
│ syntax objects and control every producer and
│ query. Use strings for enum-like data. Tags
│ remain appropriate for column names/references.

[refaktor]

Yes, this has to be thought about and made cosistent. Thanks for exposing it, I will work on this and let you know.

[refaktor]

I will start with adding one-of and some-of to validation dialect.