I was wondering what the equivalent of I7 adjectives are in other programming languages, or since it seems like I7 adjectives can do different things maybe it’s not a one-to-one comparison?

For example I7 adjectives can be like boolean properties (open or closed), enumerations (kinds of value), predicates (definitions), and so on…I must be missing a couple? Could you call an I7 adjective an interface in OO terms too?

Maybe I shouldn’t be posting this at 1am, but if I’m following you correctly, I’d say the closest thing is variables. The associations and relations of I7 adjectives is what sets them apart from most other languages, because they’re geared for telling stories. I’ve found some amazing similarities in I7 to PHP, including how strings and functions are structured, and even how lines of code are separated. Booleans are in PHP, as variables. PHP doesn’t have enumerations, but allows you to create them, just like you can create new functions in I7 (as scenes). This shocked me when I learned how robust I7 can actually be. I knew you could do cool things with it, but I always thought it was limited to its own properties and classes, with some customization. Predicates work the same way, and I’ve found I7 to be just as robust as PHP in sorting out complicated variable structures, with a lot of variables passing through each if statement.

Sorry – could you expand on this question?

I’d say an adjective is a boolean function or property. (There isn’t really a difference between an object property and a function on objects, if you take a really high-level view. The details are important, but then I7’s details are pretty different from other languages – there’s no exact equivalency.)

…Make that a function/property onto an enumerated type, when you get into “A thing can be red, green, or blue” territory.

If it were me, I would have called everything a predicate and worked from there. I7 has wound up with properties, definitions, phrases-on-objects, and relations – all of which are different flavors of predicates – and it makes things unnecessarily confusing.

It may be clarifying (or maybe confusing) to point out that I7 adjectives can come from different language structures. You can write either

Definition: a thing is tasty if …

A thing can be tasty or nasty.

The first is a definition, the second is a property. Both of these create an adjective “tasty” (applicable to things) but with different affordances. So maybe “an adjective is a predicate” is the best answer, but then it’s not a first-class entity in the language – it’s always derivative.

From a nuts-and-bolts (As opposed to curves-and-equations) kind of way of looking at it, adjectives are somewhat like a language construct for getting at properties of objects, not entirely unlike a method. They may act as simple getters/setters (‘now the morsel is tasty’) or as a more complex method that looks at state and gives a boolean value (definitions).

The interesting thing about adjectives, though, is that they essentially act as qualifiers on types in a way that other languages don’t have. Inform permits:

To taste-describe (morsel - a tasty thing):
  [do something]

To taste-describe (morsel - a nasty thing):
  [do something completely different]

Which, while obviously not hard to replicate in a language that supports the more normal kind of overloading, is somewhat unique as far as I’m aware.

@Sequitur, that’s interesting, I never thought of I7 having a kind of multimethod like that – can you add conditions to that, like a ‘a tasty thing in the kitchen’?

@craftian, I had just read , it’s probably a stretch to apply that to I7.

@George: I think so, although you might have to use a “with” clause.

This example works:

"Compulsive Eating"

A thing can be tasty. A thing can be edible.

Food is a kind of thing. Food is always edible.

Kitchen is a room.

A towel is in Kitchen. A tub of library paste is in Kitchen. The library paste is tasty.

Food called some okra is in the kitchen. Food called some liver is in the kitchen. Food called some lutefisk is in the kitchen.

Tasty food called an apple is in the kitchen. Tasty food called a mango is in the kitchen.

Instead of eating something not edible:
	say "I know you're hungry, but no."

Instead of eating something tasty which is edible:
	remove the noun from play;
	say "You eat [the noun]. Om nom nom."
Instead of eating something edible:
	remove the noun from play;
	say "You eat [the noun]. Yech."
Every turn when in the kitchen:
	if an edible tasty thing is in the kitchen:
		let the morsel be a random edible tasty thing in the kitchen;
		try eating the morsel.
Test me with "z / z / eat lutefisk / eat library paste / z"

In particular, Inform handles the complicated phrase ‘random edible tasty thing in the kitchen’ as you would expect.

If your when/which clause gets too complex you can also use “the noun” to refer to the object in question.

Nitpick: I would argue against marking lutefisk as “edible”. But that’s beside the point.

“Food is usually edible. Food called some lutefisk is in the kitchen. Lutefisk is not edible.”

That looks better. :stuck_out_tongue:

This is a slanderous misapprehension that will not stand unchallenged. Lutfisk is great stuff although it’s practically flavorless; you’re most likely thinking about surströmming or possibly that vile artifact of putrescence known as hákarl.

Well first off, a boolean is an enumeration. Programming languages don’t generally consider them in that light, since it’ll add special-case stuff that only bools can do (like be the condition of an ‘if’ statement all by itself), but conceptually they’re the same thing.

I think Inform 7 considers an adjective to be something that returns an enum. Whether it is storage (like a variable or property) or computed (via a function or “Definition:”), it is immaterial.

Inform doesn’t support interfaces, but if it did I could certainly see it.