libera/commonlisp - IRC Chatlog
Search
19:27:22
jackdaniel
declarations are convenient lies that the programmer tells the compiler; the latter may conformingly a) head the advice, b) ignore the advice, c) head the advice carefully, d) try to verify the advice
19:27:53
pjb
dbotton: do you have a paste service that doesn't need javascript, such as http://termbin.com ?
19:27:54
jackdaniel
e) heed the advice and segfault (also conforming \o/ if the declaration is incorrect)
19:28:45
pjb
dbotton: your code is not conforming, since it likes to the compiler. Therefore anything happens. You're lucky if you get an error or any result ressembling 3.
19:29:20
aeth
I wouldn't expect an ftype DECLARE for a global function to work (on the other hand, a global DECLAIM right above the relevant DEFUN probably should)
19:29:53
pjb
aeth: since the compiler can inline any file-local function call, declare will have an effect.
19:31:21
aeth
of course, none of it has to do anything, but DECLAIM FTYPE is common enough to come up
19:35:46
Bike
some of the semantics relating to type declarations changed during the standardization process.
19:36:38
dbotton
according to the piece it said that such a declare should turn in to (the)s on the calls
19:37:50
Bike
of course, it's nice for an error to be signaled, but implementations don't have to do so
19:38:09
kakuhen
i.e. (the fixnum 1.0d0) and the likes are UB. You cant rely on your compiler signalling an error
19:39:09
kakuhen
that's why you should always prefer check-type over a declare if you really need strict type checking across impls
19:39:40
kakuhen
that or increase safety levels; I know CCL does type checks on (safety 3) but not (safety 2)
19:40:14
Bike
some types are impossible or impractical to check. leaving the consequences undefined lets you declare those types anyway for optimization.
19:41:08
Bike
for example, if you declare an array's element type, that specifies the type of the elements - not just the upgraded element type, like usual. so to check it an implementation would need to iterate over the array, which would probably offset any efficiency gain from it knowing the array is full of whatever.
19:41:40
pjb
non-conforming code is like programming in C. (the fixnum 1.0d0) CAN be equivalent to *(int*)(char*)(double x=1.0d0,&x) (note, not (int)1.0d0 !).
19:44:10
pjb
All kinds of silly stuff can occur is you write a wrong declaration. It's really very dangerous.
19:44:45
Josh_2
Bike: the combination is ideal though, high safety for testing, higher speed less safety in your live version :thinking:
19:44:51
Nilby
Type decls are useful, just not in the "programmer: you can't do this" way, but rather in the "compiler: maybe you can do this?" way. For the former we have things check-type and assert.
19:45:29
pjb
Josh_2: not really. In production code, you want to ensure that no error pass thru. So you definitely want to keep the highest safety, and highest error detection for production.
19:46:18
pjb
Josh_2: otherwise, it would be like using seat belt when testing your prototype cars, and removing them in production, because you've tested your car doesn't crash when driven correctly during the tests.
19:46:50
Josh_2
I disagree, on of the purposes of your testing version is to make sure that your typed code only receives the types expected
19:47:03
pjb
Any type declaration must be validated by a global analysis of the program to prove that you will never assign other than the specified type!
19:47:04
_death
dbotton: when you encounter "is an error" it means you shouldn't do it.. it's different from "signals an error", which means the implementation should do that
19:47:39
pjb
I prefer to let the compiler insert good old type infered code, or run-time type checking as needed.
19:48:40
Josh_2
but if I knew I had a core part that was performance critical I would certainly make use of type declarations
19:49:59
Josh_2
Once I did a code test a friend of mine was given for a job interview using CL. Without the proper types the time taken to perform the data analysis was stupid.
20:58:48
Josh_2
(list* :key1 key1 :key2 key2 keys) is much nicer than (append (list :key1 key :key2 key2) keys)
21:11:50
Josh_2
One of the biggest projects I have made has been in constant use for almost 2 years now
21:13:57
Josh_2
Most of the functionality was hacked into the program while it was running :sunglasses: so i've never taken the time to start from completely fresh so I could document how to get it running
21:17:58
Josh_2
Its a shame really, I've hacked so much functionality into this bot that I dont use at all anymore :shrug:
21:36:08
dbotton
I always use doc strings, write when I can, notes etc. even if I can't understand myself sometimes most of the time I and others can :)
22:19:59
_death
although "is an error" is not mentioned there, it generally means the code is nonconforming
22:45:57
phoe
and yeah the language in TCLCS is so casual and boring that I am getting comments it's not terse enough for some people
22:46:15
phoe
so if someone likes a bit of story with their knowledge my book should be fine, for basics of macro writing too
1:29:45
shunter
Toplevel proclaims establishes declarations in the global environment. It's unspecified whether toplevel declaims have any effect after the file it lives in is compiled.
4:06:50
mfiano
Hello all. I have a couple ideas, but I'm looking for different opinions on how one might, if it was so required, to go about preventing the instantiation of a class, if that class is prohibitively intended to be used only as a super class, for some particular domain. Bonus points if you can argue why it is a good way to go about it.
4:09:13
mfiano
phoe: Yes, I meant, like kicking around the parens and stuff instead of moving to Java or something non-programming :)
4:22:56
dbotton
mfiano: just add a slot or use an existing slot with a uniform the signals an error is simplest way.
4:23:36
mfiano
dbotton: Then every subclass would be required to override that slot, which is an implementation detail. I don't like that at all.
4:27:08
dbotton
You can identify the type there and signal if they try and create your abstract class
4:27:54
mfiano
I think you are making an assumption that is not true. The un-instantiatable classes are mixin classes that can be provided to a variety of different objects, some whose constructors I don't control. Using stealth-mixin or dynamic-mixins, one can alter the super class list.
5:05:05
mfiano
beach: I think there is actually an error in that method causing it not to do what is intended.
5:27:27
mfiano
If I restart my image, define that macro, a protocol class using it, and a class that inherits from the protocol class, when attempting to instantiate the subclass, I get the error, but if I select the RETRY restart in the debugger, it works, and on all subsequent attempts without the debugger. I wonder if beach or jackdaniel could explain that one.