8000 Implement Singleton Types Using the <wrapper> Mechanism by timor · Pull Request #2499 · factor/factor · GitHub
[go: up one dir, main page]
Skip to content

Implement Singleton Types Using the <wrapper> Mechanism #2499

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
timor wants to merge 8 commits into
base: master
Choose a base branch
from
Open

Implement Singleton Types Using the <wrapper> Mechanism #2499

timor wants to merge 8 commits into from

Conversation

@timor
Copy link
Contributor
@timor timor commented Dec 4, 2021 •
edited
Loading

Allows definition of methods on objects. This supersedes #2486 for the definition of methods on words using

M: \ some-word some-generic ...

but is implemented arguably in a much more intrusive way, since any object can be dispatched on now. This also allows CLOS-like eql-specializers for arbitrary objects. For convenience, a new set of "escaping" words is introduced that creates "anonymous" classes when used in a classoid position:

GENERIC: answer ( x -- ? )
M: object answer drop f ;
M: fixnum answer drop "maybe" ;
M: \ fixnum answer drop "this is a class test!" ;
M: \= 42 answer drop t ;

(EDIT: updated above example to illustrate the difference between dispatching on classes vs. their values)

<wrapper> objects are part of the class algebra with this change, and behave kind of like predicate classes that only dispatch one value. Dependency and definition handling should work correctly, but should probably be tested much more thoroughly...

EDIT:
Updated to work with UNION: classes. Also allows UNION: foo \ foo ;
It is possible though to introduce dependency issues when sorting tests a predicate class against a possibly matching singleton type in the same compilation unit. This is kind of error is caught. The workaround is as usual: Put the first definition into a different or nested compilation unit.

Alternatively, the ability to test class intersection of predicate classes against singleton types could be removed, but then method sorting becomes less convenient.

EDIT2:
There is probably no reason this should specifically make use of the <wrapper> mechanism, except that it is already there and kind of makes sense to me...

@timor timor mentioned this pull request Dec 4, 2021
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

1 participant

@timor
0