wmeyer has quit [Remote host closed the connection]
wmeyer has joined #ocaml
dsheets_ has quit [Read error: Operation timed out]
breakds has quit [Quit: Konversation terminated!]
<wmeyer>
yoohoo trematch build
<wmeyer>
built
<wmeyer>
it was almost flawless pippijn
<wmeyer>
just need for your librarires
<pippijn>
and the c++ flag
<wmeyer>
yes and the c++ flag
<pippijn>
someday I'll have flag compatibility detection
<pippijn>
easy to do, I'm just lazy
<wmeyer>
OK looks good
Drup has quit [Quit: Leaving.]
<wmeyer>
pippijn: what is stopping you at the moment?
<pippijn>
stopping me?
<pippijn>
nothing
<pippijn>
I'm coding
<wmeyer>
no no, i mean in treematch, what would be a feature you want, i ran ditz and it helps. From what I think would be good is to make treematch closer to k-framework
n06rin has quit [Quit: Leaving.]
<pippijn>
yeah
<pippijn>
I don't know what treematch needs now
<pippijn>
I want to declaratively specify C semantics
<pippijn>
static semantics first
<pippijn>
treematch is supposed to help in compiler construction
<pippijn>
what does a compiler need?
<pippijn>
- parser (got it already)
<pippijn>
- semcheck (treematch?)
<pippijn>
- transformations and IRs
<pippijn>
- codegen
<wmeyer>
well we both know it what we need
<wmeyer>
I can take treematch, but I don't expect having too much time on the rest :)
* wmeyer
sneaks silently to bed.
<pippijn>
:)
<wmeyer>
but thanks I am going to look at the semantics part
<wmeyer>
the idea is to make it as declarative as K-framework but with few extrans and performance
<pippijn>
yes
<pippijn>
that would be awesome
tchell has quit [Ping timeout: 264 seconds]
tchell has joined #ocaml
<wmeyer>
plus this build a compiler so so don't need full semantics
<wmeyer>
for an interpreter you need full semantics, for the compiler just enough to make the transformation possible
<pippijn>
sure
<pippijn>
but
<pippijn>
what about constant evaluation?
<wmeyer>
still not full semantic
<wmeyer>
semantics*
<pippijn>
not in C
<pippijn>
but consider this:
talzeus has quit [Remote host closed the connection]
<pippijn>
int square (int a) { return a * a; } char buf[square (3)];
<pippijn>
if you want to allow arbitrary computations in constant functions, you need a pretty large part of the semantics
<wmeyer>
not really, as this can be done at init when the program is executed
<pippijn>
no
<wmeyer>
you want this to be static?
<pippijn>
sizeof is a compile time operator
<wmeyer>
at compile time?
<pippijn>
yes
<wmeyer>
well, the declaration of the array tells me that
<wmeyer>
and I though you want this to be static
<wmeyer>
however I'd then advise to do such thing
<wmeyer>
int square (int a) { return a * a; } char buf[$square (3)$];
<wmeyer>
to ensure that the stages are separated
<wmeyer>
and don't depend on the syntax
<pippijn>
why $$?
<pippijn>
why does it need to be special?
<wmeyer>
it tells to force the chunk of code to be evaulated in the level before
<pippijn>
but we already know that
<wmeyer>
because then, how do the frontend knows that it has to be evaulauted
<wmeyer>
it knows from the syntax
<wmeyer>
user probably too
<pippijn>
because array bounds require compile time constant expressions
<wmeyer>
so I'd suggest something better than macros
<wmeyer>
of course I do understand it
<pippijn>
no need for $$
<wmeyer>
but it's hardcoded and not syntacticaly districtive
<wmeyer>
what if we have something like this
<wmeyer>
char * p = new char[ square(3) ];
<wmeyer>
now it's less clear if you want to force square(3) :)
<pippijn>
you know it from the syntax
<wmeyer>
however the compiler will probably inline this anyway
<pippijn>
NewDeclarator does not require compile time constants
<pippijn>
it's a simple match to find out
<wmeyer>
I understand it, but it's not clear for somebody who learns C++ :)
<wmeyer>
that's what I think
<wmeyer>
if you put it into $ $ it becomes immediately clear
<pippijn>
is that your rationale?
<wmeyer>
yes, that's my rationale
<pippijn>
there is no other reason?
<wmeyer>
C++ is full of flowers like this
<wmeyer>
(I did understand on the first glance what you meant, but in this case I'd rather be explicit)
<pippijn>
ok
<pippijn>
but
<pippijn>
we could specify the semantics to be dynamic, always
<pippijn>
and simply perform as much static evaluation as possible
<wmeyer>
oh you want partial evaulator
<wmeyer>
like MLton
<wmeyer>
well, yes that's nice
<wmeyer>
but in this case, you have to do this
<wmeyer>
what if you have
Neros_ has joined #ocaml
<wmeyer>
int x; char buf[ sqrt(x) ];
<wmeyer>
or
Neros has quit [Ping timeout: 264 seconds]
<wmeyer>
int x; <object that updates in the constructor x>; char buf[ sqrt(x) ];
<pippijn>
right
<wmeyer>
it becomes blurry!
<pippijn>
I think
<pippijn>
constant functions should be constant
<pippijn>
pure
<pippijn>
even if they have side effects inside
<pippijn>
but no globally visible side effects
<wmeyer>
that's fine, then all the arguments should be constant?
<pippijn>
hmm
<wmeyer>
then it's quite limited but still nice
<pippijn>
no
<pippijn>
it can modify pointers
<pippijn>
but no global variables can be passed
<pippijn>
then it's no longer a constant call
<wmeyer>
what could be nice in C++ is to depend on template arguments and enums :)
<wmeyer>
and consts
<pippijn>
basically a generalised constexpr
<pippijn>
D has cool compile time stuff
<wmeyer>
I'd rather remove need of static stuff in C++, let's say in ocaml you say
turnersr has joined #ocaml
<wmeyer>
let array = let a = Array.create 42 "foo" in Array.iteri (fun x i -> a.(i) <- x ^ bar) a; a;;
<wmeyer>
and this will be inited at runtime
<wmeyer>
no static bss section no fear
<wmeyer>
it has penalty
<wmeyer>
of course
<wmeyer>
but then again compiler can do some trick to make it faster
<wmeyer>
so the source of the problem is not static <-> dynamic interaction, but rather that the arrays should have compile time known size in C
<pippijn>
partial evaluation would be nice
<pippijn>
you can evaluate everything up to the point where non-deterministic input comes into the picture
<pippijn>
argv/IO
<wmeyer>
yes
<wmeyer>
but that's a different storry
<wmeyer>
I can ensure that you can't do it in C++ to large extent
<wmeyer>
ad the semantics are unspecified in many cases
<pippijn>
type-checking C++ requires a data model
<pippijn>
so you need to specify unspecified semantics, anyway
<wmeyer>
I don't think you can partially evaulate C++ programs to the extent you would be happy :)
<wmeyer>
design your C subset so it's possible!
mfp has quit [Ping timeout: 246 seconds]
<wmeyer>
I am going to bed now pippijn (being sceptical from many angles about this to be honest)
madroach has quit [Ping timeout: 264 seconds]
<pippijn>
hehe
<pippijn>
wmeyer: don't worry about it
<pippijn>
static semantics are more interesting
<wmeyer>
pippijn: i try not to be worried at the moment :)
<pippijn>
to me
<pippijn>
I don't need a partial evaluator
<wmeyer>
OK, let's see what we can squeze from treematch
cyanure__ has quit [Remote host closed the connection]
Arsenik has joined #ocaml
Arsenik has quit [Remote host closed the connection]
thomasga has joined #ocaml
eikke has joined #ocaml
tobiasBora has joined #ocaml
mort___ has joined #ocaml
<gasche>
I'm just back from one week without a laptopt or internet access
<gasche>
(but apparently I still automatically complete "op" into "opt")
<gasche>
the flood of emails and other news is exhausting
<gasche>
I was expecting an OCaml release to have happened last week, but apparently it's yet to come -- very soon
penryu has joined #ocaml
<gasche>
def-lkb: I just saw that you changed the Merlin protocol implementation to use a GADT internally
<gasche>
it's nice, and it's something I've been planning to do myself for a few weeks now
<gasche>
(but I hadn't because there was no good rationale for the change, except "it looks nicer", which is no good reason to touch code that works)
<rks`>
well, we had been talking about it as well
<rks`>
but didn't do it because the protocol was still changing a lot
<rks`>
but since more people start to have a look at merlin, it seemed like a thing we should do to make the thing more accessible
<gasche>
agreed
<gasche>
and the code mixing JSON parsing and request handling was ugly
<gasche>
hm
<gasche>
for a little story, when my girlfriend asked me to explain what GADTs are, I used precisely the merlin protocol use-case as a good usage case
<rks`>
:D
<penryu>
reading through RWO, what is the significance of explicitly labelling and using the ~f label for List.map and friends, even when the func argument always appears in the same place it would anyway?
<def-lkb>
gasche: Thanks. This typed version is not yet perfect, the tell command need slightly more expressivity than what current gadt type allows
<pippijn>
you need a japanese font to display japanese text properly
<flux>
(RC1 that is)
<flux>
who would think ocaml even has so many bugs?-)
<pippijn>
and a lot of chinese characters are not in the japanese font, so when you display a text and don't know what language it is, you'll find that a lot is missing
<Obfuscate>
mrvn: What's a reason why a site should not be sending language information in the headers?
<mrvn>
pippijn: That is a bit like different fonts though.
<pippijn>
so then you start guessing the language and find, oh, it's probably chinese
<pippijn>
so we need to switch fonts
<mrvn>
Obfuscate: The site should use the language the user requested.
<pippijn>
mrvn: why would you need different fonts in the first place?
<mrvn>
pippijn: because even 32bit aren't enough to include every font in existance, not to mention future fonts.
<pippijn>
you should need different fonts for making the same thing look different, for aesthetic reasons
<Obfuscate>
mrvn: That's not an answer to my question, although it might have been a valid response to a misinterpretation of my first statement.
<pippijn>
but han characters look different with different meanings
<flux>
although it's not quite perfect for that use, as you now need a fake object to search (which can be difficult to construct)
<pippijn>
it should be possible to produce one font that allows you to print text readable to anyone who knows the language it's written in
zpe has joined #ocaml
<pippijn>
so if you have a japanese text, you can print it with that font, and a chinese text which you can print with the same text
<mrvn>
pippijn: your url says the han charachters are the same just drawn differently depending on local customes but people will understand the char even if drawn differently. So it's like Time New Roman vs Courrier.
<pippijn>
ok
<pippijn>
then the url is wrong
<mrvn>
pippijn: possible. You need a different one to support your argument then.
<pippijn>
I don't have another url
<pippijn>
only own and other people's experience
<mrvn>
"Han Unification is designed to preserve legibility. Documents typically can be simply displayed in the font preferred by the user." But maybe that has failed.
<pippijn>
(educated) japanese people who can't read a japanese text because the text mode was chinese
<pippijn>
the font was chinese
<pippijn>
consider Times New Roman, which is readable to everyone who knows latin characters and arabic numerals
<mrvn>
well, don't use that font then. If I use a greek font to display my ascii text I can't read it too.
<pippijn>
exactly
<mrvn>
I don't quite see how you make that a fault of unicode.
<pippijn>
so if a is displayed as α
<pippijn>
that's bad :)
<pippijn>
mrvn: the point is, there is *no* font that can display a text in chinese *and* a text in japanese
<Drup>
mrvn: the point he is trying to make is that the differienciation between the (apparently) different set of character should be at the encoding level, not at the font one.
<pippijn>
that's what I thought the point of unicode is
<mrvn>
Drup: the character is the same, the glyph differs.
<pippijn>
so that you don't need to select an english font
<pippijn>
if you want to read an english document
<mrvn>
Only problem I see is that sometimes you want both glyphs in the same text. E.g. in the text describing the differences of the glyph in japanses and chinese rendering.
<pippijn>
if the glyph is sufficiently different that people can't read it, I consider it different
<pippijn>
I don't know examples of this personally, just from japanese people
<mrvn>
Personally I would throw away all those chinese and japanese glyphs and stick with latin.
<pippijn>
:)
<mrvn>
utf8/ucs32 is such a pain to deal with.
<pippijn>
ucs4*
<adrien>
I'd throw away the germans too :P
<mrvn>
wastes tons of memory, is dead slow and 99.999999999999% I don't need it.
<pippijn>
utf8 doesn't waste memory on latin texts
<pippijn>
it does on german texts
<pippijn>
ä
<mrvn>
pippijn: you need to store the number of bytes and chars of a string. wastes memory.
<pippijn>
c3 a4 or something
<pippijn>
mrvn: why do you need to do that?
<mrvn>
or compute it every time. same difference.
<mrvn>
see dead slow
<pippijn>
utf8 works fine as null-terminated
zpe has quit [Ping timeout: 245 seconds]
<mrvn>
pippijn: then please replace the 3rd char in the string
<pippijn>
that's an O(n) thing, yes
<mrvn>
it's O(1) in latin
<pippijn>
if you want O(1) indexing in utf8, that's sad
<pippijn>
you need to store offsets
<mrvn>
or use ucs32
<pippijn>
and at that point you might as well store ucs4
<mrvn>
but wait, even that isn't enough
<pippijn>
mrvn: utf32 or ucs4
<pippijn>
right, that's not enough
<pippijn>
welcome combiners
<mrvn>
and then you can't simply compare to utf-8 strings. you have to normalize them first
<pippijn>
same for ucs4
<pippijn>
19:24 < pippijn> # "ä" = "ä";;
<pippijn>
19:24 < pippijn> - : bool = false
<mrvn>
is that "a and ä?
<pippijn>
yes
<mrvn>
Seriously. Who thought "a was a good idea if you already have ä?
<pippijn>
maybe for p̈
<mrvn>
If there is a "p then make a char for it
<pippijn>
I don't know
<pippijn>
I think I disagree
<pippijn>
they did that to korean
<mrvn>
or if you allow "a then don't make a Ä
<pippijn>
and indic
<pippijn>
korean characters could be a base character and combiners
<pippijn>
very easily
<pippijn>
but no, they put in every single combination
<mrvn>
having both just means equal utf-8 can fail to compare in non utf-8 aware code.
<pippijn>
most code is not unicode-aware
<pippijn>
even when using utf-8 strings
<mrvn>
and will fail,. like ocaml above
<pippijn>
does camomile normalise?
ollehar has quit [Quit: ollehar]
<mrvn>
I wonder, what is the longest utf8 char you can make with combines?
<pippijn>
infinite
<pippijn>
you can add the same combiner over and over
<technomancy>
if I use ptr_opt, it works in the null pointer case, but segfaults when a real string is provided
<technomancy>
if I don't use ptr_opt, it works with a real string but not a null pointer
<wmeyer>
pippijn: :)
<technomancy>
for some reason ptr_opt wraps the return value in both a ptr *and* an option, which seems redundant
<technomancy>
what I really want is a string option, but I get a string ptr option which segfaults when I try to deref it even though I know the underlying function is returning a proper string
<wmeyer>
oh ctypes, hot stuff!
<wmeyer>
:)
<technomancy>
wmeyer: it'd be cool if there were docs thou
<technomancy>
(I found ctypes-tutorial, but it doesn't cover this topic)
zpe has quit [Ping timeout: 245 seconds]
<technomancy>
it's probably obvious what's going on if you know C, but it's got me stumped
<pippijn>
did you try gdb?
<technomancy>
I've never used gdb; are there docs on how to use it with ocaml?
<technomancy>
I think it's pretty clear what's going on; it's obviously dereferencing a null pointer
<technomancy>
but it doesn't make sense why ctypes is returning a null pointer
<technomancy>
because when I remove ptr_opt it works great
<pippijn>
ok, can you tell me how to build and run this?
<pippijn>
can you produce a testcase that I can feed to ocamlopt?
palomer has quit [Ping timeout: 264 seconds]
chambart has quit [Ping timeout: 263 seconds]
<technomancy>
https://github.com/technomancy/grenchman <- it's the "repl" branch here; you can compile with `opam install core async ocamlfind && ocamlbuild -use-ocamlfind grench.native` and repro with `LEIN_REPL_PORT=0 ./grench.native repl`
<technomancy>
erhm; add ctypes to the opam install list
<pippijn>
:\
<pippijn>
yeah, I'm not going to do that
<rks`>
:D
<pippijn>
good luck
<technomancy>
yeah, putting together a smaller repro case; hang on
<pippijn>
wmeyer: I'm still amazed at how subtly I broke the GLR core
<pippijn>
in two ways
<wmeyer>
hi rks` \o
<pippijn>
and I'm still thinking about how it can be made faster