freenode/lisp - IRC Chatlog
Search
10:57:26
DrDuck
I saw Alan Kay alluring to some stuff Mccarthy wrote 50 years ago and essentually said it makes Mondads look like a cludge and waste of time
10:58:31
DrDuck
In his 'Situations, Actions, and Causal Laws' part of his 'Programs With Common Sense' paper
11:00:21
DrDuck
so i really have half a understanding of all of this. what did alan kay mean by that statement?
11:18:27
pjb
So monads are just a bad and awkward implementation of objects in purely functional programming languages.
11:22:47
White_Flame
monads don't really implement objects, in the I/O mutation hiding sense. They externalize them from the language
11:24:12
White_Flame
it merely is an interface to something external, where the interface itself is immutable
11:25:26
White_Flame
and of course, that was the main thrust of why monads were added to haskell, and then their other uses were promoted as well
11:29:27
DrDuck
so is there anything in common lisp that's as expressive/powerful as haskell typeclasses?
11:30:47
LdBeth
Typeclass is no more than a sophisticated ad hoc overloading => make ad hoc polymorphism less ad hoc
12:03:32
no-defun-allowed
but in any case, you could have a (not CL obviously) evaluator that treated numbers as non-self-evaluating, and then the type of the value of 123 is not necessasrily a number
12:12:00
pjb
LdBeth: not necessarily: (let* ((*read-base* 3.) (*print-base* *read-base*)) (prin1-to-string (read-from-string "123"))) #| --> "123" |#
14:54:28
Xach
beach: might the eclector errors here be caused by recent updates to eclector? http://report.quicklisp.org/2019-08-22/failure-report/sel.html#software-evolution-library_run-dump-store
15:24:42
scymtym
Xach: yes, eclector now exports READ{,-PRESERVING-WHITESPACE,-FROM-STRING} from its packages
15:30:01
scymtym
Xach: great. maybe recommend that they don't :USE eclector packages to avoid this kind of thing in the future
19:23:08
scymtym
Xach: that's great, but i wonder why there wouldn't be the same problem for READ-FROM-STRING
19:43:57
mikeds
i'm writing a parser for a sexp-based format and i'm using CL read, but that doesn't give me the location in the file of every read form
19:44:22
mikeds
is there something in CL standard that could help me or do I need to write it from scratch
19:45:40
mikeds
it seems strange that there wouldn't be something like read that returns (values object location)
19:47:36
Xach
mikeds: there is nothing standard to do that. sbcl has a form-tracking stream of some sort but i'm not sure how it works or if it's useful for inspiration or direct use.
19:51:12
Bike
how would you handle nested structures? i mean, if you READ "(a b c (d e f) g h)" you'd get a location for the outer list but not the inner.
19:54:45
_death
anyway, READ is for arbitrary Common Lisp forms.. so unless you mean that, for "sexp-based format" you should write your own READ