freenode/#lisp - IRC Chatlog
Search
16:30:26
_death
you can find many omissions once you're looking for them.. I already gave my argument wrt STRING
16:31:40
_death
it's not the safer choice, it's "false sense of security" choice.. the safe choice would be to not assume it's a fresh string
16:32:16
phoe
the users who read this page do not need to assume that the consequences are undefined if the resulting value is modified
16:32:20
sjl_
As a random bystander, reading clhs STRING, I would not expect the returned strings to necessarily be fresh
16:33:48
_death
phoe: if a user modifies this string, whether it "works" or not on a particular implementation, it's not guaranteed to work by the standard, so it just gives a false sense of security.. and the cost is that you can't have a more efficient STRING
16:39:04
_death
so as a user, you'd go for the conservative choice: not modify the string.. as an implementer you can decide to return a fresh string, but it won't matter if the user makes the conservative choice
16:40:10
_death
but if the user goes wild and modifies the string, it will only work by chance - because the implementer chose to return a fresh string
16:40:44
sjl_
I'll reiterate: STRING is explicitly defined to NOT return a fresh string in some cases. So as a user, I wouldn't expect to be able to rely on it returning fresh strings in the rest.
16:45:11
sjl_
Now I'm confused. You say "asits return values for symbols and characters are required to be fresh." in the issue, which is the OPPOSITE of what I'm saying.
16:48:44
_death
so with this argument, whenever the spec doesn't say the structure is shared, you are required to return a fresh one?
16:51:17
phoe
it would be nice to have the spec say for every return value if it might share structure with anything else or if it is fully mutable
16:51:17
jackdaniel
in other you do not have to, because it is data supplied by user. i.e (string #\a) should always return "a"
16:52:47
_death
jackdaniel: earlier I mentioned the possibility of having a compiler macro for STRING that expands to a literal if the character is known
16:53:07
sjl_
I'm sure pjb probably said this in my missing scrollback, but an implementation that returns a single string for (string #\x) is a http://www.lispworks.com/documentation/HyperSpec/Body/26_glo_c.htm#conforming_implementation
16:53:51
sjl_
And a program that relies on (string #\x) being fresh is not a http://www.lispworks.com/documentation/HyperSpec/Body/26_glo_c.htm#conforming_program
16:55:21
phoe
4) reconsider my life choices and start making music again instead of digging into lisp spec issues
16:56:22
_death
I wouldn't expect to be able to modify the string returned by MACHINE-TYPE (if any), though the spec also doesn't say whether it's fresh or not
16:57:12
jackdaniel
it is not said that modifying string returned by (string foo) has undefined consequences; but I'm reiterating myself
16:57:44
phoe
_death: but that is the easiest way for your lisp image to go from 64 bits to 32 bits! just mutate "x86_64" into "x86_32" and you can load 32bit foreign libs just fine, trust me
17:15:12
phoe
I'd say that it is an implementation detail whether STRING returns fresh strings or non-fresh strings
17:19:51
phoe
so the test tests something that isn't a part of the spec or inferable from its wording
19:16:22
phoe
though it would be pretty insane to tell Lisp to make me a string and get a second-hand one that is already used in three other places
19:39:42
phoe
after digesting all of the arguments I am absolutely tempted to make a PR saying that this is controversial enough for :ANSI-SPEC-PROBLEM
19:39:59
phoe
since I think that we can all agree on one thing - the spec has a problem here and should have been much clearer on that part
20:55:12
rpg
Xach: Thanks. Seems like this will hamper use of CL for tasks that involve data analysis...
20:56:02
Xach
rpg: sure. if someone needs that to do data analysis and they want to use lisp, they will have to make it.
20:58:11
Xach
rpg: sometimes when i want something like that i fake it with run-program, e.g. (with-open-ssh-file (stream "user@host:path/blah") ...) it would just run scp and copy it to a local file, rather than try to do much fully in lisp.
21:00:29
phoe
so just call the proper sshfs commands in some sorta directory and then use logical pathname translations to refer to that temporary directory
21:02:09
Xach
I think logical pathnames are for when you have an enumerable set of literal pathnames embedded in the code, not for arbitrary translations with runtime variations
21:03:27
White_Flame
IMO, this is something the OS really should handle. The fact that all networking is bound to just a plain host:port is a massive weakness
21:04:20
Xach
I think it's a bummer that people start with the idea of arbitrary, configurable runtime pathname transformation and get Very Upset when logical pathnames don't do that, but I don't think that's fully the fault of logical pathnames
21:06:32
rpg
phoe: sshfs sounds neat. I'm with Xach though about logical pathnames -- I think there's too much danger that the filenames would break the LP rules, turning that into a mess.
21:35:25
rpg
Xach: I bet that's possible with ABCL, now that I think of it, but I'm not a JVM kind of guy.
21:47:03
rpg
phoe: Yes. Looks like someone set up an sftp file stream for python, but it's an add-on
21:49:47
jasom
rpg: just curious; I had a few documentation ideas and wasn't sure who to run them by once they are more complete
21:50:17
rpg
Please send them my way! I just got an idea for a new FAQ that I will try to put into the manual today.
21:52:23
jasom
okay. Will do. I'm going to go back through the mailing list and some reddit posts because things that have been obvious to me for years w.r.t. asdf seem to still be hangups for others.
21:54:07
jasom
The number of times I've seen some variation of "I wish I could just load an ASD file and then have my system be loadable" come up is rather stunning since the manual is pretty clear on not just "yes that will work but "We even hook into slime's C-c C-k so that you don't need to do anything special if you're using slime"
21:56:55
jasom
life is finally slowing down enough for me that I can possibly contribute to projects in places I've noticed I might be of assistence
22:21:54
rpg
jasom: I have to take off momentarily, but feel free to contact me if you need assistance -- TeXinfo isn't the easiest thing to edit! (but FWIW, it's a lot better than Python's Sphinx...)
1:43:45
jasom
Let's say I want to define a new component type for asdf. Once I have done so, I can use it with :components ((foo:bar ...) *but* now a :defsystem-depends-on is insufficient to pull in my customization becaue the whole form is read before the defsystem-depends-on is processed. What's the solution?
2:03:31
jasom
One solution is to put a defpackage at the top of the .asd file; I'm looking at iolib.asd now
2:10:43
jasom
It's only non-composable in the sense that it imposes a single global namespace. Package names have the exact same problem.
2:11:31
jasom
in terms of name collisions there's not really any difference between :foo-bar and foo::bar, but packages provided other forms of isolation that are useful.