Open bluejay77 opened 6 years ago
@bluejay77 I trimmed down your code mainly by removing comments. It's easier to diagnose when we have only the code that causes this particular problem. If the defclass
macro is blowing up, then we probably only need defclass-macro
, create-class
, process-slots
and putp
to reproduce the error.
Also, I'm not getting the error with the version of shen-cl/sbcl that's current in the master
branch. We can try this again once we've merged in the fix for #13 , since this approach to oo uses lisp.
native calls.
@tizoc I just tried loading the above code with the latest in master
(with #15 merged) and got this:
(0-) (load "oo.shen")
putp
getp
defclass-macro
oo.process-slots
instance
oo.type#o-o
oo.attribute-type
class?
oo.create-class
instance
assign
cl-slots
cl-parents
cl-name
make-instance
iget
iput
The function COMMON-LISP-USER::oo.lisp.get is undefined.
The macro would have converted this to (protect GET)
and prevent the parser from trying to qualify with the package name. The package prefix must get added after macros are applied, but before the code gets compiled.
Is this a problem introduced by the change from earlier or is this the expected behavior? Does one have to list every external symbol in the package declaration? I never completely understood the package macro.
I didn't think about this when making the change, but yes, the behaviour change comes with the modification.
Not sure about what the "correct" behaviour should be, in Shen/Scheme it behaves as you are seeing now, the idea being that the scm.
prefix is just a namespace, and not something special, so like with everything else you have to list scm.
prefixed functions in the export list if you want to use them inside a package (see https://github.com/tizoc/shen-scheme/blob/master/src/compiler.shen#L8-L10 for an example).
I like how that works, but I understand that it is not very convenient, and breaking the old behaviour is a problem. What I'm thinking now is that Shen/CL could override sysfunc?
so that it checks for the lisp.
prefix in addition to the list of functions being declared as system functions. That solves the issue you are seeing here while providing a better error message (this is something that in the old version would fail anyway but with a confusing error like [protect UPPERCASENAME] is not a legitimate function name
).
I'm going to do that in Shen/Scheme because I just noticed that by not doing so I leave open the option of overriding native functions, and that breaks stuff:
(0-) (define scm.+ X Y -> (- X Y))
scm.+
(1-) (+ 1 2)
-1
What do you think? sounds good?
What I'm thinking now is that Shen/CL could override
sysfunc?
so that it checks for the lisp.
I guess that would work in this case.
(I get a little confused about the behavior of the package macro and prefixes here...)
What about non-interop functions? If I have a package p
and a package q
and I refer to p.f
inside of q
, would I have to declare p.f
in the export list for q
? Otherwise, I'd have to refer to it as q.p.f
while in q
, but just p.f
outside of a package? And if f
was in the export list for p
, where it was defined, it would never need a prefix? Could sysfunc?
just always return true for a symbol with a .
in the name?
(Deleted some ranting until I better understand the issue)
You have to declare everything that is not a sysfunc in the export list, otherwise it is going to be prefixed. For names internal to other packages you can just use (internal package-name)
to obtain it instead of having to list everything:
(0-) (package test-1 [exported-func]
(define internal-func X -> X)
(define exported-func X -> X))
test-1.internal-func
exported-func
(1-) (external test-1)
[exported-func]
(2-) (internal test-1)
[test-1.internal-func]
(3-) (package test-2 [exported-func-2 | (internal test-1)]
(define exported-func-2 X -> (test-1.internal-func X)))
exported-func-2
(4-) (exported-func-2 1)
1
(5-) (internal test-2)
[]
(6-) (external test-2)
[exported-func-2 test-1.internal-func]
Note that internal
will not work with shen.
prefixed functions (that data is not keep around). It is not great, but it works.
Consider that It is not something we should change anyway, it would just make Shen BSD incompatible with Shen Professional, so just accept it for what it is and don't get stressed over it.
If I were to use Shen for bigger programs I would probably just write my own thing to better organise code instead of depending on package
, which is just some useful but rudimentary functionality provided by a few lines of code in the kernel.
@tizoc Seems weird to me, but not a huge deal. I never written enough Shen to need packages.
The lisp.
prefix issue I noticed while looking at this unrelated issue, so I think we need to issue a new issue and move this there.
@bluejay77 I forgot for a moment that this issue is actually about the error The value #<BASIC-CHARACTER-INPUT-STREAM UTF-8 (TTY/0) #x3020006233FD> is not of the expected type (AND INPUT-STREAM CCL::BINARY-STREAM)
.
I haven't been able to reproduce this with ccl, sbcl or clisp using what's currently in the master branch.
Have you seen this more than once? Does it happen reliably? It might be something with your terminal - do you use anything special for your terminal? What OS and OS version are you using?
I have seen the error several times. It happens repeatedly. The terminal is a standard one I think.... Will try to change it to another one, however. I use the Debian Linux, I think v.9.4.0.
AJY
I changed the terminal to another one. The "mystic" error will not occur any more.
Weird. Bug with the Linux Debian? I don't know!
AJY
FYI, I was able to reproduce this on Ubuntu (derived from Debian).
This appears to happen when all of the following conditions are met:
track
-ing with (step +)
I m creating a Shen OO capability based on Paul Graham's book On Lisp, Ch 25, Object-Oriented LISP.
A version of this capability is in the file oo.shen.
An attempt to track the function (create-class...) makes Shen crash:
yours, Dr Antti J Ylikoski Helsinki, Finland, the EU
I did not find a way to attach a file, I will insert the Shen code below: