quamaretto has quit [Read error: 104 (Connection reset by peer)]
quamaretto has joined #ocaml
ski has quit [Read error: 104 (Connection reset by peer)]
Smerdy has joined #ocaml
Smerdyakov has quit [Read error: 104 (Connection reset by peer)]
Smerdy is now known as Smerdyakov
Smerdyakov has quit ["oh bother"]
Smerdyakov has joined #ocaml
Smerdyakov has quit [Read error: 104 (Connection reset by peer)]
Smerdyakov has joined #ocaml
khaladan has quit [Connection timed out]
Smerdyakov has quit ["Leaving"]
Smerdyakov has joined #ocaml
pango__ has joined #ocaml
pango_ has quit [Read error: 145 (Connection timed out)]
<schlick>
I've been looking at how E is implemented (while trying to reason out how to do something else). Apparently it has a very limited core language (Kernel E) and a preprocessor (that you have no control over, so most of the problems with C's preprocessing can't occur) that hides things like that higher level aspects are implemented in lower level ones
<schlick>
I wonder how reasonable it would be to make a preprocessor like that, that would be extensable, i.e. let you add on new language constructs, but not change existing ones.
<schlick>
I'd be interested in people's thoughts on this.
<Smerdyakov>
See camlp4.
* schlick
laughs.
<schlick>
From just glancing this over it seems to be exactly what I had in mind.
<schlick>
The main reason I was thinking about doing it was it might help me avoid having to write quite so much to build a higher level language on top of my lower level one, which I hope to keep the syntax fairly similar on, but the lower level one would have to implement the garbage collection and threading and such. Is that a fairly reasonable way of going about things?
<schlick>
Similar needs seem to have caused the E authors to do their work via a preprocessor.
<Smerdyakov>
You may underestimate the power of the non-camlp4 facilities that OCaml offers.
<schlick>
I'm not sure I know what you mean.
<Smerdyakov>
You don't need to extend syntax when you already have a powerful enough language.
<schlick>
Well, that's true. My compiler project is sort of strange... I'm trying to make a programming language that sort of straddles the mid-level and high-level language area. I don't think I could write a garbage collector in a garbage collected language. And using a high level language for writing kernels is tricky (I think I found a way to have garbage collection still).
<schlick>
My approach to it is to have 3 basic modes (there's more than that). There's the usual application level one, the kernel one (it provides some special structures only kernels need, and adds some sanity checking for their use), and the compiler level (which is manual memory managment, and lacks most of the higher facilities).
<Smerdyakov>
There is so little work to be done on such things that we generally use a separate language for them, instead of polluting high-level languages with extra support.
<schlick>
I'm not sure I could do a kernel in OCaml.
<schlick>
Well, I agree. The way I was looking at it though is kernels have a LOT of bugs (Linux tries very hard but still has quite a few in the drivers). Strong static checking could help /a lot/. At the same time it'd be nice to not have to learn multiple syntaxes. The different "modes" would add or remove different features. For instance, outside the kernel and compiler mode you don't have access to anything resembling manual memory
<schlick>
instance, outside the kernel and compiler mode you don't have access to anything resembling manual memory managment.
<Smerdyakov>
I think that should be more of a meta-design principle, to be applied to distinct languages.
<schlick>
It seems like most of the guts of a high level and low level language compiler would be the same.
<schlick>
I'm not sure what you mean by applying a meta-design principle with different languages.
<Smerdyakov>
Use this to design multiple languages, not just one.
<schlick>
I'm not trying to be dense by the way. Just not sure what you mean.
<schlick>
Well, I don't disagree, but I'm not exactly sure what would have to be different. The compiler mode would have to provide some way of hardware-atomic operations to let you build a threading library (amongst probably other "special" things), and would have to be manually memory managed. I don't see that that would change most of the rest of the syntax/functionality.
<Smerdyakov>
Every function value in ML is allocated in the heap, conceptually, for example.
<Smerdyakov>
You don't want that in a kernel programming language.
<schlick>
A function value refers to the value a function returns?
<Smerdyakov>
Any function.
<schlick>
If so I'm not really sure why that would be on the heap unless it's for fear of stack overflow.
<Smerdyakov>
Every function is a closure.
* schlick
nods.
<Smerdyakov>
Dynamic allocation is a fundamental part of ML semantics.
<schlick>
I would have thought it'd just use pointers to whatever data was there.
<Smerdyakov>
Pointers to dynamically allocated data, which is required in general.
<schlick>
Well, yes. Certainly as I beat my head against things more I'm starting to understand why C did some of the things it did (some of them are just plain bad though). It's also become blatantly apparent that next to nothing should be written in C, other than the kernel and run time environments for compilers, which it seems remarkably well suited for.
<schlick>
I'd agree that applications level languages should be garbage collected.
<schlick>
I was hoping a preprocessor might spit out code in the low level language sufficient to allow it to be fully garbage collected (by working with libraries written in the low level form, the "compiler mode"), but if you wrote in compiler mode you wouldn't be able to have that.
<Smerdyakov>
You don't want to do that. You lose semantic information, which makes analysis for optimization and other purposes harder.
<schlick>
...while still keeping most of the parsing and back-end the same.
<schlick>
I hadn't thought about the optimization problem.
<schlick>
I know higher level languages provide more opportunity there. I thought correctness wise the higher level forms of the language could perform their checking before passing it to the lower level form.
<Smerdyakov>
There is no reason for that lower-level form to be thought of as a source language. Common intermediate languages are common.
<schlick>
By that you mean there's no need for me to preprocess the high level one into the low level one, before hading it off to, say, a SSA optimizing back end?
<Smerdyakov>
What I'm saying is that "preprocessing" indicates outputting a language designed for human use.
<Smerdyakov>
Compiler infrastructure often involves common formats outputed by multiple generators, but they aren't meant to be read or generated by humans.
<schlick>
The harm being that human needs might diverge from compiler needs?
<Smerdyakov>
These things aren't even "languages" usually, but rather data structures optimized for various purposes.
<schlick>
Like SSA and ANF, I assume?
<Smerdyakov>
Yes.
<schlick>
I knew about the different stages of compilation. Basically where I went off on this tangeant is I knew I wanted a programming language suited for OS authorship, compiler authorship, and applications programming. Before I got into really low level details it didn't occur to me what some of the problems with having one language would be.
<schlick>
Mainly there's a gap between mid and high level, specifically that the mid level has to expose things on as high a level as possible that the high level can be implemented in, but you can't implement a garbage collector when you have no manual control of memory.
<schlick>
To try to keep the mini-languages as similar as possible to, for instance, reuse the parsing/lexing and some of the static checking, I thought a preprocessor for the higher levels might do the job.
<schlick>
Depending on the 'mode' you picked in compiling stuff you'd get different preprocessing and static checking. It'd be invisible to you, though.
<Smerdyakov>
There is so little work on anything not in the "high-level" category that it is a waste of time to generalize a system for such tasks.
<schlick>
I guess at this point I'm having trouble seeing the problem with the idea of that.
<schlick>
Well, assuming I was wanting to do that range of tasks (write kernels, write a language runtime, and write applications) would there be any harm in implementing it that way? The only thing I can think of is the optimization which you mentioned.
<schlick>
And I have to admit to not knowing a way around that...
<schlick>
It'd be a whole program compiler so hopefully it wouldn't matter much.
<schlick>
I could probably do some optimization in the preprocessing stages. I think that'd work.
<schlick>
Basically the goal behind all this is to use Linux (my preferred OS) to get the language off the ground. The language would expose almost all of the future OS application-level API. Then use the language to write the kernel, then cross compile the compiler, then shift everything over. If a eye is kept toward portability it should be possible to implement it on Windows too.
<Smerdyakov>
I don't know. It sounds to me like you are planning too much with too little experience.
<schlick>
From there, most source code written by Windows and Linux programmers for the language could just be recompiled to run on the new (hopefully much more stable) OS.
<schlick>
Oh that's quite likely. :P
<Smerdyakov>
Trying to plan interfaces, extensible systems, etc., without specific, concrete examples of usage is always a losing battle.
<schlick>
There's two primary things that bug me about software. One is the stability, one is the security. OS wise Linux is pretty stable. There's little irritants like my DSL modem driver has to be reloaded periodically because it's doing something wrong (which may be in the firmware, Windows folks have the same problem).
<schlick>
Linux and Windows are on par security wise, at least as far as their design is pretty much the same (static ACLs).
<schlick>
The need to implement a new OS when you can fix the security problem by building capabilities on top of ACLs (doable on Windows and Linux, Windows has holes you can't fully plug due to the GUI implementation but Linux doesn't), is questionable, I admit.
<schlick>
Whether Linux is "bad enough" to justify a new OS, especially given you'd have problems with getting software.
<Smerdyakov>
I'm not talking about what the developer community as a whole should do. I'm talking about what you should be planning now to do yourself.
<schlick>
Well, basically the whole thing is a integrated goal. I'm just trying to gather information on how to do it all. I realize it'll be hard. I try not to think about that too much because it's already obviously hard. It is, at least, interesting to try at.
<schlick>
I've settled on what I want to do about the two things that bug me, right now it's figuring out how to implement the fixes.
<schlick>
Capabilities I understand fairly well. I'll have to look at the guts of E more to see how to implement it, but it's not huge. Static checking wise there's a lot more variety, and it's a lot less approachable. I'm still trying to figure out what combination of techniques to use, and to try to understand everything.
<schlick>
As far as the specifics about the preprocessing, there are two "special cases" I've run into crossing the mid-level to high-level barrier. To implement a run time you have to limit yourself to data sizes the hardware can work with directly. A little more specifically I can't make the register width of the processor 'invisible'. You'd see function calls to a bignum library everywhere.
<schlick>
First I considered two compilers, then I remembered something I read about E, and looked at how they were doing some things, and thought a preprocessor might fix that problem.
<schlick>
Strings suffer from similar problems.
<schlick>
Anyway, sorry if I bored you. I don't claim to have lots of experience implementing new languages and OS's. I'm just trying my hand at it. Some things about software bother me and I'd like to fix it, since I have to use it, that's all. I figure the language level is the best place since that fixes whatever is written in it.
m3ga has quit [Read error: 104 (Connection reset by peer)]
bluestorm has joined #ocaml
quamaretto has quit [Read error: 110 (Connection timed out)]
_JusSx_ has joined #ocaml
Skal has joined #ocaml
ski_ has joined #ocaml
ski_ is now known as ski
ski is now known as ski_
pango__ is now known as pango
Revision17 has joined #ocaml
Bigb[a]ng is now known as Bigbang
revision17_ has quit [Read error: 110 (Connection timed out)]
bd__ has joined #ocaml
bd_ has quit [Read error: 104 (Connection reset by peer)]
KrispyKringle has quit [Remote closed the connection]
Oejet has joined #ocaml
malc_ has quit [Read error: 110 (Connection timed out)]
Raziel has quit [Remote closed the connection]
Raziel has joined #ocaml
Raziel has quit [Remote closed the connection]
malc_ has joined #ocaml
zigong has quit ["using sirc version 2.211+KSIRC/1.3.11"]
Raziel has joined #ocaml
raziel_ has joined #ocaml
raziel_ has quit ["Yo soy goma. Tú eres cola."]
Raziel has quit ["Yo soy goma. Tú eres cola."]
Raziel has joined #ocaml
Schmurtz has quit [Connection timed out]
Submarine has quit [niven.freenode.net irc.freenode.net]
Submarine has joined #ocaml
juri has quit [niven.freenode.net irc.freenode.net]
ulfdoz_ has quit [niven.freenode.net irc.freenode.net]
Raziel has quit [niven.freenode.net irc.freenode.net]
malc_ has quit [niven.freenode.net irc.freenode.net]
bd__ has quit [niven.freenode.net irc.freenode.net]
Oejet has quit [niven.freenode.net irc.freenode.net]
pango has quit [niven.freenode.net irc.freenode.net]
vodka-goo has quit [niven.freenode.net irc.freenode.net]
Bigbang has quit [niven.freenode.net irc.freenode.net]
knobo_ has quit [niven.freenode.net irc.freenode.net]
mellum has quit [niven.freenode.net irc.freenode.net]
Maledict has quit [niven.freenode.net irc.freenode.net]
flux__ has quit [niven.freenode.net irc.freenode.net]
TaXules has quit [niven.freenode.net irc.freenode.net]
Hadaka has quit [niven.freenode.net irc.freenode.net]
lispy has quit [niven.freenode.net irc.freenode.net]
skylan has quit [niven.freenode.net irc.freenode.net]
Oatmeat|umn has quit [niven.freenode.net irc.freenode.net]
Skal has quit [niven.freenode.net irc.freenode.net]
noj has quit [niven.freenode.net irc.freenode.net]
Snark has quit [niven.freenode.net irc.freenode.net]
Smerdyakov has quit [niven.freenode.net irc.freenode.net]
Revision17 has quit [niven.freenode.net irc.freenode.net]
bluestorm has quit [niven.freenode.net irc.freenode.net]
gim has quit [niven.freenode.net irc.freenode.net]
ski__ has joined #ocaml
Raziel has joined #ocaml
malc_ has joined #ocaml
Oejet has joined #ocaml
Snark has joined #ocaml
Smerdyakov has joined #ocaml
Maledict has joined #ocaml
bd__ has joined #ocaml
Revision17 has joined #ocaml
Skal has joined #ocaml
bluestorm has joined #ocaml
pango has joined #ocaml
vodka-goo has joined #ocaml
Bigbang has joined #ocaml
knobo_ has joined #ocaml
mellum has joined #ocaml
ulfdoz_ has joined #ocaml
TaXules has joined #ocaml
gim has joined #ocaml
lispy has joined #ocaml
skylan has joined #ocaml
flux__ has joined #ocaml
juri has joined #ocaml
noj has joined #ocaml
Hadaka has joined #ocaml
Oatmeat|umn has joined #ocaml
juri has quit [niven.freenode.net irc.freenode.net]
ulfdoz_ has quit [niven.freenode.net irc.freenode.net]
pango has quit [niven.freenode.net irc.freenode.net]
malc_ has quit [niven.freenode.net irc.freenode.net]
bd__ has quit [niven.freenode.net irc.freenode.net]
mellum has quit [niven.freenode.net irc.freenode.net]
Oejet has quit [niven.freenode.net irc.freenode.net]
Bigbang has quit [niven.freenode.net irc.freenode.net]
knobo_ has quit [niven.freenode.net irc.freenode.net]
Raziel has quit [niven.freenode.net irc.freenode.net]
vodka-goo has quit [niven.freenode.net irc.freenode.net]
ski__ has quit [niven.freenode.net irc.freenode.net]
flux__ has quit [niven.freenode.net irc.freenode.net]
TaXules has quit [niven.freenode.net irc.freenode.net]
Hadaka has quit [niven.freenode.net irc.freenode.net]
Maledict has quit [niven.freenode.net irc.freenode.net]
lispy has quit [niven.freenode.net irc.freenode.net]
skylan has quit [niven.freenode.net irc.freenode.net]
Oatmeat|umn has quit [niven.freenode.net irc.freenode.net]
noj has quit [niven.freenode.net irc.freenode.net]
Skal has quit [niven.freenode.net irc.freenode.net]
ski__ has joined #ocaml
Raziel has joined #ocaml
malc_ has joined #ocaml
Oejet has joined #ocaml
Maledict has joined #ocaml
bd__ has joined #ocaml
Skal has joined #ocaml
pango has joined #ocaml
vodka-goo has joined #ocaml
Bigbang has joined #ocaml
knobo_ has joined #ocaml
mellum has joined #ocaml
ulfdoz_ has joined #ocaml
TaXules has joined #ocaml
lispy has joined #ocaml
skylan has joined #ocaml
flux__ has joined #ocaml
juri has joined #ocaml
Oatmeat|umn has joined #ocaml
Hadaka has joined #ocaml
noj has joined #ocaml
inkedmn has quit [Read error: 104 (Connection reset by peer)]
Oejet has left #ocaml []
inkedmn has joined #ocaml
ski_ has quit [Connection timed out]
Skal has quit [Remote closed the connection]
_JusSx_ has quit ["leaving"]
rg has joined #ocaml
_JusSx_ has joined #ocaml
Mitar has joined #ocaml
Mitar has left #ocaml []
Bigbang is now known as Bigb[a]ng
_JusSx_ has quit ["leaving"]
Snark has quit ["Leaving"]
__DL__ has joined #ocaml
shirogane has joined #ocaml
vodka-goo has left #ocaml []
__DL__ has quit ["Bye Bye"]
Smerdyakov has quit [Read error: 110 (Connection timed out)]
Smerdyakov has joined #ocaml
Mitar has joined #ocaml
Mitar has left #ocaml []
shirogane has quit [Remote closed the connection]
Submarine has quit ["Leaving"]
Skal has joined #ocaml
bzzbzz has joined #ocaml
ski__ is now known as ski_
<schlick>
I'd like opinions on a language design aspect... A routine can fail without it being reason to kill the program. It may also need to do more just call some routine to print a warning (in fact printing a warning may be totally inappropriate if failure is expected). Basically exception handling isn't always appropriate. Most of the time people use sentinel values, meaning unreasonable return values.
<mellum>
This being #ocaml, probably most people use exceptions.
<mellum>
Which seem like a reasonable mechanism for your scenario.
<ski_>
also, option
<schlick>
time people use sentinel values, meaning unreasonable return values. The problem is most programmers don't expect a "unreasonable" value. One option I've come up with is returning one of two types, one to indicate success that holds the value, and one to indicate error which holds details about why. Statically checking that both are handled somehow should be easier with a standard mechanism.
<schlick>
checking that both are handled somehow should be easier with a standard mechanism.
<pango>
you can only return one type, but values of different constructors (sum type)
<mellum>
So just WTF is wrong with using exceptions as everybody else dos?
<schlick>
Exceptions do one of two things. Print a warning, which doesn't help your program much, or zip off to some other point in the code that doesn't return (and thus makes cleanup hard) to run some other routine.
<mellum>
Uhm. I am not sure we are talking about the same thihng.
<mellum>
Exceptions as I know them don't do *anything(.
<schlick>
If you try to make a network connection, doing any of those is likely unreasonable.
<mellum>
But you can catch them and react appropriately.
<schlick>
You just want it to fail and make sure the programmer handles it.
<schlick>
I already explained how that's not a good solution. Exception handling amounts to goto. All the calls you made just had their guts ripped out and don't get to return, unless the handler knows how and the language allows that (usually based on continuations). This makes recovery a living nightmare. It also means you can't statically check that everything is handled.
<schlick>
If you just want to try to make a network connection, nothing "out of the ordinary" should happen, you just want to make sure there's a if statement (or something similar) that handles failure somewhere.
<mellum>
Well, the rest of the world seems to disagree with you; nearly every language introduced the last few years has an exception mechanism, and even very similar ones.
<mellum>
anyway, I'm going to bed now... bye
<schlick>
I'm aware. Most languages nowdays are dynamically typed, interpreted, and tend to make bad practices fairly easy (e.g. using exceptions for things that aren't exceptions... I'm still not really sure what a "exception" is anyway, since if it's handled, it's not a "exception" to any rules).
<pango>
schlick: if any intermediate level want to do some cleanup, it just has to add its own exception handler, do the cleanup there, and retrigger the exception
<schlick>
It doesn't mean I want mine to be that way. Not to mention exception handling doesn't help with static checking.
<schlick>
Only trying to cope at runtime.
<schlick>
pango: Yeah, I read about the Common Lisp "conditions" and SML error handling. Out of the two I think the SML way is better, but none are really appropriate for "expected failure" like trying network connections.
<schlick>
pango: Basically I want some standard mechanism I can type check.
<pango>
ocaml exceptions are type safe
<schlick>
pango: Not sure what that means. They're handled at runtime.
<pango>
since they're handled using pattern matching, you're always handling exceptions you know how to handle
<schlick>
pango: Which is fine I guess. Sometimes you have to. I'm more interested in making sure all failures are handled by the programmer.
<pango>
schlick: ocaml exceptions to nothing by default except rerouting program flow
<pango>
no printing, no nothing
<pango>
s/to nothing/do nothing/
<schlick>
pango: For instance if they try to connect to something, and connect can fail, can I check that they have code to handle that? And can I do it without resorting to goto (which isn't necessary if success then send stuff else if error do nothing end if).
smimou has quit ["bli"]
<pango>
btw, they're static exceptions checkers
<schlick>
pango: Obviously sometimes on error you'd want to do stuff.
<pango>
schlick: if you want to keep management local to current function, then just use exception handling within that function
<pango>
and if it's a retryable error, put the whole thing in a loop, or use a recursive call in the exception handling
<schlick>
I guess that'd be acceptable, at least if I found some way to force it to be local.
<schlick>
Basically I want it to be handled conditionally. I don't want goto at all.
<schlick>
Aside from not liking it, it causes optimization problems, and I'd have to build it into the bootstrapping compiler to get the higher level language off the ground.
<schlick>
Also screws up static checking in general.
malc_ has quit ["leaving"]
<schlick>
It seemed like with being able to use multiple types in the same location it would have made sense to just return a error type with information, or a success type with information.
<pango>
the point of exceptions is to move special cases out of the main path
<pango>
otherwise you can do fine without exception (sum types and pattern matching on results)
<schlick>
The compiler could keep whether it can return a error in linking information (akin to C headers) and make sure if it can fail, there's code to test/handle it in what calls it.
<schlick>
Moving things out of the main path is associated with numerous problems I don't want to get into. I'm perfectly happy not having the option to do so.
<schlick>
As far as sum types and pattern matching on results, maybe that's a alternative. I haven't seen that while searching.
<schlick>
Basically the compiler needs to be able to differentiate between "successful returned value" and "failed returned value". I'm just trying to figure out how to do that.
<schlick>
It's a sore spot with C (no standard mechanism), that a similar new language needs to fix.