On 22/06/2009, at 1:15 AM, john skaller wrote:
> I have solved this problem as follows, the commit got stuffed up
> because I
> still haven't figured out how to get git to re-download files when i
> mess up.
> So I've lost the changes and will have to do them again. The solution
> is basically to
I have solved this problem as follows, the commit got stuffed up
because I
still haven't figured out how to get git to re-download files when i
mess up.
So I've lost the changes and will have to do them again. The solution
is basically to add a new combinator
`BEXPR_address e
which ta
On 19/06/2009, at 5:00 PM, john skaller wrote:
>
> On 19/06/2009, at 4:24 PM, Erick Tryzelaar wrote:
>
>>> There is a language (forget the name, something C like) which
>>> specialises in pointer "kinds".
>>
>>
>> I believe you're thinking about D
>
> no, its an academic language specialising in
On 19/06/2009, at 4:24 PM, Erick Tryzelaar wrote:
>> There is a language (forget the name, something C like) which
>> specialises in pointer "kinds".
>
>
> I believe you're thinking about D
no, its an academic language specialising in pointer kinds.
Cyclone I believe.
> Yech, that's ugly :) I'm
On 19/06/2009, at 4:15 PM, Erick Tryzelaar wrote:
>>
>> This is already an error, just not a type error.
>
> Oh? It works for me:
>
> val x = 1,2,3;
> println x;
> x.[0] = 0;
As mentioned before, this is just because assignments are hacked.
They're type checked, nothing else. Try this:
On Thu, Jun 18, 2009 at 10:38 PM, john
skaller wrote:
>
> "const" is the wrong idea though. It may help, but it isn't the
> same as
>
> int immutable x = 1;
> int immutable *px = &x;
>
> With "const" a function promises not to modify the pointed
> at value. This helps the caller make
On Thu, Jun 18, 2009 at 10:38 PM, john
skaller wrote:
>
>> One way we could limit this a little bit is to make value arrays
>> immutable, where these would be type errors:
>>
>> # val x = 1,2,3;
>> # x.[0] = 5; <- type error
>> # proc foo[N] (x:array[int,N]) { x.[0] = 5; } <- type error
>>
>
> This
On 19/06/2009, at 2:40 PM, Erick Tryzelaar wrote:
> But there's no way to say "it's a type error to modify this array"
> like C/C++ does. So, is this something we'd want? I personally think
> something like this would be useful, and I'd bet it'd help with
> optimization. We'd probably want someth
On Thu, Jun 18, 2009 at 3:28 PM, john
skaller wrote:
>
> still not sure what to do about this. This cannot work now:
>
> x.[i] += 1;
>
> where x is a C-array, because the subscript function cannot return
> an lvalue (since they don't exist). It could return a pointer, and we could
> make it
On 07/04/2009, at 10:35 AM, Raoul Duke wrote:
> hi,
>
>>> [1]: http://www.bitc-lang.org/docs/bitc/bitc-origins.html
>> Quite an interesting paper .. pity they didn't know about Felix.
>
> uh... googling a second would tell you otherwise :-)
>
> http://www.coyotos.org/pipermail/bitc-dev/2007-June/
hi,
>> [1]: http://www.bitc-lang.org/docs/bitc/bitc-origins.html
> Quite an interesting paper .. pity they didn't know about Felix.
uh... googling a second would tell you otherwise :-)
http://www.coyotos.org/pipermail/bitc-dev/2007-June/000920.html
note that BitC is closing down as Dr. Shapiro
On 06/04/2009, at 5:54 PM, Erick Tryzelaar wrote:
>
> [1]: http://www.bitc-lang.org/docs/bitc/bitc-origins.html
Quite an interesting paper .. pity they didn't know about Felix.
Typeclasses with semantics which talk to theorem provers!
Ok, the formulae are weak (only universal quantification at
On 06/04/2009, at 5:54 PM, Erick Tryzelaar wrote:
>
>
> Those annotations, those are essentially effect types, right?
Dunno what they are although the name is suggestive ..
> I remember I read a paper a couple months ago from the BitC folks
> that talk about implementing their effect system [
On Apr 6, 2009, at 12:09 AM, john skaller wrote:
>
> On 06/04/2009, at 4:33 PM, Erick Tryzelaar wrote:
>
>>>
>>> The question is what 'x' means given
>>>
>>> var x = 1;
>>
>>
>> To play the devils advocate, do we even need lvalues? I can live
>> without pre and post incrementing.
>
>
> What a
On 06/04/2009, at 4:33 PM, Erick Tryzelaar wrote:
>>
>> The question is what 'x' means given
>>
>> var x = 1;
>
>
> To play the devils advocate, do we even need lvalues? I can live
> without pre and post incrementing.
What about assignment? If you can't get the address of a variable
you ca
On Apr 5, 2009, at 9:34 PM, john skaller wrote:
> At this point some choices need to be made about lvalue stuff. In
> principle
> the idea is:
>
> a) a var is actually a pointer
> b) mutation including assignment requires a pointer
> c) offset can be added to pointers to support mutation of sub
On Sat, 2007-12-01 at 18:09 -0800, Erick Tryzelaar wrote:
> On Dec 1, 2007 5:00 PM, skaller <[EMAIL PROTECTED]> wrote:
> > Clearly
> >
> > x + 1
> >
> > is ambiguous .. incrementing the pointer? or the value it points to?
>
> What if we made incrementing the pointer a separate felix funct
On Dec 1, 2007 11:32 PM, skaller <[EMAIL PROTECTED]> wrote:
> We could certainly POST PROCESS the result of substituting the $1
> out by the argument .. however this is very hard because it
> needs parsing of C/C++ text, which is very hard, and impossible
> without a table of which names are types.
On Sat, 2007-12-01 at 18:09 -0800, Erick Tryzelaar wrote:
> On Dec 1, 2007 5:00 PM, skaller <[EMAIL PROTECTED]> wrote:
> > Clearly
> >
> > x + 1
> >
> > is ambiguous .. incrementing the pointer? or the value it points to?
>
> What if we made incrementing the pointer a separate felix funct
On Dec 1, 2007 5:00 PM, skaller <[EMAIL PROTECTED]> wrote:
> Clearly
>
> x + 1
>
> is ambiguous .. incrementing the pointer? or the value it points to?
What if we made incrementing the pointer a separate felix function?
It'd be clearer, and I doubt it'd be needed much.
> which means all
20 matches
Mail list logo
