Kernel core

[causal-agent]

I've no idea how to determine when the core is "done".

[solson]

• [ ] String functions (including regex functions)
• [ ] I/O functions
• [ ] File/Dir/FileUtils functions
• [ ] Socket functions
• [ ] System functions (exit, shell commands, sub-processes, etc)
• [ ] Macros for creating or extending Ruby classes and modules (and macros for defining methods)
• [ ] Structs
• [ ] Ruby interop helpers (I'm thinking macros to make interacting with DSLs much prettier)
• [ ] Date and time functions
• [ ] Threading/concurrency stuff
• [ ] Random number generator functions
• [ ] Enumerable/Enumerator functions

We should probably avoid wrapping every little thing. It's a waste of time to define (defn length [x] (.length x)) when we can just type (.length whatever)... So maybe some of the above won't really need to be added to the Apricot core, but we should take a close look at all of them.

[ekd123]

I'm wondering if Apricot will be compatible with Clojure's core?

I'm thinking that defining methods (for Lisp classes) whose names are started with "." is a good way to say "It's a method". Unfortunately, it's impossible in Clojure.

If Compability is not the thought, we might start doing something good and different.

[causal-agent]

I'm not sure what you mean. . works the same way in Apricot as it does in Clojure, it is impossible to call a function whose name begins with . because it would be expanded to the (. object method ...) special form.

[ekd123]

Then comes the problem: they are both routines, but some of them are just in the host, why are their names different? (though it's easier to be parsed..)

[causal-agent]

I'm still not sure what you mean. The (.method object) shorthand is used to call methods, which are different from functions.

[solson]

@ekd123 A code example showing what you're envisioning would help.

About compatibility... full Clojure compatibility is less likely, but we have considered it. On the other hand we intend for it to be very easy to to translate Clojure code into Apricot (by having the same features such as destructuring, the same function/macro names, and so on). But we will add more where it makes sense and leave out stuff that doesn't make sense in Apricot.

[ekd123]

(defmulti .writeToTerm class)
(defmethod .writeToTerm String [x] (println x))

In this case, .writeToTerm should be considered as a method of String.

[solson]

Well, right now we have this implemented:

(defmethod String write_to_term [x] (println x))

I don't see the advantage of using a . in the name.

[solson]

I left out an important bit of information. Apricot's current defmethod defines methods on Ruby classes, and we don't have protocols or multimethods yet.

[canweriotnow]

Are datetime fns still up on the air? If so, this is something I could volunteer for.

[solson]

Yes, everything in the list up above needs work (most of it doesn't exist at all). Knock yourself out!

[canweriotnow]

Sweet... I've driven myself mad w datetimes, I'd love to see some payoff in something cool like this :smile: