ELLIOTTCABLE changed the topic of #elliottcable to: screw syntax, make neat languages
<cloudhead>
hi
<purr>
cloudhead: hi!
PragCypher has quit [Remote host closed the connection]
<devyn>
ELLIOTTCABLE: my guess is for pristine=true: set pristine=false, pc=first in root. stack would be empty but I don't think that's a problem
<devyn>
and of course it would just end up combining against response
yorick has quit [Remote host closed the connection]
<devyn>
ELLIOTTCABLE: initialization of a pristine Execution also has to check if it's empty, otherwise if it's empty step #3 would be applied, as current would be undefined
<devyn>
but I think this should work
<devyn>
hmm
<devyn>
hold on I see another problem
<devyn>
step #3 should really just take into account whether there's an enclosing Expression
<devyn>
if not it just discards and produces no combination
<alexgordon>
hi devyn
<devyn>
hi alexgordon
<alexgordon>
devyn: talk langs to me dev
<devyn>
not going to be here for much longer. just finishing up advance() and then headed downtown.
<alexgordon>
devyn: :(
<devyn>
but, if you want, you can throw stuff at me and I'll reply later
<devyn>
:p
<cloudhead>
rust is the least fun I've had programming since C++
<cloudhead>
:(
<cloudhead>
actually it's less fun than C++
prophile has quit [Quit: The Game]
<alexgordon>
cloudhead: HAHA
<alexgordon>
cloudhead: micah said the exact same thing
<alexgordon>
cloudhead: but more educatedly-like
<alexgordon>
cloudhead: rust is a really brilliant language and it does everything right buuuuuut I dunno it's like uncanny valley
<alexgordon>
C++ is the real deal
<alexgordon>
it's the real deal because it's for the most part a superset of C
<alexgordon>
so you can really crucify yourself using it
<alexgordon>
e.g. computed goto. I dunno if rust has anything like that
<alexgordon>
rust is a bit like ada to be honest
<alexgordon>
you can't argue with their decisions
<cloudhead>
lolol
<purr>
lolol
<cloudhead>
it's just
<cloudhead>
so fucking verbose
<cloudhead>
and complicated
<alexgordon>
...but they don't add up to a good whole
<alexgordon>
cloudhead: yah
<alexgordon>
their problem is trying to implement everything that C can do
<alexgordon>
but in a different way
<cloudhead>
let p = node.parent_.as_ref().unwrap().upgrade().unwrap();
<cloudhead>
just wrote this
<cloudhead>
lol
<cloudhead>
I don't even
* joelteon
monads
<cloudhead>
the safety features get in the way of... doing things
<alexgordon>
haha yeah
<cloudhead>
yea, and because of the crippled type system
<cloudhead>
you basically have to litter the code with crap
<joelteon>
to be fair
<cloudhead>
I almost prefer running valgrind every other time
<joelteon>
it is not yet version 1
<cloudhead>
true..
<alexgordon>
joelteon: their problem now is that it's really not ready
<alexgordon>
but it has traction
<cloudhead>
but will v1 have higher-kinded types
<cloudhead>
is my question
<alexgordon>
so do they push for 1.0 and possibly people will actually use it
<cloudhead>
and even that would not be enough I think..
<joelteon>
alexgordon what do you call the difference between C++ templates where you state what variables you're parameterizing on and haskell typeclasses where you don't have to
<alexgordon>
or do they spend the 4 or so years it needs, at the risk of alienating all their users
<cloudhead>
heh
<cloudhead>
(* -> *) -> *
<alexgordon>
joelteon: one of them is useful?
<joelteon>
ok
<joelteon>
but what's the name for it
<alexgordon>
not sure, example please
<joelteon>
ok i don't really know c++ but it's like
<joelteon>
what would the type for a map function be in c++
<joelteon>
i don't know lambdas
<alexgordon>
don't need lambdas
<alexgordon>
the type would be
<joelteon>
ok
<alexgordon>
well
<joelteon>
go on
<alexgordon>
depends how deep you go
<alexgordon>
the simplest would be
<alexgordon>
template<typename T> std::vector<T> map(std::vector<T> xs, T (*f)(const T& x));
<alexgordon>
but that's not really the same as haskell
<alexgordon>
you can extend that to mapping between different types
<joelteon>
you can extend haskell to map between different types too
<alexgordon>
template<typename A, typename B> std::vector<B> map(std::vector<A> xs, B (*f)(const A&));
<alexgordon>
right next stage would be to map over arbitrary collections
<joelteon>
i wasn't trying to make this a dick measuring contest, i might've done it by accident
<alexgordon>
lol?
<purr>
lol
<joelteon>
do you know what you call it when that happens
* alexgordon
isn't measuring his dick
<joelteon>
i forgot my ruler
<alexgordon>
joelteon: you mean when you do like A<B> ?
<joelteon>
maybe
<joelteon>
yes
<alexgordon>
it's either higher kinded or higher ranked, can never remember the difference
<cloudhead>
does C++ have hkts?
<joelteon>
ok, no, that's not what i meant
<alexgordon>
joelteon: my knowledge of haskell lingo is pretty low
<cloudhead>
well, you wouldn't really need them
<joelteon>
if haskell types looked like c++ types, that would be this:
<joelteon>
std::vector<B> map(std::vector<A> xs, B (*f)(const A&));
<joelteon>
in c++ you state template<typename A, typename B>
<alexgordon>
oh well that's just a forall
<alexgordon>
haskell has implicit forall
<joelteon>
right
<alexgordon>
when you write
<joelteon>
oh ok
<joelteon>
implicit forall
<joelteon>
ok
<alexgordon>
(a -> b) -> [a] -> [b]
<alexgordon>
it means
<joelteon>
yeah i know
<alexgordon>
forall a. forall b. etc
<joelteon>
there we go
<joelteon>
ok, cool
<alexgordon>
joelteon: C++ doesn't have that because functions (among other things) can have type arguments
<alexgordon>
whereas haskell uses casting
<alexgordon>
e.g.
<joelteon>
you mean they can take a type as an argument?
<alexgordon>
_usually_ C++ will be able to deduce the type arguments automatically
<joelteon>
that makes sense
<alexgordon>
but sometimes it cannot, e.g. for a return value parametrization
<alexgordon>
also C++ templates can be integers as well as types
<alexgordon>
e.g.
<alexgordon>
Matrix<4, 4>
<alexgordon>
which haskell doesn't have
<alexgordon>
and don't get me started on variadic templates :P
<joelteon>
ok i won't
<alexgordon>
people say haskell has a powerful type system
<joelteon>
haskell does have type lits now though
<joelteon>
and there are some constraints in base 4.7 for comparing numbers
<joelteon>
on the type level
<alexgordon>
but it still has things like 10 overloads for functions on tuples, whereas in C++ you can do that with a recursive template definition
<joelteon>
but i mean, why would you use that shit anyway
<joelteon>
c++ tuples are like hlists
<alexgordon>
joelteon: link?
<alexgordon>
what's an hlist
<joelteon>
it's just a tuple, except you can cons/uncons it
<alexgordon>
personally I'm in the camp that it's better to just generate this code from metaprogramming than try and expand the scope of the type system
<joelteon>
it's just a haskell tuple*
<alexgordon>
like if you wanted a function that mapped on tuples
<alexgordon>
map :: (a -> b) -> (a, a) -> (b, b)
<alexgordon>
you're better off generating a bunch of those
<joelteon>
that's (&&&)
<joelteon>
but yeah
<alexgordon>
than trying to do weird stuff like
<alexgordon>
map :: (a -> b) -> (a...) -> (b...)
<alexgordon>
too complex
<joelteon>
i agree
<alexgordon>
but that's what C++ does
<alexgordon>
never afraid of complexity :P
<joelteon>
nop
<joelteon>
i'd link you to the hlist docs but that's an oleg library
<ELLIOTTCABLE>
alexgordon: have to admit, you're making me want to learn C++ properly.
<ELLIOTTCABLE>
alexgordon: as in, the way you've described templating above, sounds right up my alley. I would *love* to work with that.
<alexgordon>
ELLIOTTCABLE: haha
<alexgordon>
ELLIOTTCABLE: it's actually awesome
<alexgordon>
because it's so intuitive, to me
<alexgordon>
I find it way more intuitive than "traits" and stuff
<alexgordon>
because it's literally just simple subtitution
<alexgordon>
no hidden rules baked into the language
<ELLIOTTCABLE>
cloudhead: hi.
<ELLIOTTCABLE>
cloudhead: in your professional opinion, what's the value of Rust?
<alexgordon>
didn't he say he hated it yesterday?
<ELLIOTTCABLE>
I got a lot of feel for your issues with it; what do you see as the positives?
<ELLIOTTCABLE>
-clouds
<purr>
ELLIOTTCABLE: is stuck up in the clouds; hilight 'em if you want 'em.
<ELLIOTTCABLE>
devyn!
devyn has quit [Read error: Connection reset by peer]
devyn has joined #elliottcable
<ELLIOTTCABLE>
devyn!
vigs has quit [Ping timeout: 258 seconds]
<ELLIOTTCABLE>
“All of these come from abstract algebra and category theory, which is a pretty insane field.”
<ELLIOTTCABLE>
love this guy so much.
<devyn>
ELLIOTTCABLE!
<ELLIOTTCABLE>
hi
<purr>
ELLIOTTCABLE: hi!
<ELLIOTTCABLE>
learning things, a bit
<ELLIOTTCABLE>
so, two things:
vigs has joined #elliottcable
<ELLIOTTCABLE>
A) Why are you writing a Paws? To my immense surprise, you keep coming back and working on it, day-after-day.
<ELLIOTTCABLE>
B) if you understand Paws well-enough, now that you're *implementing* it; I need to talk to somebody about the concurrency issues you brought up. I've been thinking hard on it for several days, and have some observations; but micah's basically fallen off the programming map, and I seem to have a really hard time drawing actionable insights or decisions out
<ELLIOTTCABLE>
of my thought-process without a cognizant sounding-board.
<ELLIOTTCABLE>
(I googled “learning system F”, because the original paper I have on hand is a little dense for me,)
<ELLIOTTCABLE>
(and got an article titled “System F in CoffeeScript.”)
<ELLIOTTCABLE>
(that's two things you would never fucking expect to see in close proximity to one-another. O_O)
<devyn>
ELLIOTTCABLE: A) I don't even know. It's kinda fun. I'm learning Rust. I have better things to do, but... this is pretty fun
<devyn>
ELLIOTTCABLE: B) okay
* ELLIOTTCABLE
smiles
<ELLIOTTCABLE>
I have to leave in a little under 20 minutes, to start walking. Have a haircut to get to.
<devyn>
alright
<devyn>
lol system f in coffeescript
<purr>
lol
<ELLIOTTCABLE>
so I won't go into any depth, right now. Will you be around “tonight?” (T ⨤ 2 hrs)
<devyn>
yeah, most likely
<ELLIOTTCABLE>
I understand the S.f in CS thing, actually. He chose it because, for the strict set of things needed, their syntaxes are directly correspondent
<devyn>
then I guess that makes sense
<ELLIOTTCABLE>
λx.λy.x === (x)-> (y)-> x
<ELLIOTTCABLE>
and
<ELLIOTTCABLE>
x y === x y
<devyn>
Haskell is probably closer...
<ELLIOTTCABLE>
e ::= x | λx.e | e e
<ELLIOTTCABLE>
e ::= x | (x)-> e | e e
<ELLIOTTCABLE>
yeah, but Haskell isn't remotely as approachable.
<devyn>
\x -> \y -> x
<devyn>
x y
<ELLIOTTCABLE>
to me, it was surprising that he was using CoffeeScript instead of, say, Ruby, C, or JavaScript
<devyn>
I still think \ is such a funny choice
<ELLIOTTCABLE>
funny, ick
<devyn>
because it looks like lambda, apparently
<ELLIOTTCABLE>
terrible choice. >:
<devyn>
if you enable UnicodeSymbols you can actually use the lambda
<devyn>
no one does though
<ELLIOTTCABLE>
I would >:
<ELLIOTTCABLE>
anyway
<devyn>
haha
<ELLIOTTCABLE>
so.
<ELLIOTTCABLE>
basically:
<ELLIOTTCABLE>
there's three ways to take bites out of the sequencing problem.
<ELLIOTTCABLE>
which is what the thing you brought up, basically is.
<devyn>
mmhm
Sgeo has joined #elliottcable
<ELLIOTTCABLE>
at the moment, the naïvest Paws *must* un-stage unstage a realizing execution after a single combination.
<ELLIOTTCABLE>
A) for what is likely the most common single staging, we can special-case it and make it “synchronous”, i.e. on-the-stack, because we *know* it preforms no asynchronous operations. Specifically, the receiver for Things.
<ELLIOTTCABLE>
that means a sequence of ‘component’-lookups, not abstracted in any way (`foo bar baz`) can be preformed on the stack, without unstaging.
<devyn>
yes
<devyn>
I was thinking about that
<devyn>
in fact I was thinking that all native operations could basically choose whether they want to respond immediately or not
<devyn>
and then that would get propagated
<devyn>
so like the native handler could either return a response immediately
<devyn>
and the reactor would just continue
<devyn>
hmm
<devyn>
maybe
<devyn>
native handler could return a staging
<devyn>
or not
<devyn>
like
<devyn>
Option<Staging>
<ELLIOTTCABLE>
Spilled soda on my laptop.
<ELLIOTTCABLE>
And now leaving for haircut. Back soon.
<devyn>
lol
<purr>
lol
<devyn>
okay
oldskirt_ has quit [Read error: Connection reset by peer]