I'm having more trouble understanding deftype. (I'd never come across it so far in my common lisp experience.) I couldn't tell what the benefit would be of your ((tags 'posnum) 0) examples over just a simple predicate. Won't it only be useful if arc actually got optional typing like common lisp?
(Also, I assume you're familiar with arc's approach to types using annotate and rep?)
Try to think of it as an add-on, not a replacement. If you were to rewrite "isa" to first check if the type you're checking for is the builtin expression type or the tag, and if it's not, lookup the symbol in the "tags" table. If the key is not bound, it returns nil. If the key is bound, apply the predicate bound to the key to the value supplied to "isa".
In my opinion defextend is fine the way it is, it has its similarities to CLOS's defmethod, which I would avidly abuse in my earlier lisp days.
The positive thing about adding a tagged predicate dispatch table, if implemented into "isa", would be the illusion of any object being a particular "type", provided it satisfies the predicate. In reality, the true type of the object would be cons or sym or whatever its value is.
One simple idea: The int/num difference could theoretically be moved into arc codespace via deftag. Primarily leave the number type "num" internally, but deduce if a number is an "int" via the tags table.
Example:
(deftag int
(and (isa _ 'num)
(is _ (round _))))
(isa 1.5 'int) => nil
(isa 1 'int) => t
One cool thing you could do is define tags for something like an object descriptor, or a class. Store whatever you need in cons cells, along with maybe a symbol at the head named "class:" or something, with "slots:" or "methods:" in that class. This could easily be checked if a particular cons resembles a "[class]" structured cons via a predicate, right? So deftag a predicate for "class". Then check if your object is a class-structed cons via "isa".
tag and isa already mean something in anarki. Any suggestions on how we integrate the existing type support with deftag? Feel free to send a pull request!
In truth, it's been about 5-6 years since I've collaborated on anyone's code that isn't my own. I'd love to submit a pull request :) I'm installing Racket & Anarki on this windows machine this morning to see about getting a working version. Do you think "deftype" would be ok for the macro name? Any other suggestions? Maybe something in the spirit of original Arc, like "pred" for predicate or something?
I think you're in the best position to judge :) Maybe play with a little example program and see what looks best in its context? If it doesn't seem to matter just pick one. We can always change it later.
I have to admit, I'm not sure how long it's been since somebody tried installing anarki on windows. Let me know when you run into problems. I'm actually amazed that I was able to get mtl running on linux so easily. Are you using cygwin?
No, I can't stand Cygwin. I actually wrote the original 1200 lines of the interpreter on Fedora. My goal was to try to keep it completely portable C code. As of right now, on my machine, I create a Win32 Console app in Visual Studio to compile MTL on Windows, and it works just fine. Initially I had some segfaults, but it was mainly due to the lack of exception checks and null checks... So as far as I can tell, it's pretty much cross platform at the moment.
In the few minutes I've used anarki, it seems to work just fine :) I just run it in the command-line Racket app by running:
Playing with it some more, I have a few ideas/tweaks :)
1. Maybe we should rename deftype to def-isa since it only overrides isa, not type or coerce? That would also fit with how we use defcall to extend coercion to function, defcoerce to extend coerce, defset to extend assignment, etc.
2. I'm thinking of renaming the types table to type-predicates.
At the same time, I kind of feel like having a dash makes it deviate a little... And "defisa" just doesn't look right in my opinion. Do you think having a slight variance would be ok?
Thanks! I see it now. Amazing how much difference it makes to see it working in a known context.
I figured out why '=' wasn't working; we were redefining it further down the file. I fixed it by moving deftype to later, and now we can go back to '='. https://github.com/arclanguage/anarki/commit/2c12a9e4f8. Does that seem reasonable?
Essentially the syntax is the same, but with one difference: If the body of the bracket function ONLY consists of a dotted expression, the body of the function IS that expression. Example:
I mainly took this step to take advantage of having support for multiple "dots", Example:
x.car.type => (type (car x))
It's just more readable in my opinion. In regards to the second part of your post, it's because of a bug in my number reader, which I'll fix soon. Thanks for pointing it out!
I plan to add n-expression support into bracket functions, too. It would make the following work:
I've criticized sweet-exprs in the past as trying to do too much (https://news.ycombinator.com/item?id=8507385). But the original subset you're implementing here is very useful.
(I'm still opposed to neoteric expressions, because parens before function is The One True Way, especially in the presence of infix: http://arclanguage.org/item?id=16924. But I won't agitate for it again since n-exprs are optional :)
BTW, in searching for the above link I ran across http://arclanguage.org/item?id=18261, which you might find interesting if you hadn't already seen it.