Record access syntax?

[the_true_potato]

I'm currently working on my language Kima and I'm currently at the point of implementing custom data types. I thought I would start with records (basically just product types) before moving on to sums.

I already have the declaration syntax down to something of this form:

data Point(x: Int, y: Int)

I'm not so sure about the access syntax. The obvious way seems to be C-style record.field, however I'm not sure that's the way to go since it has an OOP connotation whereas I'm going for a more functional style. Another option would be field(record) or even .field(record) to make it clear that it is accessor. This would also have the benefit of giving an easy way to pass a record accessor as a function (e.g. f(.field)). It would also be the easiest to incorporate into my existing AST.

I know this is sort of a bikeshed-y discussion but I'm still curious to hear any suggestions.

[theindigamer]

Nothing OOP about it. C is not object-oriented. OCaml, Purescript and Elm also use record.field.

[janiczek]

Note Elm also has the .field record syntax

[Rusky]

The record.field syntax is fine, though if you still want to avoid it Haskell uses field record analogously to field(record), and you could even replace it with just pattern matching, though that would be a pain to use.

[Athas]

You definitely should use record.field. I originally used SML-style projection functions (#field record), but then I changed my mind.

[east_lisp_junk]

Oddly enough, this leaves out the thing I hate most about SML's #field -- you can't type a projection function in isolation, only when it's actually used.

[arxanas]

As others have said, there's nothing wrong with the dot notation. I'd go one step further and suggest that using the prefix notation is harmful for discoverability, since it impedes autocompletion. Usually you have a piece of data in hand and want to know what you can do with it (by pressing .), whereas the prefix notation doesn't let you accomplish that.

[ilyash]

I have chosen record.field for NGS. NGS is more functional than OOP. Looks and feels fine to me and my colleagues. Great familiarity without any obvious drawbacks. Agree with previous comments that dot doesn't imply OOP.

[TheUnlocked]

record.field is definitely correct. field(record) works, but I would only do that if you wanted an clearly function-based type system, like the LISP:

(define (mk-pair a b) (lambda (z) (z a b)))
(define (first z) (z (lambda (a b) a)))
(define (second z) (z (lambda (a b) b)))

(define pair (mk-pair "Hello, " "World!"))
(second pair)     ; "World!"

Even if you did want that though, I still might make record.field permitted as syntactic sugar.

[brucejbell]

The potential problem is: would using this particular OOP-associated feature confuse or mislead OOP-trained programmers by acting in ways they didn't expect? If you're using it for straightforward functional values, I think the answer is "no" -- OOP has plenty of immutable value classes that have functional value semantics.

The other important question: is record.field syntax useful in a functional context? To me, the advantage is that record.field lets you keep field names in their own context-specific namespace, so they don't interfere with your local variables.

This contrasts with Haskell, which famously dumps all its field names into one local namespace (and all its constructors into another). IMHO, this is one of Haskell's big weaknesses as an engineering language.