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.
5:50:42
scymtym
i think i added the trick for preventing instantiation. i have to go now but can check the logs later
5:53:55
mfiano
I got it to work now. I was slightly modifying it for my purpose, and in doing so, I didn't realize that the initform was meaningless, and was just the quoted error form.
5:59:36
mfiano
As in it was unevaluated, and just there for display purposes or something when viewing the object in the inspector. An initform of nil, with an initfunction of the error is all it takes for it to work for me.
6:03:51
mfiano
code is doing `:initform '#1=(error ...) :initfunction (lambda () #1#)` which is quoting the first but not the second. I missed that subtle detail. The value of the initform does not matter much, as this slot is not inherited due to the EQL specializer on `compute-slots`, and it is not even evaluated yet before the initfunction error. At least that's what I gather by reading about it. Please
6:05:00
dirtcastle
Josh_2: thanks for the suggestion. I wonder which is the best language and book to learn OOPS. Lisp is not known for OOPS right...
6:06:16
beach
dirtcastle: The book by Sonja Keene is probably the only one exclusively dedicated to CLOS, but PCL has a lot about it too. Modern Common Lisp code uses CLOS a lot.
6:06:35
mfiano
and what makes it nice, is that it is fully extensible. The MOP is the CLOS as macros are to syntax.
6:10:02
edgar-rft
dirtcastle: the best book I read for learning CLOS is Sonya Keene's "Object-Oriented Programming in COMMON LISP: A Programmer's Guide to CLOS"
6:13:05
beach
ACTION now fears he is going to be given a list of predecessors with object systems in them,.
6:13:36
hayley
ACTION hopes the scare quotes suggests that she does not agree much with the "wisdom".
6:14:53
dirtcastle
yes. I heard common lisp has the ability to adapt to any new paradigm that comes around. And the comment I read said " common lisp has the best object system and that's ironic".
6:14:58
hayley
I told off a lecturer at my old university for making that statement. And the instructor for operating systems class had said similar for Elisp.
6:16:27
mfiano
beach: "lisp in general" also includes predecessor sibling branches developed independently of CL, some of which have CLOS-like or otherwise modern object systems.
6:16:43
hayley
Wouldn't state _any_ new paradigm, c.f. Felleisen's "On the expressive power of programming languages". There are some interesting things you cannot do with macros/local rewrites only.
6:16:55
beach
dirtcastle: It doesn't make much sense to "learn CLOS" in itself. CLOS is part of the Common Lisp language, and you use it together with the other features.
6:16:59
dirtcastle
lisp is known for using procedural & functional style, recursion and macros. and lambda functions?
6:17:25
hayley
I'd go easy on recursion, as only the Scheme standard mandates tail-call elimination.