libera/#sicl - IRC Chatlog
Search
12:07:31
beach
Bike: Can you have a look at the SICL part of +CLASS-ALIASES+ and see whether it looks right? And, if I understand you correctly, the element type that I give there must be EQUAL to that returned by u-a-e-t, yes?
13:03:54
Bike
beach: is ratiop going to work? to be clear, ctypep is going to be calling ratiop, so if you don't have your own typep this seems like it could be infinite recursion
13:09:00
Bike
in class-aliases. the right hand sides are parsed again, so array element types will be upgraded fine.
13:10:20
Bike
that the upgraded types - whatever upgraded-array-element-type returns - are comparable by equal.
13:10:41
Bike
https://github.com/s-expressionists/ctype/blob/main/carray.lisp#L11 equal is how ctype compares upgraded type specifiers
13:11:36
beach
Can you give an example of two sources of an upgraded type that must give true when compared with EQUAL. Now it sounds like there is only one such source.
13:12:18
Bike
i mean for example if upgraded-array-element-type sometimes returned (mod 8) and sometimes returned (integer 0 7) ctype could not handle it.
14:00:13
beach
Does the ENVIRONMENT parameter of u-a-e-t suggest the existence of multiple global environments?
14:03:12
beach
Still, I can't imagine two different first-class global environments in SICL that would give different return values.
14:05:59
beach
Speaking of which, for WSCL, someone should go through all standard functions to see which ones could have an optional ENVIRONMENT parameter but don't. I find it kind of random in the standard right now.
14:13:20
Bike
mm, that could get weird. for example there are lots of functions that take type specifiers but no environment, but it's not obvious how an environment could be nicely provided - like MAP
14:23:14
Bike
in practice it doesn't matter so much since implementations of typep usually ignore the environment
14:27:57
beach
OK, making some progress. When I attempt to load ctype, register allocation seems to get into an infinite computation. So I disabled register allocation temporarily. Now, there are just a bunch of prerequisites that I need to load (and implement if that is not already the case) first, like MAP, and MAKE-LOAD-FORM-SAVING-SLOTS, and more.
14:33:54
beach
Sometimes it feels like work in SICL is not converging, but I of course realize that has to be the case, since the standard is finite.
14:38:15
jackdaniel
beach: rehashing your remark about multiple details that need to implemented in "full" cl implementation (you've mentioned that you are not surprised that drmeister decided to pick an existing implementation); I think that this could be considered the standard flaw (perhaps not something possible to overstep though) that there are so many corner cases that are specified that it is very hard to come up
14:41:22
Bike
you shouldn't need to worry about make-load-form-saving-slots being called in normal use
14:42:02
beach
OK, thanks. I'll just look into all the compiler warnings and decide which ones need to be addressed.
14:43:52
beach
jackdaniel: The thing that bugs me, and which is one of the reasons for the existence if SICL, is that all these implementations handle all these corner cases in a specific way. Let's hope we can change that with the spirit of the SICL project, i.e., to create independent libraries that handle corner cases in an implementation-independent way.
14:45:36
beach
Though, lately, I have come to realize that, if anyone wants to create a Common Lisp implementation from scratch using these libraries, or alter an existing implementation to use those libraries exclusively, then I have to make the SICL bootstrapping procedure work for arbitrary implementations.
14:46:02
jackdaniel
I know. We've talked about that in the past; I've raised a concern, that sometimes different handling of things is a valid and deliberate choice for the implementation profile and you've agreed that these independent libraries will be configurable to account for that.
14:51:15
beach
So things like garbage collection and object representation must be left to the implementation.
17:01:09
Gnuxie
beach: is there a reason why in Cluster we don't want to accept implicit operands here https://github.com/robert-strandh/Cluster/blob/master/code.lisp#L153 (or has it just not been implemented yet) ?
17:37:14
Gnuxie
some instructions take an operand from the same register and so it doesn't need to be encoded
17:37:44
Gnuxie
in this case MUL is the issue but I don't think Cluster accounts for any implicit operands other than gpr-a atm
17:39:04
beach
Do you need me for anything else? I am about to go spend time with my (admittedly small) family.