freenode/lisp - IRC Chatlog
Search
19:25:26
oleo
(defparameter *x* 0) (let ((*x* 1)) (sb-thread:join-thread (sb-thread:make-thread (lambda () (let ((*x* *x*)) *x*))))) -> 0
19:25:36
oleo
(defparameter *x* 0) (let ((*x* 1)) (sb-thread:join-thread (sb-thread:make-thread (lambda () (let ((*x* 1)) *x*))))) -> 1
19:32:23
oleo
(let ((*x* 1)) (sb-thread:join-thread (sb-thread:make-thread (lambda () (let ((*x* *x*)) (setf *x* "abc")))))) -> "abc"
19:33:29
oleo
so read the global value eventually, if you don't bind it, but write only to your own version
19:38:20
oleo
(let ((*x* 1)) (sb-thread:join-thread (sb-thread:make-thread (lambda () (setf *x* "abc")))) -> "abc"
19:42:51
mfiano
Considering threads are not part of the standard, it is undefined behavior whether they will be thread-local or not.
19:48:14
aeth
You'd not only need to pay for it, you'd first have to convince the majority of the community decision makers that it's necessary. The easiest way would probably be to hire as many as possible.
19:48:43
aeth
You could probably get away with just getting the developers of SBCL, CCL, and ECL on board.
19:50:32
aeth
oleo: How many of the people involved in the CL spec were employed by companies that used CL commercially? How many such companies exist today?
19:56:46
aeth
The main thing that would have to be worked on in a spec would probably be the type system.
19:57:41
aeth
One simple example: make SBCL's gradual-typing-via-declare the standard, expected behavior. It's already assumed in a bunch of places. No need for syntax changes. Macros can create more convenient syntax.
20:02:30
aeth
all of the people involved in CL implementations go to #anti-standards-committee where they plot about ways to prevent CL's standard from getting an update
20:03:01
White_Flame
there's CL2.1. all it takes for there to be a standard is for somebody to write it up, and others to use it
20:03:33
White_Flame
so obviously it's best when there's concensus, like the lisp industry getting together to create Common Lisp
20:04:02
aeth
White_Flame: All it takes for there to be a standard is SBCL, CCL, and ECL agreeing on something.
20:04:59
White_Flame
yep, and in many ways that's how CL formed in the first place: consolidating existing "ad hoc" features that were popular
20:05:00
jackdaniel
to agree and to have time to implement agreed *thingey* are two different things
20:05:29
jmercouris
I think what would be best would be an extension of the language in the form of macros
20:05:45
MichaelRaskin
Well, there is a reserve of implemented things where agreeing on naming is almost equal to implementing
20:06:04
jackdaniel
things which doesn't require implementation support (as in: writing macros) would be hard to justify as part of the standard
20:06:42
jackdaniel
consolidating some features is another story: i.e agree on common interface to semaphores, or threads (in fact: agree on something what portability layers try to unify)
20:07:06
White_Flame
I often liken this part to C (at least pre modern updates), where the language is small, but the industry has standardized on popular libraries
20:07:59
aeth
One easy thing to do in an upcoming spec would be to bump the minimums. Some docstrings are probably non-portable because array-total-size-limit (the maximum size of an array, including a string) has a minimum at 1024
20:08:31
aeth
Probably the way to do it would be to define minimums for 32-bit implementations and minimums for 64-bit implementations, and a way to detect which minimum the implementation is following.
20:09:16
White_Flame
one would think that a way to detect the limits would be... array-total-size-limit
20:09:40
aeth
A harder, but related, thing would be to *lower* a minimum. short-float cannot be IEEE half-precision floating point. The minimum precision is too high (13 instead of 11).
20:11:24
aeth
long float is probably still too uncommon to specify concretely. Do people want it to be quad float? 80-bit extended-precision? arbitrary precision?
20:12:29
aeth
(I'm sure some people's code would break if SBCL added a long-float because pi is long-float, not double-float!)
20:15:50
White_Flame
it would be nice to compile all the complaints people have about the current lisp spec
20:18:12
aeth
Characters (we can be more specific these days), paths (same thing), type system, more sequences (extensible sequences?), threads, maybe networking, possibly typed arrays/hash-tables/lists/etc. (lists are the only trivial one to implement yourself, but even then only your code would know your way)
20:20:07
aeth
Oh, and various functional programming things that you could technically do by writing a language in Lisp that compiles to Lisp and isn't compatible with anything anyone else uses either.
20:21:13
aeth
Lisp isn't particularly FP by today's standards even though it was by the standards of 25+ years ago.
20:25:04
jackdaniel
you miss the point, but I'm too busy with talking on #lisp-secret-room to explain myself :p time for sleep, good night
20:26:28
aeth
Considering a new standard would be a once-every-30-year event, I don't think deprecation would mean much
20:27:04
aeth
Can't remove anything, not even the currently-deprecated stuff, since people used them assuming they wouldn't be removed
20:27:50
aeth
I've only seen prog in ancient lisp code but someone probably generates it with a macro somewhere in Quicklisp instead of using tagbody for some reason.
20:32:19
aeth
White_Flame: symbol-plist is in the book. http://www.gigamonkeys.com/book/beyond-lists-other-uses-for-cons-cells.html
20:33:01
aeth
mfiano: definitely unicode because there isn't even (afaik) a major unicode portability library
20:34:41
mfiano
PLN is the big one in my opinion. As the CL ecosystem grows, and in certain cases where it makes sense to have short package names/nicknames, transitive dependencies colliding out of a user's control except only their choice of direct dependencies is a huge problem.
20:37:51
aeth
Oh, forcing specific optimizations would be nice. (declare (optimize (tco t))) and if the compiler recognizes tco it's enabled.
20:38:39
White_Flame
yeah, I've fiddled with SBCL internals to enable it while debug & safety are high, so the stack doesn't blow during testing
20:39:16
mfiano
defpackage-plus has in my opinion a very bad hack to support package-local nicknames in a way that gracefully falls back to global nicknames if an implementation doesn't support it. This is very wrong. At best, which an implementation supports them, you have non-portable code. At worst, you silently have global nicknames. It's not a "pure" solution.
20:42:08
aeth
Oh, I almost forgot. The next CL standard should sneak in a full implementation of Prolog as well. Put it in an appendix as a mandatory thing. Or maybe a long footnote.
20:42:23
mfiano
I consider that worse than just using global nicknames, because you don't know how it will behave from a user standpoint.
20:43:22
aeth
nirved: I'm trying to specifically talk about things where a layer wouldn't be too useful.
20:43:46
aeth
You can implement anything in any turing complete language, but not necessarily efficiently.
20:46:57
aeth
yes, the Prolog was a joke, but actually apparently there are some things an implementation must do in order to coexist with Prolog. iirc dmiles was talking about that a while ago
20:47:33
aeth
the latter would be more of an idea to specify as an extension or something, not actually all of Prolog
20:48:29
aeth
Perhaps the future of a CL environment is as a runtime for many languages. Then there'd be lots of interesting things that could be added.
20:48:34
nirved
if necessary CL can spit out machine code as well, and with CL writing a compiler is relatively easy
20:51:09
White_Flame
nirved: that would be more in the realm of creating a new language separate from CL, not necessarily modifying/extending CL itself
20:51:35
White_Flame
as at that level, you're working with individual implementation specifics, not anything CL-specified
20:52:12
aeth
But there are already lots of constructs in CL that don't really make sense to directly use, like tagbody
20:52:43
White_Flame
and if CL wants to be a modern runtime, it really needs feedback-based recompilation in my opinion
20:53:28
aeth
You might be able to get enough meaningful feedback in a DSL to recompile those DSL functions at runtime, if that's what you mean.
20:55:41
White_Flame
right, that sort of architecture would allow making the base langauge more generic, while still finding location-specific speed decisions
20:56:24
aeth
not sure how you'd do this without first (1) making the MOP standard and then (2) also making what you're talking about standard
20:58:33
aeth
It would be nice if something like specialization-store wasn't necessary for when you wanted generics for e.g. (simple-array single-float (3))s
21:00:18
White_Flame
recompile your code to inline the type decisions that actually occurred the most
21:01:32
White_Flame
for instance, (mapc (lambda (x) ...) list) is unrolled in SBCL to a plain loop, instead of literally calling that function every iteration
21:02:00
White_Flame
but (mapc #'some-other-function list) couldn't be inlined, because that function might be redefined, or be passed in as a variable, or whatever
21:02:19
White_Flame
in theory, if the code notices that the same function is always given to that mapc, it could be recompiled to a loop with that function inlined
21:03:41
White_Flame
the functionality should be maintained throughout its optimization; only the speed should be affected
21:04:37
White_Flame
also, if the invariant that was optimized is violate (ie, you pass in a different function than what was inlined) then it either undoes that optimization or run a separate fallback "slow path" for the more generic case
21:05:38
White_Flame
you can see how it would increase the speed of math operations, and do things like flip from baked-in fixnum to bignum processing automagically
21:06:23
White_Flame
I'm not a fan of Java, and only somewhat of JavaScript, but man I respect the tech they've put in those VMs
21:38:41
comborico1611
Why is "form" also used, and not just "expression". "Expression" does predate "form", correct?
21:41:43
White_Flame
it doesn't evaluate (car foo) first as an expression, it dispatches on the form (car ???)
21:42:11
White_Flame
if foo was (1 . 2), then evaluating the experession would yield (setf 1 3) which doesn't make sense
23:17:13
edgar-rft
comborico1611, the best explanation of Lisp forms vs. s-expressions I found so far is <https://stackoverflow.com/questions/2877371/definition-of-lisp-form>
23:18:07
edgar-rft
In short, Lisp forms can also be self-evaluating atoms like numbers, strings, arrays, etc.
5:01:18
beach
It was for people who have GitHub repositories. They are doing a survey on how API-breaking changes impact the work, and on to what degree those people introduce API-breaking changes.
5:30:04
rme
I've received messages like that before (where someone is doing research based on GitHub repositories); I am afraid that I tend to ignore them.
5:30:39
beach
I do too. But this was an opportunity to mention that 1. I use Common Lisp and 2. There are very few problems of this type with Common Lisp.
5:36:54
loke
What could have happened? (it is triggered some time after loading one of the McCLIM files and an error happens)
5:37:39
loke
beach: Right, but which one? The one in my REPL (both SLIME repl and *inferior-lisp*) are still normal.
5:38:44
loke
It's not really a problem, I actually prefer lower case. It's just unsettling that I have no idea why it happens.
5:39:39
loke
aaaah. wait a second. It only happens for stack traces generated from the CLIM Command Reader.
7:04:23
shrdlu68
Hey, I'm reading online and some guy says that Lisp has two fundamental features: 1. Programs and data being the same 2. nil eq () eq false.
7:05:10
shrdlu68
He says without either of these, a language is not a lisp. In what qay is 2. a fundamental lisp feature?
7:07:47
schweers
I like nil punning and the like, but I don’t think it’s /that/ essential. But hey, maybe
7:10:00
shrdlu68
schweers: In the comments here: http://smuglispweeny.blogspot.co.ke/2008/02/ooh-ooh-my-turn-why-lisp.html
7:10:45
flip214
consider all the problems with eg python, perl, etc, where you have multiple "false"s: "", "0", false, 0, []
7:11:31
schweers
although I’m not so sure anymore if I regard scheme to be a lisp, albeit for different reasons.
7:11:53
flip214
schweers: well, python is called "a lisp without the parenthesis" - I don't understand why. so how many parts of lisp are needed to _get_ a lisp?
7:12:38
schweers
as far as I know, only false and None are non-true in python. Am I wrong? (Not that it matters)
7:15:31
schweers
ugh, I hate python. this indentation stuff really is stupid. And not for the reason most python newbies have.
7:17:08
beach
shrdlu68: There is no widespread agreement about the definition of "Lisp". That's why this channel is dedicated to Common Lisp, which is well defined.
7:18:29
shrdlu68
beach: Ah, so there's no way to validate this gentleman's claim, there being no standard definition.
7:19:26
beach
Therefore it leads to pointless discussions, since every person has his or her prerequisites for some language being "a Lisp".