btanksley | 1 Apr 01:13 2000

RE: Lists, Tables, Psets (Was: Joy, Dolphin, ...)

From: Kyle Lahnakoski [mailto:kyle <at> arcavia.com]

>I hope you do not mind I broadcast this reply to the list.

No problem; hopefully we can all be enlightened.

>btanksley <at> hifn.com wrote:

>> But in a sense, this is a problem native to every system; the calling
>> conventions which make sense to me now won't make any sense 
>> to me later, and
>> that's all there is to it.

>Solving the parameter naming problem is trivial:  Give every parameter
>an Id, have each programmer associate a name, of their liking, to each
>parameter ID.  The "idiot programmer" can choose a name, you can choose
>to change it for your application.  Therefore, when I say name I really
>mean ID.  ID and name are the same unless we talk of poor naming
>problems. 

I'll treat them as interchangable in the future, then.  This makes sense.

This is only one of many calling convention questions that your scheme
addresses, of course; I'll concede that it does address it, although I have
my doubts as to the magnitude of the problem.

>> >My questions are:
>> >What is the data structure used to store a call to the MyFunction?
>> >What is the data structure used to define the interface for 
>> >MyFunction?
(Continue reading)

btanksley | 1 Apr 01:29 2000

RE: Memory Management, Inlining, and POINTER

From: iepos <at> tunes.org [mailto:iepos <at> tunes.org]

>> >If one is popping things
>> >off, then why were they put there in the first place?

>> Um...  Who says they were put there?  You have a reference 
>> to a list; you
>> want to get the first thing in the list.  Now, that list 
>> still may exist
>> (someone else may have it); but now you have the first thing as in
>> independantly considerable item.

>This situation could happen, in a system that used references,
>but it seems like very poor style to me, to leave large lists on
>the stack (even if you really only leave a reference), when you know
>you are only going to use a small piece of the list. It seems like it
>would be wiser to arrange things such that instead of copying 
>a reference
>to the whole list earlier, one had just copied the small piece that
>one really needed a copy of.

But you really _are_ using the whole list, one item at a time.  This is a
pretty standard way to iterate over a linked list.  If you'd wanted just a
small piece of the list, you would have started with a reference to the
list, and use that reference to carve the small chunk you wanted.  No need
to copy the whole list just to let you carve off a tiny chunk of the copy!

>Another benefit is that if one only copies the small
>piece it may become reasonable to copy by value instead of by 
>reference.
(Continue reading)

Jason Marshall | 1 Apr 03:04 2000
Picon
Picon

Re: Intent

Recently, btanksley <at> hifn.com wrote:

> And who is this "everyone else" with whom you wish to associate
yourself and
> disassociate Brent?

Some days I wonder.

> >I feel the need to reiterate your comments on intent.  This
> >has been the foundation on which I have been trying to build a
> >language of my own. 'Metadata' sounds more flowery, but down
> >here in the trenches, 'intent', gets nods of comprehension much
> >earlier in the conversation, in my limited experience.
>
> Of course, you DO know that it's bull, right?  Just because you
personally
> don't understand the theory and practice of combinators doesn't mean
that
> combinators don't reveal intent.

What I 'know' is that other than Fare, I'm not picking up on any
meaningful
discussion of metadata going on in this list, which is the main reason
I don't participate more in the discussions.  I can see plenty of
evidence
of incidental or inferential metadata, but I can get that out of any
language, no matter how advanced, or how obtuse.  Talk of whiz-bang ways

of implementing yet-another-language-with-some-induction-logic is, while

(Continue reading)

iepos | 1 Apr 05:19 2000

Re: Intent

> What I 'know' is that other than Fare, I'm not picking up on any
> meaningful discussion of metadata going on in this list, which
> is the main reason I don't participate more in the discussions. 
> I can see plenty of evidence of incidental or inferential metadata,
> but I can get that out of any language, no matter how advanced, or
> how obtuse.  Talk of whiz-bang ways of implementing
> yet-another-language-with-some-induction-logic is, while interesting,
> old hat, and does nothing for readability before I've had my
> morning coffee, which is exactly when I'm going to botch the code.
> 
> No one talks of formalized metadata, which is what I am after, and what
> I thought/think Fare is after.  Why?

It is generally understood that my project, at least, is only
for a "TUNES--" ... Thus, I'm not now considering _all_ the
goals of TUNES. My main focus now has been to achieve efficient
storage management. 

But, you may say that reflection is quite an important feature, and
that it should not just be swept under the rug. The terminology
associated with reflection always seems to get very confusing,
but you might say that Joy _is_ reflective, in that programs
themselves can be pushed onto the stack and manipulated as
first-class citizens, and in fact this is quite a common
practice in Joy programs.

Anyhow, this is probably not the only kind of reflection you want...
However, I suspect that a Joy-like system would make a nice
base for a system that was reflective in other ways. One of the
author's goals was that Joy programs be easy to reason about by
(Continue reading)

Kyle Lahnakoski | 1 Apr 05:21 2000

[Fwd: Re: Intent (was: Re: Lists, Tables, Psets)]


Jason Marshall wrote:

> Not only is the code more readable by a human (set aside arguments that
> 25 wpm typists may not be able to cope with the verbosity, as these can
> be addressed by modelling tools and the like), but as you say, it's more
> 
> readable by the code optimizer in the system.  If you for instance
> declare
> that you intend to visit every item in a list or container, and perform
> an action on it, this is easier for the optimizer to sort out than if
> you
> write 50 different minor variations on an iterator idiom by hand, some
> with unintentional out of bounds bugs that you didn't bump into (yet).
> And it's easier for the compiler to parrallelize it on the target
> hardware if the facilities are available (MPP, vector math, etc).
> 
> Some of these issues can be handled at the language level, and some at
> the API level.  The important thing when designing is not to ask, 'how
> do I?' but 'Why do I?'.  Why do I create a file?  Because I want to
> keep some persistent information.  Why do I have locks?  To perform
> atomic operations on data that is seen by multiple threads of execution.
> 
> Why do I need explicit resource allocation/deallocation?  I dunno.
> Why do you?  Are the builtin facilities failing in some serious way?

You put it so well.  It has been what I was trying to say, but obviously
lack the skill to do so. 

> the programmer can just remember that detail", then you're definitely
(Continue reading)

btanksley | 1 Apr 06:09 2000

RE: Intent

From: Jason Marshall [mailto:jmarsh <at> serv.net]

>Recently, btanksley <at> hifn.com wrote:

>> And who is this "everyone else" with whom you wish to associate
>> yourself and disassociate Brent?

>Some days I wonder.

Me too.  You know, that would have been a lot cooler as a quote if I hadn't
spent most of the rest of my reply sounding like I had a terrible headache
and blamed you personally.  I didn't have a headache, so I don't have that
excuse; thank you for tolerating my uncouth abruptness.  I apologise, and
will attempt to do better.

>> >I feel the need to reiterate your comments on intent.  This
>> >has been the foundation on which I have been trying to build a
>> >language of my own. 'Metadata' sounds more flowery, but down
>> >here in the trenches, 'intent', gets nods of comprehension much
>> >earlier in the conversation, in my limited experience.

>> Just because you personally
>> don't understand the theory and practice of combinators doesn't mean
>> that combinators don't reveal intent.

>What I 'know' is that other than Fare, I'm not picking up on any
>meaningful
>discussion of metadata going on in this list, which is the main reason
>I don't participate more in the discussions.  I can see plenty of
>evidence
(Continue reading)

btanksley | 1 Apr 06:24 2000

RE: [Fwd: Re: Intent (was: Re: Lists, Tables, Psets)]

From: Kyle Lahnakoski [mailto:kyle <at> arcavia.com]

>Jason Marshall wrote:

>> Not only is the code more readable by a human
[huge snippage]

>You put it so well.  It has been what I was trying to say, but 
>obviously lack the skill to do so. 

I think I understood what you were saying; the problem is that it's just not
true that concatenative code is less readable or optimizable than
parameterized code.  The first statement in that long discussion, and the
assumed basis of the rest, is simply false.

I don't think it's true that concatenative languages are less capable of
using metadata, but I'm willing to discuss this; I haven't studied the issue
of metadata as well as you have.

>Kyle Lahnakoski                                  Arcavia Software Ltd.

-Billy

Jason Marshall | 1 Apr 12:35 2000
Picon
Picon

(unknown)

>> What I 'know' is that other than Fare, I'm not picking up on any
>> meaningful discussion of metadata going on in this list, which
>> is the main reason I don't participate more in the discussions. 
>> I can see plenty of evidence of incidental or inferential metadata,
>> but I can get that out of any language, no matter how advanced, or
>> how obtuse.  Talk of whiz-bang ways of implementing
>> yet-another-language-with-some-induction-logic is, while 
interesting,
>> old hat, and does nothing for readability before I've had my
>> morning coffee, which is exactly when I'm going to botch the code.
>> 
>> No one talks of formalized metadata, which is what I am after, and 
what
>> I thought/think Fare is after.  Why?
>
>It is generally understood that my project, at least, is only
>for a "TUNES--" ... Thus, I'm not now considering _all_ the
>goals of TUNES. My main focus now has been to achieve efficient
>storage management. 

My current focus is on a GC framework (rather than a one-size-fits-all
GC), and after the groundwork is in place, I'm going to attack the
problem from the top, down.  I figure for security, and certain size &
latency optimizations, that being able to prove something immutable
would be a fairly useful thing.  While the trivial case is fairly 
simple
(no mutators, and no shared data with mutators, recursively), some 
other cases where the sharing time extends only as far as the end
of the call, will be harder to construct proof systems for.  The 
difference between immutability and almost-immutability is a race
(Continue reading)

Kyle Lahnakoski | 1 Apr 17:53 2000

Database Theory Links


I was a very lucky guy!  Usually I find it impossible to find stuff on
the net.  Here are two links on DB theory.  The wealth of information in
the first one can bring anyone up to speed on db theory:

http://www.bus.orst.edu/faculty/brownc/LECTURES/DB_TUTOR/

The second one is a rare and elusive beast.  Fourth and fifth normal
forms are very hard to find in any detail.

Graphics:
http://www.umuc.edu/~tkorjack/chpt11date/sld001.htm

Text:
http://www.umuc.edu/~tkorjack/chpt11date/tsld001.htm

--

-- 
----------------------------------------------------------------------
Kyle Lahnakoski                                  Arcavia Software Ltd.
(416) 892-7784                                 http://www.arcavia.com

Jason Marshall | 1 Apr 19:15 2000
Picon
Picon

Re: Intent

>
>From: Jason Marshall [mailto:jmarsh <at> serv.net]
>
>> Recently, btanksley <at> hifn.com wrote:
>>Talk of 
>>whiz-bang ways of implementing yet-another-language-with-some-
>>induction-logic is, while interesting, old hat, and does nothing for
>>readability before I've had my morning coffee, which is exactly when 
>>I'm going to botch the code.
>
>Grin.  I certainly understand that.

Here's where things get trickier.  There's a severe shortage of 
programmers
in the good-great category.  We're short on architects (me), and we're 
way
short on artists (also probably me), and so far, software engineering 
has been
an artform, no matter what people try to tell you.  It's really no 
different than
architectural engineering.  You want something to stand up, sure, but 
you
want it to be functionally elegant, and to not fight you all the time. 
I can't
honestly say I'd like that state of affairs to change, but then, the 
'system'
works well for me already. 

Anyway, that wasn't where I was heading with that.  Where was I?  Ah, 
yes.
(Continue reading)


Gmane