interface for cando

[Bike]

Since cando and clasp have grown out of the same project, cando uses clasp "internals" quite generously. It would be more convenient for maintenance if cando used a defined interface to clasp, so that what cando uses can be specially protected during clasp development.

From a quick grep, the cando lisp code has 192 uses of the core: package. (The cando C++ code's use of clasp internals will be a whole other kettle of fish.) Those uses are as follows:

• 94 uses of core:make-cxx-object. This should probably be exported from a defined Clasp system for C++ interfacing.
• 12 uses of core:native-vector<int> related operators. Not sure what's going on with those, but could be an extension.
• 8 uses of core:bformat. Some of these are used in logging and this should probably be replaced with cl:format if possible. There are also uses in the Fortran printer. I don't know if cl:format can handle that, but hopefully it should be adequate?
• 5 uses of core:split. This function seems to have the same basic operation of the Lisp split-sequence library (https://github.com/sharplispers/split-sequence), which could be used. split is kind of a general utility function so having it as part of clasp's interface would be a little weird, but we could do that too. There is also one use of core:split-at-white-space.
• 2 uses of core:proper-list-p, which has similar issues.
• 5 uses of core:encode. Could probably go with core:make-cxx-object?
• 5 uses of core:getpid, 3 of core:num-logical-processors, 1 of core:fork, 1 of core:fork-redirect, 1 of core:sigchld-count, 1 of core:wait, 1 of core:wifexited, 1 of core:wifsignaled, 1 of core:wtermsig, 1 of core:lseek, 1 of core:read-fd, 1 of core:close-fd, 2 of core:mkstemp-fd, 7 of various core:sig functions, 3 of core:chmod. These are all POSIX related functions that we should export from a dedicated POSIX interface.
• 1 use of core:strftime, which doesn't actually seem to be defined anywhere, but which would presumably be an interface to the unix function.
• 2 uses each of core:argv and core:argc, and 1 of core:*command-line-arguments*, which should be made into an exported interface.
• 4 uses of core:quit. This has already been moved to the ext: package, i.e. calls to core:quit can and should be replaced with calls to ext:quit. There are also 11 uses of core:exit and 1 use of core:c_exit; these functions may be redundant?
• 3 uses of core:is-interactive-lisp. This is kind of an ill defined function that should be reevaluated.
• 1 use of core:top-level, Clasp's top level REPL function. This could be a defined interface.
• 1 use of core:make-ff-nonbond. I think this is a typo and the chem: package was meant.
• 1 use of core:leap-command-line-includes and 1 of core:leap-command-line-scripts, which I don't see defined anywhere, but presumably would relate to LEAP rather than to Clasp.
• 1 use of core:call-with-stack-top-hint. This should probably use clasp-debug:with-capped-stack instead. I'm not sure core:call-with-stack-top-hint even works any more.
• 1 use of core:*make-special. (core:*make-special foo) can be replaced with (setf (ext:specialp foo) t), I think.
• 1 use of core:symbol-global-value-set, which could be exported as (setf ext:symbol-global-value) or something if actually required.

There are also a few uses of core:*read-hook* and related, but hopefully those are being removed soon.

[kpoeck]

As a tiny start, we already export from ext the following (in init.lisp )

• getpid
• argc
• argv
• rmdir
• mkstemp
• weak-pointer-value
• make-weak-pointer
• weak-pointer-valid
• hash-table-weakness

since I found them in either:

• asdf
• or slime
• or trivial-garbage

[yitzchak]

If the use of core:make-cxx-object is to create an object in the chem package I suspect that it is just missing some kind of make-? function or is a reference before one was added. Even if we still use the equivalent of core:make-cxx-object we probably want to at least hide it behind a lisp make-? function for that sake of end users.

[yitzchak]

For instance (chem:make-aggregate) is available versus (core:make-cxx-object 'chem:aggregate)

[drmeister]

This is really nice - please proceed to simplify the interface but don't break anything.

[yitzchak]

FYI the leap-command-line-* functions are actually in core. https://github.com/cando-developers/cando/blob/2614173783b025bec7f9596f7467258473a15936/src/main/extension.cc#L80

Maybe they should be moved?

[myonkunas]

The use of core:*read-hook* has been tested with minimal performance degradation and removed. Merged here: https://github.com/cando-developers/cando/commit/883a6298c98c6cea45c15e302ee43742cbacac91

[Bike]

In 7e0724867e79bd428fe4bbcc2dc34079b329b34d I have created a clasp-posix package. For the moment it just reexports some stuff from core (and ext) and those symbols remain where they are, so it's backward compatible

[yitzchak]

I can start rolling in the clasp-posix package into my open PR over in cando.

[Bike]

Whoops, I didn't export the sigset stuff cando uses. Done in 5cdabf66e1de344b68ab8f879da37c9ab64378ed. I also didn't export num-logical-processors since it's not actually part of posix (or at least not under that name)

Some of these names could probably be shortened. "sigset-sigaddset"? but that can be for later.

[yitzchak]

What about getpid?

[yitzchak]

I guess I could get it from ext?

[Bike]

i have exported that from clasp-posix as well now

[yitzchak]

Instead of exporting core:make-cxx-object in another package what about just defining a make-instance method?

(defmethod make-instance ((class core:cxx-object) &rest initargs &key &allow-other-keys)
  (apply #'core:make-cxx-object class initargs))

The CLHS says an error should be thrown when make-instance is called on built-in-class because those have restricted capabilities. Instances of cxx-object can be created using make-cxx-object so it seems like having make-instance defined in this case would make sense even though they are a subclass of built-in-class.

I am sure there could be something I don't get about the internal implementation details, but just a thought.

[Bike]

we don't even need to have cxx objects be a subclass of built-in-class, really. we could probably support things like slot-value on them if we wanted to. I don't think there's any standard reason to prevent us from extending make-instance in the fashion you describe.

Unfortunately, while I understand the internal implementations of our CLOS fine, and on that level there is no technical barrier, I haven't really used the CXX stuff much at all and don't have a good idea of how it works.

[yitzchak]

Unfortunately my method doesn't appear to work currently. The method associated with built-in-class seems to take precedence. If cxx-object isn't a subclass of built-in-class then that would probably not be an issue.

[Bike]

Oh, if you're using that method literally, it won't work. make-instance's first argument is the class you're instantiating, not an object. I don't remember what (class-of (find-class 'core:cxx-object)) is off the top of my head, but you want to specialize on that.

Putting methods on make-instance will also implicate the very special optimizations I put on make-instance. They should be suppressed if there's a method, but I haven't tested this extensively.

[yitzchak]

Well that makes sense, (class-of (find-class 'core:cxx-object)) reports #<The STANDARD-CLASS BUILT-IN-CLASS>

[Bike]

I see. In that case we'd have to replace that with a core:cxx-class or something. I think that could be doable. Though it would probably implicate some scraper stuff that's dicey to mess with.