IRC channel logs


back to list of logs

<galex-713>Are “variants” like in ocaml possible with guile?
<galex-713>That is a type that can be multiple types, in order to define data structures
<ijp>yes and no
<ijp>in Scheme, types usually correspond to predicates, so variants boil down to a macro that generates a bunch of different record types and a common predicate for all
<ijp>possibly with some sort of typecase to destructure
<ijp>this has probably been implemented 578 times as a macro
<galex-713>ijp: why not (define (myvariantp val) (or (typep val) (typep val))?
<ijp>which is what said macros usually do
<galex-713>ah ok
<zv>fqn amb evaluator
<zv>in goops
<zv>come at me
<daviid>zv: what is it with goops?
<zv>amb evaluator
<galex-713>ijp: is there a way to make records with fixed-type members?
<galex-713>like, to make them less expensive
<galex-713>Like you do in C or OCaml
<ijp>you can, but it won't make them cheaper
<ijp>except for arrays
<galex-713>ijp: for arrays?
<galex-713>ijp: you can specify the type on an array?
<galex-713>can you make records from arrays to improve performance?
<galex-713>What would be the more like a C struct?
<galex-713>ijp: ^
***wleslie is now known as toothlesshd
***toothlesshd is now known as wleslie
<davexunit>galex-713: typed structs aren't available yet.
<davexunit>I started writing a simple struct unboxing implementation, but it turns out that it's not what the guile maintainers ultimately want.
<davexunit>there needs to be some overhaul of structs.
<davexunit>I want my game engine to take advantage of f64 unboxing in the new guile. I have record types for things like 2d/3d/4d vectors that would benefit greatly from their fields being unboxed.
<dsmith-work>ijp: 579 is not quite correct. More likely 583
<dsmith-work>Thursday Greetings, Guilers
<lloda>aren't f64vector ops already unboxed? at least in master
<davexunit>lloda: yes
<davexunit>lloda: but there are optimizations that cannot be made yet, like storing f64s in structs
<davexunit>I mean, you can store f64s in structs, but the compiler cannot unbox references to them
<davexunit>a hack that I've tried is to use a struct with a single field that is an f64vector, but it made my code significantly more difficult to work with.
<davexunit>I wasn't able to squeeze out enough of a performance boost to make it worth it.
<ruste>davexunit: Just used haunt to build my github page. Fantastic stuff.
<ruste>Randome scheme question. Suppose I want to make a macro that takes two symbols and expands to a pair of define statements that assign them values. I can't think of a way to do that.
<davexunit>ruste: oh cool! glad you like it!
<davexunit>I wrote the damn thing, yet I still have a half-finished blog migration...
<davexunit>still using pelican and haven't blogged in a year...
<ruste>Maybe with a lisp style macro and an unquote, but that just feels icky.
<davexunit>ruste: re: macro, you can do that.
<davexunit>(define-syntax-rule (define-some-stuff one two) (begin (define one 1) (define two 2)))
<davexunit>(define-some-stuff foo bar)
<davexunit>;; => 1
<davexunit>;; => 2
<ruste>Yeah! I've been trying to write up all my projects! It'll be a while.
<davexunit>'begin' is interesting. definitions within the 'begin' form are hoisted into the place where 'begin' appears
<davexunit>so, if this macro was used at the top-level of a module, then the definitions would apply to the top-level of that module.
<ruste>Okay. I'll have to try that in 2.0 when I get home.
<ruste>1.8 is being finnicky.
<ruste>That is interesting. That's not what I would have expected.
<davexunit>ruste: 1.8 is ancient.
<davexunit>I don't recommend using it at all.
<davexunit>the 2.0 series has been out for many years
<ruste>I did my best to compile 2.0 for windows but to no avail.
<ruste>1.8 is the only one in cygwin.
<davexunit>oh, windows.
<ruste>I sorely miss my linux environment at work.
<davexunit>no one really uses windows around here.
<davexunit>but I think that one or two people submit patches to help make guile work better/at all on windows
<davexunit>so hopefully some day
<ruste>Yeah. I tried building 2.0 in a shell account I have but I've only been able to build it from source on slackware on my chromebook.
<ruste>Hopefully someday. That would make game development in guile a lot more interesting.
<ruste>Having a much wider audience.
<davexunit>I've built guile from source on a number of distros
<davexunit>it works just fine on any gnu/linux distro or os x
<ruste>I've always had trouble with declarations in pretty basic libraries.
<ruste>I think the shell account I'm building it on is gentoo.
<ruste>Getting something about pollfd being declared or defined strangely.
<ruste>I think I've run into similar problems whenever I've tried in the past.
<davexunit>I don't know what gentoo's problem is, but the guile packages in their repos have been messed up for years
<davexunit>whoever maintains those has no idea what they are doing.
<ruste>Yup. It's a shell acount though so I can't just install a package without a lot of effort so I'm just building from a tarball.
<koosha>Hello friends !
<koosha>Is there some cheet sheet for guile ?
<dsmith-work>koosha: No cheating!
<koosha>dsmith-work: hahha , Okay , thanks .
<ruste>koosha: I usually just keep the latest manual open as one giant page in my web browser and C-f when I need something.
<koosha>ruste: Where do you mean ?
<ruste>Does anyone here regularly use GOOPS? I don't think I've ever seen it used.
<galex-713>ruste: I think it is only used for OOP libraries, like GTK+
<galex-713>But I’m not sure many lispers do like OOP
<ruste>galex-713: That's pretty much the the impression I got.
<galex-713>cl is different
<galex-713>Yet there’s none in elisp, and that’s cool
<galex-713>OOP is so much full of shit
<ruste>I think it has its uses but pretty much all of its proponents take it waaay to far.
<ruste>You don't need OOP in a language to write OOP code.
<ruste>I think most of my code ends up being relatively object oriented.
<ruste>And I write mostly scheme and c.
<galex-713>object oriented means abstraction/encapsulation + heredity + polymorphism
<galex-713>Only polymorphism is useful here, and yet it becomes a nightmare with heredity
<galex-713>But OOP is awful
<galex-713>At least you maybe need a good type system, but not OOP
<galex-713>C structs+unions are way enough powerful
<ruste>Fare enough.
<galex-713>Far or fair? :p
<ruste>They keep it way too cold in here. Hard to type with numb fingers.
<webshinra>(i'm a lipster and I like OOP)
<galex-713>webshinra: (then you’re not a real one :p)
<webshinra>(say the one which defend the C type system)
<dsmith-work>Yeah, I never got the whole OOP thing either
<dsmith-work>webshinra: lipster ;^)
<ruste>I think we're the lipsters.
<ruste>Common lisp has us beaten on implementation standardization and popularity.
<ruste>It's too bad they're just too blind to see that guile is the best lisp.
<galex-713>The best “lisp” is epsilon
<galex-713>It’s kinda like ε > guile > scheme > elisp >= common lisp > C > *
<ruste>galex-713: ypsilon?
<galex-713>If we were talking about kernels, common lisp would be linux, scheme would be BSD, guile would be Open/NetBSD and epsilon would be hurd
<ruste>Huh. Looks neat.
<ruste>So it's a performant kernel that will have a variety of relatively general dsls built on top with the option to customize and add more?
<galex-713>dsls ?
<ruste>domain specific languages
<galex-713>Ah yeah
<ruste>But not really in this case.
<galex-713>Yes globally it is
<ruste>Much more broad.
<galex-713>There are like a few dozens primitives on which you base any programming language you want
<ruste>Huh. Personally guile = C > Scheme >> all else.
<galex-713>C is not that cool
<galex-713>C lacks a REPL
<davexunit>C is just about the worst language around.
<ruste>I like it for the same reason I like guile.
<galex-713>It does not have read, nor eval, nor print
<galex-713>This is a shame
<ruste>Both get out of my way, just in different ways that are useful to me in different ways.
<galex-713>Although it is hardly extensible
<galex-713>C is cool only because it is fast and widely used
<galex-713>So we use it until guile/epsilon becomes better
<ruste>Guile doesn't impose any sort of paradigm on me.
<galex-713>nor do epsilon…
<galex-713>But certainly C does
<ruste>C doesn't care at all what I do with it.
<ruste>Do the wrong thing, seg fault.
<galex-713>C is hard and ask you to do lot of useless stuff
<ruste>It'll let me do anything.
<ruste>Yes, it does.
<ruste>That's why I use guile most of the time.
<ruste>But C has its uses.
<ruste>While it does enforce a paradigm. It's a trade for the power and less of a trade than C++
<ruste>ACTION shudders
<ruste>At this point I only touch C if I have to, but I prefer it to many of the alternatives.
<mordocai>Is up to date on the state of GuileEmacs?
<koosha>Why guile doesn't accept this code ? : ( define (foo) (define x 4 ) )
<dsmith-work>mordocai: I think it is as far as bpt's code. There have been Guile releases since then, so there may be issues..
<dsmith-work>koosha: There is no value returned
<koosha>dsmith-work: Is it needed ? I just want to edit the x value in my function .
<galex-713>koosha: use set!
<galex-713>and declare the var before
<dsmith-work>The inner define is creating a new binding.
<dsmith-work>koosha: Pretty much the same as (define (foo) (let ((x 4)) ))
<koosha>galex-713: Oh , It worked .
<koosha>dsmith-work: But why defining it is wrong ?
<galex-713>koosha: because you are defining a new variable with the same name but more local scope
<galex-713>like (let ((var 1)) (display var) (let ((var 2)) (display var)) (display var)) prints 121
<galex-713>not-top-level define are equivalents to let
<galex-713>It’s in the doc ;)
<dsmith-work>(define (foo) (let ((x 4)) #! must be an expression here !# ))
<galex-713>yeah that also
<galex-713>more precisely, I explained what was going on, not why wasn’t it going to work x)
<galex-713>Anyway, even if it worked, at the end of your foo proc, normally x would have the same value, which is completely useless
<galex-713>So void let are not allowed because useless
<dsmith-work>It a thing that doesn't make sense. Like (define x) or (set! x)
<dsmith-work>Must be a value in there
<avoine>mordocai: you ask because of this article?
<koosha>Right . Where can I read about it in doc ?
<avoine>this guile-emacs related story just land in the ycombinator front page
<ijp>(define x) works
<dsmith-work>ijp: Hmm. Ok. Bad example.
<ijp>it arguably shouldn't, but that ship has sailed
<galex-713>dsmith-work: you use (define x) to declare your variable (and its scope) before to use it
<galex-713>Even if it’s probably bad programming style
<koosha>Thank you .
<dsmith-work>koosha: "The expressions in body are evaluated in order, and the value of the last expression is returned as the value of the let expression."
<galex-713>ah yeah, that is because define returns <undefined> while let doesn’t
<dsmith-work>koosha: Must be one or more expressions in body
<galex-713>That’s so bad define doesn’t return the defined symbol, like elisp
<galex-713>also that if returns undefined instead of nil sometimes :(
<galex-713>or stuff like that
<ijp>the symbol wouldn't help you at all
<galex-713>let could return <undefined> or nil
<ijp>what's nil?
<galex-713>ijp: I already made macros/functions using that
<galex-713>ijp: it’s the common-lisp/elisp void list, (), except you can use it as #f too
<ijp>anyway, definitions are segregated from expressions
<ijp>galex-713: I know what it is, but guile doesn't use it
<ijp>(except for elisp compatibility, and even that doesn't work right)
<ijp>so the return value of a definition doesn't make sense
<galex-713>I prefer elisp’s style
<galex-713>It’s like common-lisp, without the bullshit
<galex-713>Yet scheme has all these cool stuff like named let, etc…
<mordocai>avoine: Yeah, that's why I asked
<avoine>mordocai: I think the latest version is in that branch:
<avoine>but this is still a work in progress
<mordocai>Yeah, I might see if I can get it up and running at home to try it out. Looks like latest commit was march so relatively recent