libera/#lisp - IRC Chatlog
Search
18:13:19
jcowan
"Another view is that a programming language really isn't a programming language unless it's also the scripting language of something." Ergo, C and Haskell are not programmimng languages.
18:21:41
jcowan
IMO "scripting language" is just a term for "programming language I can't get paid enough if I write in it"
18:27:35
dash[m]
"scripting language" may be a bit fuzzy but we definitely can distinguish "command language" as an idea, a top-level interface to a system
18:27:36
lisp123_
SICP says "(In fact, most language processors contain, deep within them, a little ``Lisp'' evaluator.) "
18:28:44
dash[m]
some of lisp's ideas have spread so much that they're not recognized as lisp distinctives anymore, relaly
18:28:57
dash[m]
* some of lisp's ideas have spread so much that they're not recognized as lisp distinctives anymore, really
18:30:37
mariari
depends what you count as lisp, if you count some form of eval/apply then ML languages implement this for fast currying
18:30:56
dash[m]
lisp123_: it doesn't, it's more like "most language processors share common designs, historically, with lisp implementations"
18:32:08
lisp123_
so they follow similar processes, but not necessarily have an embedded lisp interpretor
18:32:13
dash[m]
Rarely. The only example I can think of currently is Julia being built on top of femtolisp
18:32:41
mariari
caml/caml-light used to be built upon some minimal lisp, these days they have an s-expression IR at some layer
18:38:53
aeth
one is "script Unix" (i.e. POSIX shell replacement sort of thing, or at least part of a Unix pipeline... see e.g. Perl)
20:10:32
sm2n
mariari, racket can get away with what it does because it does not support interactive development
20:12:08
sm2n
as far as I can tell, it is an open problem how to do interactive development while also having a somewhat strict/rigourous module system
20:15:00
pjb
interactive is necessarily messy. So don't count on strict/rigorous, if you want to make it usable. Deal with it!
20:15:56
pjb
that said, nothing prevents the tool to record and analyse the interactive session, and to save some mathematically strict and rigorous definition that when loaded will restitute a sufficiently similar state.
20:40:01
sm2n
mariari, to be more specific, probably the biggest issue/difference is that CL packages are not really all that fundamental. They really are basically just sets of symbols, with some facilities for inheritance and so on. But they are basically entirely orthogonal to CL's evaluation/execution strategy
20:40:23
sm2n
on the other hand, racket's module system is deeply tied up with it's (phased) evaluation strategy
20:41:09
sm2n
modules can even be instantiated multiple times, as needed, to satisfy hygiene requirements
20:47:37
jcowan
sm2n: Two of them, one for Interlisp and one for Common Lisp. The two languages interoperate nicely, but are in different packages
20:49:17
jcowan
(meaning that different names can mean completely different things at differentt levels of the syntactic ttower)
21:02:03
mariari
sm2n: yes, modules are also something important to program around. Having a good culture around qualified imports can make names shorter (see the Module.t convention in ocaml), and more consistent .
21:02:42
mariari
sm2n: you can do interactive development quite well with a rigourus module system, I don't see why it would prevent that
21:03:23
dash[m]
mariari: smalltalk/lisp ideas of "interactive development" tend to be a bit more aggressive than others
21:03:47
mariari
if we treat modules as just another term in the language, then really it's not much of a difference, the main thing to look out for are that modules tend be more early binding rather than late, however for using them in big applications, if you update a value in it it should still propagate
21:04:38
mariari
dash[m]: yes I'm accounting for that, I don't see what you lose really, as you can still update it live and change out values fine
21:04:54
mariari
you can even do interesting things like mention how agressive you want to inline at a module level and across module boundaries
21:07:07
dash[m]
yeah, that's the main thing I mean, is that one of the major benefits of modules is early binding
21:08:52
mariari
Yes, the late vs early binding in the case of modules vs objects tends to be more about how subtyping treats the value and how new instances work. Which I'd argue is orthogonal to late vs early binding in asking about a particular definition from the image
21:15:31
[itchyjunk]
ah sweet. the code works it seems, just prints things twice. need to debug that
21:16:14
[itchyjunk]
since i have you here already, how do i do nothing `if (true) (do stuff) (do nothing)`
21:18:06
jcowan
In Medley, you can register a defined name (function, variable, etc.) and associate with a file, and that fact is persisted. Any change to the definition is propagated to the file.
21:19:03
jcowan
Interlisp is the language (and CL is the other language): Medley is the implementation
21:19:15
mariari
that's neat, I've seen in factor when I've deleted something from a file and reload that, it's gone from the image, which I found interesting (it did tree shaking of the image for you... only had it do it when I evaled the entire buffer and not single defns)
21:19:51
mariari
there is a lot of neat things you can do with images and re-definitions, in terms of touching back of files
21:42:18
sm2n
I'm not saying interactive development with modules is not possible, I'm just saying it's a relatively unexplored space of language design
21:43:29
sm2n
the racket developers bumped into some of these issues with keeping modules consistent with global state and such, and appear to have given up
21:45:53
mariari
sm2n: well hasn't racket always not been image based? At least from everything I've seen they never tried? I think it might have been explored in the past in some SML derivatives, but I have to investigate that more (the ZINC paper suggests that some SML's may have been image based?)
21:52:57
mariari
namely local opens if you have modules being first class, top level opens can be tracked through other means easily enough
21:59:04
sm2n
though I'm not sure for how long the immutable top level has been around, which is probably more important
22:00:00
sm2n
the problem appears to be tied up specifically with how racket's macro system and modules system interact
22:06:10
sm2n
apparently, I don't understand all the details. But the basic idea is that racket is all about building towers of syntactic abstraction, i.e macros that write macros, and so a question is how to deal with scoping at macroexpansion time for compilation. Racket has a phased system here, where each layer of macros has it's own evaluation "phase", and hence has its own module imports and such. This module system design appears to have made it difficult to support
22:06:25
sm2n
here's the paper describing the original design: https://www.cs.utah.edu/plt/publications/macromod.pdf
22:07:35
sm2n
anyway module systems seem to be one of the hairiest areas of programming language design
22:08:09
mariari
There are some good theory around it, but yeah. For type systems modules require quite a bit of work
22:08:11
jcowan
SML modules are supposed to be The Best, though they don't deal with macros. Not thatt I understand them.
22:08:49
mariari
with dependent types or the approach 1ML takes (or even fx91!) you can get them to be first class
22:08:52
sm2n
yeah, and there's apparently recent work in implementing modules using dependent types
22:09:43
mariari
there is quite a bit of that, the ML type system is too limiting, with a better type system a lot of work has been fertile ground for research
22:10:31
sm2n
iirc moscow ML had regions and then found out they weren't as good as normal GC and ended up throwing it out
22:11:03
mariari
part of the issue is the ML type system isn't good enough to track them properly, it's why effect languages typically have them (see F*)
22:11:40
mariari
in the 90's I think there were a few more I'd have to see the timeline of languages again
22:15:03
mariari
dependently typed language in general can express refinements, it's just a matter of how natural is it, and what makes it easy to support. Those are the hard issues as far as I can tel
22:30:42
mariari
I believe this is the link http://okmij.org/ftp/Scheme/macros.html#syntax-rule-dark-corner
23:15:25
yottabyte
how can I use dolist to return early? apparently I can use return according to these docs: http://www.lispworks.com/documentation/HyperSpec/Body/m_dolist.htm, but they don't provide an example
23:20:39
moon-child
yottabyte: in particular, the body of 'dolist' is implicitly enclosed in a block named nil. return-from will exit the lexically closest block of the given name, yielding whatever value(s) you provide, and return is the same except that it assumed that the name is nil. So this is nothing really special about dolist, except that dolist happens to enclose its body in a block
23:23:35
moon-child
(although, we are presently arguing about arcana there, so despite admonitions to the contrary, perhaps not right at the moment)
23:24:30
yottabyte
reading this http://www.lispworks.com/documentation/HyperSpec/Body/s_block.htm#block was insightful
23:24:44
yottabyte
I didn't even know what an implicit block named nil really meant until I read that
1:56:11
pjb
yottabyte: the hyperspec is a transcription of the ANSI standard for CL (which hasn't changed since it was finished in 1994).
2:51:58
nirnam
alot of thing still be written in C89, I guess you can consider CL standard fairly modern
2:59:09
aeth
Unicode as the default char-code/code-char, UTF8 as the default format for reading/writing files/etc. (although something like UTF32 might be the actual internal string format), metaobject protocol, bordeaux-threads, cffi, gray streams, extensible sequences, package local nicknames, etc.
2:59:31
aeth
Most of the latter stuff have trivial wrapper libraries or are the names of such libraries (e.g. closer-mop for the MOP)
3:03:38
aeth
That's most of them, but note that it doesn't include unicode because there is no such library for that, unfortunately.