headers
Brian T Rice | 5 May 2003 02:45
Favicon

Re: Term "Configuration"

Sorry for the time to reply. I spent some time thinking the situation
over before I developed a refined statement of the definition.

On Wed, 30 Apr 2003, Mario Blazevic wrote:

> Take your term "configuration", for example: "some collection of objects
> and relationships which hold over them" is a good start, but it doesn't
> say if the relationships are a property of the configuration or of the
> objects. To put it in a half-formal way, can you express a configuration
> as a pair C = (O: set of objects, R: set of relationships)? If you take
> the first component O of the pair, the set of objects, can you derive R
> from O without the configuration C?

I deliberately avoided stating "property"ship... TUNES is deliberately
abstract about core and derived ideas, and saying that "a is a property of
b" in a specification for it is overly-restrictive.

The closest analogue of "property"ship in the TUNES lexicon is
attribution, which is deliberately divorced from an ontology specifying
centrality of certain objects over others.

As far as the (O,R) formalization, I think this is decent, but needs
restating. It looks too much like "object-relational" however, which is
/not/ what is intended in the slightest. Really, you could formalize it
as:

_Configuration_: a set of objects and meta-objects which is closed over
the operation of accessing the subject matter of any meta-objects in the
set.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Armin Rigo | 5 May 2003 13:25
Favicon

Re: Term "Configuration"

Hello Brian,

On Tue, Apr 29, 2003 at 05:53:17PM -0700, Brian T Rice wrote:
> >From wordnet, I get the synonyms "constellation" and "structure", both of
> which aren't properly suggestive.

I like the term "constellation". I think it is clearer than "configuration".  
Avoiding the use of terms with a strong existing meaning (however biased it
may be) always seem like a good idea to me.

A bientôt,

Armin.
Permalink | Reply | 1 comment |
headers
Brian T Rice | 6 May 2003 11:58
Favicon

Re: Term "Configuration"

On Mon, 5 May 2003, Armin Rigo wrote:
> On Tue, Apr 29, 2003 at 05:53:17PM -0700, Brian T Rice wrote:
> > >From wordnet, I get the synonyms "constellation" and "structure", both of
> > which aren't properly suggestive.
>
> I like the term "constellation". I think it is clearer than "configuration".
> Avoiding the use of terms with a strong existing meaning (however biased it
> may be) always seem like a good idea to me.

This "good idea" is involved with any term we choose, and I'd rather pick
something that generalizes a concept that even the common user knows than
to talk of "constellations". We already have our own special vocabulary
for words like "attribute" and "object" which are heavily weighed by
tradition and hype already, and I think there's a good effect in forcibly
re-negociating the terms into what they ought to be.

But basically, I don't see how "constellation" is any more clear for any
reason other than pure figurativeness, and even then it's just poetic.
It's not that I dislike the poetic, or don't see its value here, but it
suggests location and perspective when we're talking about stellar
constellations, which just seems to be invoking too many metaphors at
once. I'd rather generalize one idea that people know than draw in a
couple of metaphors that people never think about.

--

-- 
Brian T. Rice
LOGOS Research and Development
http://tunes.org/~water/
(Continue reading)

Permalink | Reply | 0 comments |
headers
Brian T Rice | 7 May 2003 06:29
Favicon

New morphism glossary entry

I've added the term "morphism" to enhance our explanation for the
relevance of category theory and algebraic design in TUNES. See:

http://cliki.tunes.org/Morphism

I've also added a node explaining induction vs. co-induction to assist in
understanding, and modified the 101-course for category theory to point
out the name "morphism".

I'm not looking for ridiculously-rigorous definitions, since those can be
had on many other web sites and research papers, but instead to explain
the relevance in particular to what we're developing.

I'm also noticing that we will need to make use of these concepts soon to
get past where we are now with the site, prototypes, and specification.

Any thoughts? Category theory experts are welcome to assist in editing. I
may ask a patron or two from Lambda the Ultimate to help out as well.

--

-- 
Brian T. Rice
LOGOS Research and Development
http://tunes.org/~water/
Permalink | Reply | 0 comments |
headers
Marc Santoro | 12 May 2003 05:02
Favicon

Learning Lounge

After a bit of discussion with Brian Rice today on IRC, I spent some 
time examining the Learning Lounge.

I wrote a rough draft of the direction I would like to see the LL take. 
To summarize, I think it should be rebuilt, with a wider scope of 
indoctrination.

http://cliki.tunes.org/Learning%20Lounge%20Rebuilding

As stated, it's a draft, so it's probably chock full of errors.

Obviously, an appropriate approach at this point in time is to create 
the project separately  from the LL, with the end goal of replacing the 
LL, perhaps in a year or two.

What do you think?
Permalink | Reply | 7 comments |
headers
James Michael DuPont | 12 May 2003 10:19
Picon
Favicon

Re: Learning Lounge

I agree with your idea of lowering the learning curve.

There is a project that I have been nurturing, www.fsedu.org that also
aims to provide an online free learning environment. 

One of the courses planned is scheme, I think that using some of the
tunes learning tasks as part of the curricula would be good.

mike

--- Marc Santoro <ultima <at> tunes.org> wrote:
> After a bit of discussion with Brian Rice today on IRC, I spent some 
> time examining the Learning Lounge.
> 
> I wrote a rough draft of the direction I would like to see the LL
> take. 
> To summarize, I think it should be rebuilt, with a wider scope of 
> indoctrination.
> 
> http://cliki.tunes.org/Learning%20Lounge%20Rebuilding
> 
> As stated, it's a draft, so it's probably chock full of errors.
> 
> Obviously, an appropriate approach at this point in time is to create
> 
> the project separately  from the LL, with the end goal of replacing
> the 
> LL, perhaps in a year or two.
> 
> What do you think?
(Continue reading)

Permalink | Reply | 0 comments |
headers
Pietro Braione | 15 May 2003 12:18
Picon

[OT] [Fwd: (SEWORLD) CfP: REPLS '03]

Hope that the messages I forward sometimes
on conferences, meetings, etc. do not
annoy people. If it is the case, tell me.

Pietro

-------- Original Message --------
Subject: (SEWORLD) CfP: REPLS '03
Date: Wed, 14 May 2003 12:12:34 -0600 (MDT)
From: Pascal Costanza <costanza <at> iai.uni-bonn.de>
To: SEWORLD <at> serl.cs.colorado.edu

                    C A L L   F O R   P A P E R S
                    =============================

                             Workshop on
     Reflectively Extensible Programming Languages and Sytems (REPLS)

                                  at
         The International Conference on Generative Programming
                  and Component Engineering (GPCE'03)

                           September 22, 2003
                            Erfurt, Germany

                  http://prog.vub.ac.be/gpce-repls/

------------------------------------------------------------------------
   ---
IMPORTANT DATES
(Continue reading)

Permalink | Reply | 0 comments |
headers
PB | 15 May 2003 14:39
Picon
Favicon

Re: Learning Lounge

Marc Santoro wrote:
> After a bit of discussion with Brian Rice today on IRC, I spent some 
> time examining the Learning Lounge.
> 

I've reckoning for some time about the Learning Lounge.
I agree that it should be reorganized.
I also agree that the learning curve should be lowered.
I do not completely agree on your proposal, for some
reasons. I'm sorry if I will be somehow blunt in some
of my statements.

1- Ok, we do not want to grow a generation of categorists
or of gurus in linear logic. But I think that completely
removing the foundational topics is a mistake. Rather,
one should detect which foundational topics are compulsory
and which are not, at least to create a common vocabulary
of terms and concepts.

2- I do not see an overall organization in your proposed
path. It appears as a huge course on programming languages
concepts, with some external unrelated topics. I would first
detect the core areas in TUNES, and then organize the courses.
I propose a (tentative) alternative organization of topics,
each with a chaotic list of stuff that can be put inside:

   a- Programming languages concepts:
       - functional and logic languages: Lisp/Scheme, Haskell,
         laziness, (co)induction; Prolog, Curry?
       - objects and classes: Squeak, CLOS
(Continue reading)

Permalink | Reply | 5 comments |
headers
Marc Santoro | 16 May 2003 03:12
Favicon

Re: Learning Lounge

I agree with you a great deal; the first 5-6 topics you described in
detail included, essentially, the reasons I would choose to teach CL and
Squeak.  I think that many of those subtopics would be good
learning projects/topics involving a course on learning a language.

I also do not want to "remove" the fundamental topics -- but I would like
to see the definition of fundamental topics change to include (and perhaps
be centered around) topics that must be understood before the more
advanced topics can be learned.

The pattern I envisioned is based on the topics and skills I would like a
person to have, placed into a development-oriented framework. I want
people writing code! I want people sharing.

I think also that you are starting too quickly; I would like to introduce
a single language (Squeak), which would allow for the development of
understanding of many important core concepts. Once these concepts are
understood, the process of learning different languages should be
expedited greatly. While Squeak is not the best platform (nor is CL) for
each of Tunes' core concepts, I think that a solidly grounded
understanding of one or two languages is much more important at the
beginning than a weak grasp of many languages (in the first topic you
mention 12.9 -- do you really expect a newbie to be able to tackle that? I
would not dare to give more than 1, unless they are already
well-experienced with stuff that is non-traditional or
non-systems-programming) -- particularly when the only concepts in a
language the student is forced to learn are the concepts specifically
related to Tunes.

Thanks,
(Continue reading)

Permalink | Reply | 4 comments |
headers
PB | 16 May 2003 12:30
Picon
Favicon

Re: Learning Lounge

Marc Santoro wrote:
> I agree with you a great deal; the first 5-6 topics you described in
> detail included, essentially, the reasons I would choose to teach CL and
> Squeak.  I think that many of those subtopics would be good
> learning projects/topics involving a course on learning a language.
> 
> I also do not want to "remove" the fundamental topics -- but I would like
> to see the definition of fundamental topics change to include (and perhaps
> be centered around) topics that must be understood before the more
> advanced topics can be learned.

Let's say "foundational" rather than "fundamental".
You're right when you say that one can get along
and program without the foundations, so they're
not really fundamental for everyone.

> 
> The pattern I envisioned is based on the topics and skills I would like a
> person to have, placed into a development-oriented framework. I want
> people writing code! I want people sharing.
> 

100% agree.

> I think also that you are starting too quickly; I would like to introduce
> a single language (Squeak), which would allow for the development of
> understanding of many important core concepts. Once these concepts are
> understood, the process of learning different languages should be
> expedited greatly. While Squeak is not the best platform (nor is CL) for
> each of Tunes' core concepts, I think that a solidly grounded
(Continue reading)

Permalink | Reply | 3 comments |

Gmane