freenode/#lisp - IRC Chatlog
Search
14:01:05
jmercouris
If there was a de-facto GUI framework / web engine port for Linux, it'd be an easier target
14:04:09
lukego
Suppose you have a static programming language with relatively weak abstraction capabilities. So you make an S-expression representation of its source code and then write programs using CL macros. Final step is to generate readable code in the target language with no dependency on Lisp. What's the best example of this approach?
14:12:03
lukego
Relatedly: Have many people taking this approach to hardware description languages like Verilog and VHDL? I googled for this and found Verilisp that seems like exactly what I was thinking of but with a mysterious status (homepage not even on internet archive.) I'm not sure if this is what Marc Battyani does.
14:12:28
ggole
It's convenient to make free use of let, and the compiler will have no trouble with redundant variables, but a human reader of the output might not be pleased.
14:13:03
Bike
HDLs have their own problems because they're not programming languages, and because you can't usually access the "assembly" level because of proprietary-ness
14:15:56
lukego
Verilisp looks awesome in the ECLM sense. Like somebody who wanted to build hardware just decided to use Lisp and bloody well did it. Code looks funky to a Lisper though :-) giving closing parens their own lines like C braces, defining functions like REMOVE-IF-NOT and EXPT with comments thinking they are not already built in..
14:20:18
lukego
also liberal use of EVAL in cases where the idiomatic Lisp is not obvious and author doesn't care but just wants to get shit working. Man, this is a pleasure to read :)
14:35:21
lukego
Reminds me of the time a guy turned up at ECLM talking about how he'd written a successful commercial product for designing aeroplane engines in Common Lisp, afaik with no prior experience, just a bright guy with a problem to solve who somehow recognized Lisp as a good fit
14:46:14
makomo
right, but i mean without catching the condition. i was thinking of something like COERCEP
14:49:26
makomo
i'm reading some data from the user. these objects should be something that is coercable to a certain numeric type stored in *type* (which can be changed at runtime by the user)
14:50:13
makomo
if it's not possible to coerce the values, i would like to report a proper error, instead of letting the following code just explode or w/e
14:56:04
lukego
Thanks again pjb. I'll make a deep dive on the LTD code. Just brilliant to have Norvig code for inspiration.
14:56:58
phoe
makomo: (handler-case (coerce a b) (error (e) (error (make-condition 'coerce-error :data a :type b))))
14:59:02
pjb
makomo: notice that implementations are free (and even must have to) implement additionnal coertions.
15:00:18
pjb
makomo: in the spec of coerce, notice the use of the expression: *recognizable* subtype.
15:00:40
pjb
recognizable subtype n. (of a type) a subtype of the type which can be *reliably* *detected* to be such by the *implementation*. See the function subtypep.
15:01:01
pjb
So COERCE is highly implementation dependent, at least when you use it on strange types.
15:01:59
pjb
For example, consider: (values (eval '(lambda (x) (list x x))) (compile nil '(lambda (x) (list x x))) (coerce '(lambda (x) (list x x)) 'function))
15:02:46
pjb
makomo: You may get the same result for the 3 values, but you could also expect to get an interpreted function from eval, a compiled function from compile, and whatever is best for the implementation, according to the implementation from coerce.
15:04:31
lukego
beach: I find myself in the pleasantly surprising situation that I want to prototype a little project and CL seems like the only suitable language :)
15:04:47
pjb
makomo: another example, I hear that sbcl has other sequence subtypes than vector and list…
18:24:12
jcowan
Lisp-flavored C is not uncommon, though it usually doesn't escape particular Lisp implementations.
18:30:09
kristof
(let ((x (the single-float 0.1)) (y (the single-float 0.2))) (the single-float (+ x y))) => 0.3
18:34:35
jcowan
it so happens that when you add the nearest approximation to 1/10 to the nearest approximation to 2/10', you get the nearest approximation to 3/10.
18:34:50
jcowan
(this is in double-floats, I don't have single-float support handy with a printer I trust)
18:38:09
kristof
D also does this. I presume it has something to do with the way floating points are printed from their binary representation and I know there's some tradeoffs to be made there
18:38:13
aeth
SBCL does something special with floats. Even double-floats. I wrote something that ran in SBCL, CCL, ECL, and CLISP... and for one of the five values, the error was really huge in all of them except for SBCL.
18:38:46
kristof
I wonder if this is the first time someone came in to this channel to complain of correctness and utility
18:41:13
aeth
Well, (defun foo () (let ((x (the single-float 0.1)) (y (the single-float 0.2))) (the single-float (+ x y)))) is compiled to constantly return 0.3 so I'd test with (defun foo (x y) (declare (single-float x y)) (+ x y)) (foo 0.1 0.2)
18:48:51
jcowan
aeth: 0.30000000000000004 and 0.3 are two tokens for the same double-float, but the former is in some sense the canonical one.
18:55:57
kristof
anamorphic: (loop for (sym val . rest) on '(a 1 b 2 c 3 d 4) by #'cddr do (print sym))
18:56:12
jcowan
Scheme requires it, and AFAIK the last holdout against doing so has now given in. There is no C requirement to do so, but at least glibc always prints the shortest correct representation. CL doesn't have a requirement either, but I'd be surprised if any CL implementation does otherwise.
18:56:22
kristof
however that will give you the final nil so you should throw a when clause in there
19:02:06
kristof
I was confusing the return value of the loop function for the print action. The first thing I wrote works just fine.
19:04:10
kristof
does slime support a way to do newlines at the prompt? Sometimes I don't want to load forms from a scratch buffer, I just want to write in the single buffer.
19:15:51
phoe
it does support them as long as you do not have a complete form; for example, "(+ 2 2)" and RET triggers evaluation but "(+ 2 2" and RET creates a newline.
19:16:19
phoe
I frequently delete the last closing parenthesis after typing the opening one creates a pair, if I expect to be writing a multiline form.
19:17:03
kristof
SBCL's repl does but slime does not... on Atom, at least. Does it have that before on emacs?
19:32:36
LdBeth
For slime the editor processes the form rather than the Lisp itself, it doesn’t know very well on when to send it, sometimes it even applies to GNU/Emacs
20:14:05
aeth
In SBCL, SLIME's #'sin is (FUNCTION (T) (VALUES NUMBER &OPTIONAL)) and (introspect-environment:function-type 'sin) is (FUNCTION (NUMBER) (VALUES (OR (SINGLE-FLOAT -1.0 1.0) (DOUBLE-FLOAT -1.0d0 1.0d0) (COMPLEX SINGLE-FLOAT) (COMPLEX DOUBLE-FLOAT)) &OPTIONAL))
20:14:56
aeth
(And it's not for portability, I don't think either even has function types in the other implementations)
20:18:27
Bike
"slime's" is the derived type, whereas the one you attributed to introspect environment is the declared type
20:22:51
aeth
In SBCL (and I think just in SBCL) it has the line TYPE: (FUNCTION (T) (VALUES NUMBER &OPTIONAL))
20:23:38
aeth
But personally if I was for some reason debugging something involving #<FUNCTION SIN> (obviously this is just an example) then I'd find the declared type to be more useful.
20:24:14
aeth
Well, I (setf *print-case* :downcase) most of the time, but I keep having to restart SLIME to switch implementations/etc.
20:24:36
Bike
as you can see from looking at the source, slime-inspect on sbcl for functions uses the simple-fun-type that's actually in the function object, rather than the declared type
20:26:56
aeth
Well, this is weird. (sb-disassem:disassemble-code-component #'sin) shows the very small entry point of a T input value. I declare stuff all the time and there's usually a check in the part that's in sb-disassem:disassemble-code-component but not in cl:disassemble
20:35:49
aeth
Actually, what I think is going on is that SBCL's declaim ftype and SBCL's type declarations are separate things, but when you declaim ftype for something you write you also type declare or something. (declaim (ftype (function (number) number) bar)) (defun bar (number) (sin number)) will produce a #'bar as if I did a (declare (number number)) even though I didn't.
22:00:46
skidd0
or, how can i directly manipulate the lack.response reesponse structure before sending?
22:15:28
jcowan
Well then, why bother to have external symbols at all and require a (slightly) more verbose syntax to access them from other packages? (This is not a rhetorical question.)
22:34:02
skidd0
to get access to the lack.response, would I want to do something :around the CALL method?
22:56:39
Bike
skidd0: it doesn't replace, but if your :around method doesn't call-next-method the original method will not be called
23:56:10
skidd0
I'm getting an error where hunchentoot doesn't know how to handle options http requests
1:28:34
kooga
(setf (lack.response:response-headers *response*) '(:access-control-allow-origin "*"))
1:29:52
skidd0
also, i figured out that I needed to add a options verb to the routing library i'm using (snooze)