I am a student in 5th year (out of 5) and i need a diploma project
idea.
Topics i am interested in and want to study:
- LISP
- macros
- MOP
- meta-models
- Language oriented programming (or derived work)
- AOP
- others...
Any ideas (and details) are welcomed.
Thanks!
Adrian DOZSA wrote:
> I am a student in 5th year (out of 5) and i need a diploma project
> idea.
>
> Topics i am interested in and want to study:
> - LISP
> - macros
> - MOP
> - meta-models
> - Language oriented programming (or derived work)
> - AOP
> - others...
>
> Any ideas (and details) are welcomed.
> Thanks!
>
Point of information: does the above mean you do not yet know all those
things? Or do you mean you know them (a little anyway) and want to
/apply/ them in a diploma project?
Second POI: What kinds of things would you like to see a computer do?
ken
--
Well, I've wrestled with reality for 35 years, Doctor, and
I'm happy to state I finally won out over it.
-- Elwood P. Dowd
In this world, you must be oh so smart or oh so pleasant.
-- Elwood's Mom
On Feb 26, 2:01 am, Ken Tilton <·········@gmail.com> wrote:
>
> Point of information: does the above mean you do not yet know all those
> things? Or do you mean you know them (a little anyway) and want to
> /apply/ them in a diploma project?
>
Yes that means i know ("a little anyway") all those things i wrote.
>
> Second POI: What kinds of things would you like to see a computer do?
>
I have to mention that i don't really want a practical project (a
program to do something) and i would like more a research kind of
topic, if you understand. I think i should have wrote "diploma thesis"
instead.
Adrian DOZSA wrote:
> On Feb 26, 2:01 am, Ken Tilton <·········@gmail.com> wrote:
>
>>Point of information: does the above mean you do not yet know all those
>>things? Or do you mean you know them (a little anyway) and want to
>>/apply/ them in a diploma project?
>>
>
>
> Yes that means i know ("a little anyway") all those things i wrote.
>
>
>>Second POI: What kinds of things would you like to see a computer do?
>>
>
>
> I have to mention that i don't really want a practical project (a
> program to do something)
Well then you certainly came to the right newsgroup.
> and i would like more a research kind of
> topic, if you understand. I think i should have wrote "diploma thesis"
> instead.
>
Gotcha. Btw, too bad you snipped the vital ten-line original, I had to
go back and get it:
> Topics i am interested in and want to study:
> - LISP
> - macros
> - MOP
> - meta-models
> - Language oriented programming (or derived work)
> - AOP
> - others...
>
> Any ideas (and details) are welcomed.
What is language oriented programming? Do you mean /natural language/?
Needless to say (because of my Cells project) I think the most
interesting thing going on in language research these days is the
dataflow paradigm, with functional reactive programming being the single
most active academic label hung on this very old idea. Here is the prior
art section of cells-manifesto.txt:
Prior Art (in increasing order of priorness (age))
---------
Functional reactive programming:
This looks to be the most active, current, and vibrant subset of
folks working on this sort of stuff.
Links:
FlapJax (FRP-powered web apps) http://www.flapjax-lang.org/
http://lambda-the-ultimate.org/node/1771
http://www.haskell.org/frp/
FrTime (scheme FRP implementation, no great links)
http://pre.plt-scheme.org/plt/collects/frtime/doc.txt
Adobe Adam, originally developed only to manage complex GUIs. [Adam]
COSI, a class-based Cells-alike used at STSCI to in software used to
schedule Hubble telescope viewing time. [COSI]
Garnet's KR: http://www.cs.cmu.edu/~garnet/
Also written in Lisp. Cells looks much like KR, though Cells was
developed in ignorance of KR (or any other prior art). KR has
an astonishing number of backdoors to its constraint
engine, none of which have turned out to be necessary for Cells.
The entire constraint programming field, beginning I guess with Guy Steele's
PhD Thesis in which he develops a constraint programming language or two:
http://portal.acm.org/citation.cfm?id=889490&dl=ACM&coll=ACM
http://www.cs.utk.edu/~bvz/quickplan.html
Sutherland, I. Sketchpad: A Man Machine Graphical Communication System.
PhD thesis, MIT, 1963.
Steele himself cites Sketchpad as inexlicably unappreciated prior
art to his Constraints system:
See also:
The spreadsheet paradigm:
http://www.cs.utk.edu/~bvz/active-value-spreadsheet.html
The dataflow paradigm: http://en.wikipedia.org/wiki/Dataflow
Frame-based programming
Definitive-programming
Read the whole thing for a lengthy synopsis of the big picture and my
open-source Cells project:
http://common-lisp.net/cgi-bin/viewcvs.cgi/cells/cells-manifesto.txt?root=cells&view=markup
kt
--
Well, I've wrestled with reality for 35 years, Doctor, and
I'm happy to state I finally won out over it.
-- Elwood P. Dowd
In this world, you must be oh so smart or oh so pleasant.
-- Elwood's Mom
On Feb 26, 12:57 pm, Ken Tilton <·········@gmail.com> wrote:
>
> What is language oriented programming? Do you mean /natural language/?
>
Language oriented programming is a style of programming in which,
rather than solving problems in general-purpose programming languages,
the programmer creates one or more domain-specific programming
languages for the problem first and solves the problem in those
languages.
Additional links:
Language Oriented Programming: The Next Programming Paradigm
by Sergey Dmitriev, CEO of JetBrains
http://www.onboard.jetbrains.com/is1/articles/04/10/lop/mps.pdf
Language Workbenches: The Killer-App for Domain Specific Languages?
by Martin Fowler
http://www.martinfowler.com/articles/languageWorkbench.html
The Death Of Computer Languages, The Birth of Intentional Programming
by Charles Simonyi, ex-Microsoft
ftp://ftp.research.microsoft.com/pub/tr/tr-95-52.doc
Adrian DOZSA wrote:
> On Feb 26, 12:57 pm, Ken Tilton <·········@gmail.com> wrote:
>
>>What is language oriented programming? Do you mean /natural language/?
>>
>
>
> Language oriented programming is a style of programming in which,
> rather than solving problems in general-purpose programming languages,
> the programmer creates one or more domain-specific programming
> languages for the problem first and solves the problem in those
> languages.
>
> Additional links:
>
> Language Oriented Programming: The Next Programming Paradigm
> by Sergey Dmitriev, CEO of JetBrains
> http://www.onboard.jetbrains.com/is1/articles/04/10/lop/mps.pdf
"I have begun development of a universal platform (the
Meta Programming System) for designing domainspecific
languages along with their supporting tools and
environments. It will allow programmers to define
languages as easily as they can write programs today.
The platform will fully support LOP, giving programmers
the freedom to use the most suitable language for each
part of their programs,..."
Someone needs to write a snappy "rule" for this sort of thing.
Yeah, I had heard of "intentional programming". This is just too funny.
The paper offers nothing higher level than a "Collection DSL". Good
lord, this is where we began with OO. Hey, look at my shapes class! So
expect the same result: whenever anyone goes to write a program
superfast, they will never find a DSL (nor an OO hierarchy) that is Just
Right, so:
"If there are no appropriate DSLs for your problem, then
you create ones that fit your problem."
Great! Ooops! I need to create an editor, too! Why?
"The problem is that text editors are stupid and don�t
know how to work with the underlying graph structure
of programs."
PWUAUHAHAHAHAHAHAA. The man knows nothing of Lisp.
"As features are added
to the language, it becomes increasingly difficult to add
new extensions without making the language ambiguous.
We would need to invent more types of brackets,
operators, keywords, rules of ordering, nesting, etc.
Language designers spend enormous amounts of time
thinking about text syntax and trying to find new ways
to extend it.
If we are going to make creating languages easy, we
need to separate the representation and storage of the
program from the program itself."
Is someone solving the wrong problem? Well, I think he is planning on
selling his solution:
"We need some sort of editor for our
languages. But we don�t want a generic editor; experience
has shown that generic editors aren�t as usable as we
want them to be. We want writing models to be fast, so
we want specialized editors tailored to our language
concepts."
And we then learn he is working on a generic graphical programming
environment for building DSLs. Move over, Emacs!
Anyway, if your professor is a big LOP fan then you could get in big
trouble by turning in a one sentence paper: "LOP reinvents Lisp." Hmmm,
maybe you could back it up with a Collection DSL. Ooops, that reinvents
LOOP. Hey, how about "Lisp as a prototyping environment for DSLs". You
could do it this way: "Of course no one would really want to program in
Lisp, but for quick prototyping of DSLs the orderly syntax makes text a
viable editing front-end and destructuring-bind means we get to skip the
parser, too, allowing us to focus on semantics yadda yadda yadda..." ie,
You do not have to rub it in their noses.
LOP is the single most common mistake in language evolution: taking a
good idea and making it into its own language or process. One thing
encouraging that is that you just can't do truly new things (in all but
one language) /without/ making a new language. But with Lisp you do not
stop to make a DSL, you just create a macro here and a macro there and
keep on programming. A DSL emerges from the process when lazy
programmers tire of writing/maintaining boilerplate.
Well, that's my view from the cheap seats anyway.
kzo
--
Well, I've wrestled with reality for 35 years, Doctor, and
I'm happy to state I finally won out over it.
-- Elwood P. Dowd
In this world, you must be oh so smart or oh so pleasant.
-- Elwood's Mom
On Feb 26, 7:56 pm, Ken Tilton <·········@gmail.com> wrote:
> Adrian DOZSA wrote:
> > On Feb 26, 12:57 pm, Ken Tilton <·········@gmail.com> wrote:
>
> >>What is language oriented programming? Do you mean /natural language/?
>
> > Language oriented programming is a style of programming in which,
> > rather than solving problems in general-purpose programming languages,
> > the programmer creates one or more domain-specific programming
> > languages for the problem first and solves the problem in those
> > languages.
>
> > Additional links:
>
> > Language Oriented Programming: The Next Programming Paradigm
> > by Sergey Dmitriev, CEO of JetBrains
> >http://www.onboard.jetbrains.com/is1/articles/04/10/lop/mps.pdf
>
> "I have begun development of a universal platform (the
> Meta Programming System) for designing domainspecific
> languages along with their supporting tools and
> environments. It will allow programmers to define
> languages as easily as they can write programs today.
> The platform will fully support LOP, giving programmers
> the freedom to use the most suitable language for each
> part of their programs,..."
>
> Someone needs to write a snappy "rule" for this sort of thing.
>
> Yeah, I had heard of "intentional programming". This is just too funny.
> The paper offers nothing higher level than a "Collection DSL". Good
> lord, this is where we began with OO. Hey, look at my shapes class! So
> expect the same result: whenever anyone goes to write a program
> superfast, they will never find a DSL (nor an OO hierarchy) that is Just
> Right, so:
>
> "If there are no appropriate DSLs for your problem, then
> you create ones that fit your problem."
>
> Great! Ooops! I need to create an editor, too! Why?
>
> "The problem is that text editors are stupid and don't
> know how to work with the underlying graph structure
> of programs."
>
> PWUAUHAHAHAHAHAHAA. The man knows nothing of Lisp.
>
> "As features are added
> to the language, it becomes increasingly difficult to add
> new extensions without making the language ambiguous.
> We would need to invent more types of brackets,
> operators, keywords, rules of ordering, nesting, etc.
> Language designers spend enormous amounts of time
> thinking about text syntax and trying to find new ways
> to extend it.
> If we are going to make creating languages easy, we
> need to separate the representation and storage of the
> program from the program itself."
>
> Is someone solving the wrong problem? Well, I think he is planning on
> selling his solution:
>
> "We need some sort of editor for our
> languages. But we don't want a generic editor; experience
> has shown that generic editors aren't as usable as we
> want them to be. We want writing models to be fast, so
> we want specialized editors tailored to our language
> concepts."
>
> And we then learn he is working on a generic graphical programming
> environment for building DSLs. Move over, Emacs!
>
> Anyway, if your professor is a big LOP fan then you could get in big
> trouble by turning in a one sentence paper: "LOP reinvents Lisp." Hmmm,
> maybe you could back it up with a Collection DSL. Ooops, that reinvents
> LOOP. Hey, how about "Lisp as a prototyping environment for DSLs". You
> could do it this way: "Of course no one would really want to program in
> Lisp, but for quick prototyping of DSLs the orderly syntax makes text a
> viable editing front-end and destructuring-bind means we get to skip the
> parser, too, allowing us to focus on semantics yadda yadda yadda..." ie,
> You do not have to rub it in their noses.
>
> LOP is the single most common mistake in language evolution: taking a
> good idea and making it into its own language or process. One thing
> encouraging that is that you just can't do truly new things (in all but
> one language) /without/ making a new language. But with Lisp you do not
> stop to make a DSL, you just create a macro here and a macro there and
> keep on programming. A DSL emerges from the process when lazy
> programmers tire of writing/maintaining boilerplate.
>
> Well, that's my view from the cheap seats anyway.
>
> kzo
>
> --
> Well, I've wrestled with reality for 35 years, Doctor, and
> I'm happy to state I finally won out over it.
> -- Elwood P. Dowd
>
> In this world, you must be oh so smart or oh so pleasant.
> -- Elwood's Mom
I totally agree with you. On every forum/newsgroup lispers share the
same point. But don't be so hush, they are only trying to simulate the
power of Lisp macros on a different platform/language and create a
process of developing a custom made language. Overall it's a good
thing because they finally realize that Abelson and Sussman's
"stratified design" (from SICP) or the more recent language embedded
DSLs are the way to do complex software.
This ("Lisp as a prototyping environment for DSLs") would be a nice
idea, but it's nothing new; it's only a "i told you so" paper.
Adrian DOZSA wrote:
> I totally agree with you. On every forum/newsgroup lispers share the
> same point. But don't be so hush, they are only trying to simulate the
> power of Lisp macros on a different platform/language and create a
> process of developing a custom made language.
Maybe I'm wrong, but on page 9 of the PDF it looks like something like a
simple text replacement template system. It is not even close to the power
of Lisp macros, which is so powerful, because the Lisp syntax is simple and
Lisp code is executed to expand Lisp macros. Maybe you can define the code,
which is executed when the template is expanded, but I don't think that you
can use templates for writing the code, which is executed when expanding
the templates. In Lisp you this is possible and useful, e.g. when using the
LOOP macro inside another macro.
If your thesis is about DSL, don't forget to mention Forth when you explain
and compare existing solutions. The syntax of Forth is even simpler than
Lisp: There are only words and numbers, separated by whitespace. But a very
powerful concept is that when a word is executed, it can read the program
source input stream.
--
Frank Buss, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Adrian DOZSA wrote:
> On Feb 26, 7:56 pm, Ken Tilton <·········@gmail.com> wrote:
>
>>Adrian DOZSA wrote:
>>
>>>On Feb 26, 12:57 pm, Ken Tilton <·········@gmail.com> wrote:
>>
>>>>What is language oriented programming? Do you mean /natural language/?
>>
>>>Language oriented programming is a style of programming in which,
>>>rather than solving problems in general-purpose programming languages,
>>>the programmer creates one or more domain-specific programming
>>>languages for the problem first and solves the problem in those
>>>languages.
>>
>>>Additional links:
>>
>>>Language Oriented Programming: The Next Programming Paradigm
>>>by Sergey Dmitriev, CEO of JetBrains
>>>http://www.onboard.jetbrains.com/is1/articles/04/10/lop/mps.pdf
>>
>>"I have begun development of a universal platform (the
>>Meta Programming System) for designing domainspecific
>>languages along with their supporting tools and
>>environments. It will allow programmers to define
>>languages as easily as they can write programs today.
>>The platform will fully support LOP, giving programmers
>>the freedom to use the most suitable language for each
>>part of their programs,..."
>>
>>Someone needs to write a snappy "rule" for this sort of thing.
>>
>>Yeah, I had heard of "intentional programming". This is just too funny.
>>The paper offers nothing higher level than a "Collection DSL". Good
>>lord, this is where we began with OO. Hey, look at my shapes class! So
>>expect the same result: whenever anyone goes to write a program
>>superfast, they will never find a DSL (nor an OO hierarchy) that is Just
>>Right, so:
>>
>>"If there are no appropriate DSLs for your problem, then
>>you create ones that fit your problem."
>>
>>Great! Ooops! I need to create an editor, too! Why?
>>
>>"The problem is that text editors are stupid and don't
>>know how to work with the underlying graph structure
>>of programs."
>>
>>PWUAUHAHAHAHAHAHAA. The man knows nothing of Lisp.
>>
>>"As features are added
>>to the language, it becomes increasingly difficult to add
>>new extensions without making the language ambiguous.
>>We would need to invent more types of brackets,
>>operators, keywords, rules of ordering, nesting, etc.
>>Language designers spend enormous amounts of time
>>thinking about text syntax and trying to find new ways
>>to extend it.
>>If we are going to make creating languages easy, we
>>need to separate the representation and storage of the
>>program from the program itself."
>>
>>Is someone solving the wrong problem? Well, I think he is planning on
>>selling his solution:
>>
>>"We need some sort of editor for our
>>languages. But we don't want a generic editor; experience
>>has shown that generic editors aren't as usable as we
>>want them to be. We want writing models to be fast, so
>>we want specialized editors tailored to our language
>>concepts."
>>
>>And we then learn he is working on a generic graphical programming
>>environment for building DSLs. Move over, Emacs!
>>
>>Anyway, if your professor is a big LOP fan then you could get in big
>>trouble by turning in a one sentence paper: "LOP reinvents Lisp." Hmmm,
>>maybe you could back it up with a Collection DSL. Ooops, that reinvents
>>LOOP. Hey, how about "Lisp as a prototyping environment for DSLs". You
>>could do it this way: "Of course no one would really want to program in
>>Lisp, but for quick prototyping of DSLs the orderly syntax makes text a
>>viable editing front-end and destructuring-bind means we get to skip the
>>parser, too, allowing us to focus on semantics yadda yadda yadda..." ie,
>>You do not have to rub it in their noses.
>>
>>LOP is the single most common mistake in language evolution: taking a
>>good idea and making it into its own language or process. One thing
>>encouraging that is that you just can't do truly new things (in all but
>>one language) /without/ making a new language. But with Lisp you do not
>>stop to make a DSL, you just create a macro here and a macro there and
>>keep on programming. A DSL emerges from the process when lazy
>>programmers tire of writing/maintaining boilerplate.
>>
>>Well, that's my view from the cheap seats anyway.
>>
>>kzo
>>
>>--
>>Well, I've wrestled with reality for 35 years, Doctor, and
>>I'm happy to state I finally won out over it.
>> -- Elwood P. Dowd
>>
>>In this world, you must be oh so smart or oh so pleasant.
>> -- Elwood's Mom
>
>
> I totally agree with you. On every forum/newsgroup lispers share the
> same point. But don't be so hush,...
hush as an adjective? Ok, google offers "hush money". I think perhaps
this usage is closer to an abbreviation of "hush-hush"? I give it points
for creativity, take away more points for preciousness.
>... they are only trying to simulate the
> power of Lisp macros on a different platform/language and create a
> process of developing a custom made language. Overall it's a good
> thing because they finally realize that Abelson and Sussman's
> "stratified design" (from SICP) or the more recent language embedded
> DSLs are the way to do complex software.
Nice speech. So why the hell ask for ideas for profound thesis topics
involving both Lisp and LOP? That's like saying I want to do a paper
about powered flight and one of my interests is in making hot-air
balloon travel less susceptible to wind direction.
>
> This ("Lisp as a prototyping environment for DSLs") would be a nice
> idea, but it's nothing new; it's only a "i told you so" paper.
>
Oh, you took me seriously. A lot of people make that mistake. No, I was
just trying to keep you from pissing off your professor, that is death.
You could do a totally rocking DSL thing with Lisp. It lets you sidestep
the hurdles faced by crappy implementation languages and Just Do A DSL.
The fascinating question is the one I raised in the last post: will LOP
come to grief on the same rocks that wrecked OO and kept it from being a
Big Win? Doing a Collection DSL is a frickin joke: of /course/ that will
be reusable. Did the author think having a Collection DSL was a paradigm
shift? Lessee a DSL that does not map onto programming, one that maps
onto funeral home management. And is reusable. Bzzt. That is the exact
same problem OO failed at, and DSLs are the same as OO only worse,
because they are trying to express the whole shebang, not just the class
hierarchy.
kt
--
Well, I've wrestled with reality for 35 years, Doctor, and
I'm happy to state I finally won out over it.
-- Elwood P. Dowd
In this world, you must be oh so smart or oh so pleasant.
-- Elwood's Mom
On Feb 27, 6:11 am, Ken Tilton <·········@gmail.com> wrote:
> Adrian DOZSA wrote:
> > On Feb 26, 7:56 pm, Ken Tilton <·········@gmail.com> wrote:
>
> >>Adrian DOZSA wrote:
>
> >>>On Feb 26, 12:57 pm, Ken Tilton <·········@gmail.com> wrote:
>
> >>>>What is language oriented programming? Do you mean /natural language/?
>
> >>>Language oriented programming is a style of programming in which,
> >>>rather than solving problems in general-purpose programming languages,
> >>>the programmer creates one or more domain-specific programming
> >>>languages for the problem first and solves the problem in those
> >>>languages.
>
> >>>Additional links:
>
> >>>Language Oriented Programming: The Next Programming Paradigm
> >>>by Sergey Dmitriev, CEO of JetBrains
> >>>http://www.onboard.jetbrains.com/is1/articles/04/10/lop/mps.pdf
>
> >>"I have begun development of a universal platform (the
> >>Meta Programming System) for designing domainspecific
> >>languages along with their supporting tools and
> >>environments. It will allow programmers to define
> >>languages as easily as they can write programs today.
> >>The platform will fully support LOP, giving programmers
> >>the freedom to use the most suitable language for each
> >>part of their programs,..."
>
> >>Someone needs to write a snappy "rule" for this sort of thing.
>
> >>Yeah, I had heard of "intentional programming". This is just too funny.
> >>The paper offers nothing higher level than a "Collection DSL". Good
> >>lord, this is where we began with OO. Hey, look at my shapes class! So
> >>expect the same result: whenever anyone goes to write a program
> >>superfast, they will never find a DSL (nor an OO hierarchy) that is Just
> >>Right, so:
>
> >>"If there are no appropriate DSLs for your problem, then
> >>you create ones that fit your problem."
>
> >>Great! Ooops! I need to create an editor, too! Why?
>
> >>"The problem is that text editors are stupid and don't
> >>know how to work with the underlying graph structure
> >>of programs."
>
> >>PWUAUHAHAHAHAHAHAA. The man knows nothing of Lisp.
>
> >>"As features are added
> >>to the language, it becomes increasingly difficult to add
> >>new extensions without making the language ambiguous.
> >>We would need to invent more types of brackets,
> >>operators, keywords, rules of ordering, nesting, etc.
> >>Language designers spend enormous amounts of time
> >>thinking about text syntax and trying to find new ways
> >>to extend it.
> >>If we are going to make creating languages easy, we
> >>need to separate the representation and storage of the
> >>program from the program itself."
>
> >>Is someone solving the wrong problem? Well, I think he is planning on
> >>selling his solution:
>
> >>"We need some sort of editor for our
> >>languages. But we don't want a generic editor; experience
> >>has shown that generic editors aren't as usable as we
> >>want them to be. We want writing models to be fast, so
> >>we want specialized editors tailored to our language
> >>concepts."
>
> >>And we then learn he is working on a generic graphical programming
> >>environment for building DSLs. Move over, Emacs!
>
> >>Anyway, if your professor is a big LOP fan then you could get in big
> >>trouble by turning in a one sentence paper: "LOP reinvents Lisp." Hmmm,
> >>maybe you could back it up with a Collection DSL. Ooops, that reinvents
> >>LOOP. Hey, how about "Lisp as a prototyping environment for DSLs". You
> >>could do it this way: "Of course no one would really want to program in
> >>Lisp, but for quick prototyping of DSLs the orderly syntax makes text a
> >>viable editing front-end and destructuring-bind means we get to skip the
> >>parser, too, allowing us to focus on semantics yadda yadda yadda..." ie,
> >>You do not have to rub it in their noses.
>
> >>LOP is the single most common mistake in language evolution: taking a
> >>good idea and making it into its own language or process. One thing
> >>encouraging that is that you just can't do truly new things (in all but
> >>one language) /without/ making a new language. But with Lisp you do not
> >>stop to make a DSL, you just create a macro here and a macro there and
> >>keep on programming. A DSL emerges from the process when lazy
> >>programmers tire of writing/maintaining boilerplate.
>
> >>Well, that's my view from the cheap seats anyway.
>
> >>kzo
>
> >>--
> >>Well, I've wrestled with reality for 35 years, Doctor, and
> >>I'm happy to state I finally won out over it.
> >> -- Elwood P. Dowd
>
> >>In this world, you must be oh so smart or oh so pleasant.
> >> -- Elwood's Mom
>
> > I totally agree with you. On every forum/newsgroup lispers share the
> > same point. But don't be so hush,...
>
> hush as an adjective? Ok, google offers "hush money". I think perhaps
> this usage is closer to an abbreviation of "hush-hush"? I give it points
> for creativity, take away more points for preciousness.
>
> >... they are only trying to simulate the
>
> > power of Lisp macros on a different platform/language and create a
> > process of developing a custom made language. Overall it's a good
> > thing because they finally realize that Abelson and Sussman's
> > "stratified design" (from SICP) or the more recent language embedded
> > DSLs are the way to do complex software.
>
> Nice speech. So why the hell ask for ideas for profound thesis topics
> involving both Lisp and LOP? That's like saying I want to do a paper
> about powered flight and one of my interests is in making hot-air
> balloon travel less susceptible to wind direction.
>
>
>
> > This ("Lisp as a prototyping environment for DSLs") would be a nice
> > idea, but it's nothing new; it's only a "i told you so" paper.
>
> Oh, you took me seriously. A lot of people make that mistake. No, I was
> just trying to keep you from pissing off your professor, that is death.
> You could do a totally rocking DSL thing with Lisp. It lets you sidestep
> the hurdles faced by crappy implementation languages and Just Do A DSL.
> The fascinating question is the one I raised in the last post: will LOP
> come to grief on the same rocks that wrecked OO and kept it from being a
> Big Win? Doing a Collection DSL is a frickin joke: of /course/ that will
> be reusable. Did the author think having a Collection DSL was a paradigm
> shift? Lessee a DSL that does not map onto programming, one that maps
> onto funeral home management. And is reusable. Bzzt. That is the exact
> same problem OO failed at, and DSLs are the same as OO only worse,
> because they are trying to express the whole shebang, not just the class
> hierarchy.
>
> kt
>
> --
> Well, I've wrestled with reality for 35 years, Doctor, and
> I'm happy to state I finally won out over it.
> -- Elwood P. Dowd
>
> In this world, you must be oh so smart or oh so pleasant.
> -- Elwood's Mom
But i didn't said that i necessarily want Lisp and LOP. Lisp is the
only invariant :)
For example an extended/specialized MOP for CLOS for some idea would
be nice (like Constanza's AspectL and ContextL from Closer).
Any ideas on this?
Adrian DOZSA wrote:
> But i didn't said that i necessarily want Lisp and LOP. Lisp is the
> only invariant :)
> For example an extended/specialized MOP for CLOS for some idea would
> be nice (like Constanza's AspectL and ContextL from Closer).
> Any ideas on this?
>
EiffelL?
AspectL is like LOPL, this is Lisp, we do not need AOP. ContextL reminds
me of Capabilities, a stupid pet trick better handled by multiple
dispatch. Of course, this is for academia so the work does not need to
have merit. Watch out for using MOP just for the sake of using MOP.
Cells was done with macros, then with MOP, then I decided MOP should not
be used for its own sake, went back to macrology.
kt
--
Well, I've wrestled with reality for 35 years, Doctor, and
I'm happy to state I finally won out over it.
-- Elwood P. Dowd
In this world, you must be oh so smart or oh so pleasant.
-- Elwood's Mom
Adrian DOZSA wrote:
> But i didn't said that i necessarily want Lisp and LOP. Lisp is the
> only invariant :)
> For example an extended/specialized MOP for CLOS for some idea would
> be nice (like Constanza's AspectL and ContextL from Closer).
> Any ideas on this?
I am already working on a MOP for ContextL, and this isn't too much work
either. I consider AspectL as "deprecated" because you can do most of
the things in AspectL already with plain macrology + moppery. The only
interesting bit in AspectL are the destructive mixins, and the
functionality in ContextL covers this in a conceptually much cleaner way.
Here are other ideas:
- A recent approach is Classboxes, originally developed for Smaltalk and
Java, which gives you a way to define lexically scoped class extensions.
It would be interesting to build a full implementation of this for CLOS.
They have tried to add constructs like generic-flet and
with-added-methods to CLOS, but this didn't quite work out. So coming up
with a clean design here would be interesting. Compared to the existing
Classboxes approach, contributions would be to cover generic functions /
multiple dispatch and maybe to come up with an extension of the CLOS MOP
to cover the new concepts. These two bits don't exist for Classboxes
yet, AFAICT.
- Another recent approach is traits-style mixin inheritance (not Self
traits, but traits as developed for Smalltalk). Traits are interesting
because they give you similar functionality to that of multiple
inheritance as in CLOS, but without some of the isues. Namely, complex
class hierarchies in CLOS can become hard to understand because the
class linearization algorithm is ambiguous. Traits keep the main
characteristics of single inheritance here. However, it doesn't seem
straightforward to integrate multiple dispatch well, especially when
methods are specialized both on classes and on traits. Coming up with a
clean model here would be very interesting.
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
On Feb 27, 1:52 pm, Pascal Costanza <····@p-cos.net> wrote:
> Adrian DOZSA wrote:
> > But i didn't said that i necessarily want Lisp and LOP. Lisp is the
> > only invariant :)
> > For example an extended/specialized MOP for CLOS for some idea would
> > be nice (like Constanza's AspectL and ContextL from Closer).
> > Any ideas on this?
>
> I am already working on a MOP for ContextL, and this isn't too much work
> either. I consider AspectL as "deprecated" because you can do most of
> the things in AspectL already with plain macrology + moppery. The only
> interesting bit in AspectL are the destructive mixins, and the
> functionality in ContextL covers this in a conceptually much cleaner way.
>
> Here are other ideas:
>
> - A recent approach is Classboxes, originally developed for Smaltalk and
> Java, which gives you a way to define lexically scoped class extensions.
> It would be interesting to build a full implementation of this for CLOS.
>
> They have tried to add constructs like generic-flet and
> with-added-methods to CLOS, but this didn't quite work out. So coming up
> with a clean design here would be interesting. Compared to the existing
> Classboxes approach, contributions would be to cover generic functions /
> multiple dispatch and maybe to come up with an extension of the CLOS MOP
> to cover the new concepts. These two bits don't exist for Classboxes
> yet, AFAICT.
>
> - Another recent approach is traits-style mixin inheritance (not Self
> traits, but traits as developed for Smalltalk). Traits are interesting
> because they give you similar functionality to that of multiple
> inheritance as in CLOS, but without some of the isues. Namely, complex
> class hierarchies in CLOS can become hard to understand because the
> class linearization algorithm is ambiguous. Traits keep the main
> characteristics of single inheritance here. However, it doesn't seem
> straightforward to integrate multiple dispatch well, especially when
> methods are specialized both on classes and on traits. Coming up with a
> clean model here would be very interesting.
>
> Pascal
>
> --
> My website:http://p-cos.net
> Common Lisp Document Repository:http://cdr.eurolisp.org
> Closer to MOP & ContextL:http://common-lisp.net/project/closer/
I am aware of the classboxes and traits ideas. They were developed at
The Software Composition Group at the Institute of Computer Science
and Applied Mathematics (IAM) at the University of Berne. One of my
professor is an active collaborator of the SCG lab. Classboxes and
traits are interesting in weak-reflective languages(classboxes) and
languages with pure message-passing, as opposed to generic
functions(Traits). But i think you can easily simulate or overcome it
with Lisp's CLOS (multimethods), MOP and macros. But this is a nice
idea, i'll take a closer look at it. Thanks!
On 2007-02-26 12:56:53 -0500, Ken Tilton <·········@gmail.com> said:
> But with Lisp you do not stop to make a DSL, you just create a macro
> here and a macro there and keep on programming. A DSL emerges from the
> process when lazy programmers tire of writing/maintaining boilerplate.
>
> Well, that's my view from the cheap seats anyway.
Nail on the head, I'd say.
Adrian DOZSA <·········@gmail.com> wrote:
+---------------
| Ken Tilton <·········@gmail.com> wrote:
| > What is language oriented programming? Do you mean /natural language/?
|
| Language oriented programming is a style of programming in which,
| rather than solving problems in general-purpose programming languages,
| the programmer creates one or more domain-specific programming
| languages for the problem first and solves the problem in those languages.
+---------------
Oh, you mean how Lispers program all the time... ;-} ;-}
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
On Feb 26, 2:57 am, Ken Tilton <·········@gmail.com> wrote:
> Needless to say (because of my Cells project) I think the most
> interesting thing going on in language research these days is the
> dataflow paradigm, with functional reactive programming being the single
> most active academic label hung on this very old idea.
The OP might have a fabulous thesis by figuring out how to get an
efficient parallel implementation of something like Cells.
The OP wrote:
> I have to mention that i don't really want a practical project (a
> program to do something) and i would like more a research kind of
> topic, if you understand. I think i should have wrote "diploma thesis"
> instead.
Hm, it sounds like you want to prove some theorems about programming
languages, no? If you don't plan to write any code then you'd better
have a bunch of math ;) Personally I don't think of PL work as
interesting unless there is an implementation of something to play
with, or at least a sketch of an implementation. I'm not a PL expert
so I'm not sure what "low-hanging fruit" (i.e. stuff you can do in a
semester or two) there might be in terms of easy theorems to prove,
but I know there's plenty of low-hanging fruit in the efficiency and
implementation areas.
mfh
mfh
On Feb 26, 6:43 pm, ·············@gmail.com" <············@gmail.com>
wrote:
> On Feb 26, 2:57 am, Ken Tilton <·········@gmail.com> wrote:
>
> > Needless to say (because of my Cells project) I think the most
> > interesting thing going on in language research these days is the
> > dataflow paradigm, with functional reactive programming being the single
> > most active academic label hung on this very old idea.
>
> The OP might have a fabulous thesis by figuring out how to get an
> efficient parallel implementation of something like Cells.
>
> The OP wrote:
> > I have to mention that i don't really want a practical project (a
> > program to do something) and i would like more a research kind of
> > topic, if you understand. I think i should have wrote "diploma thesis"
> > instead.
>
> Hm, it sounds like you want to prove some theorems about programming
> languages, no? If you don't plan to write any code then you'd better
> have a bunch of math ;) Personally I don't think of PL work as
> interesting unless there is an implementation of something to play
> with, or at least a sketch of an implementation. I'm not a PL expert
> so I'm not sure what "low-hanging fruit" (i.e. stuff you can do in a
> semester or two) there might be in terms of easy theorems to prove,
> but I know there's plenty of low-hanging fruit in the efficiency and
> implementation areas.
>
> mfh
>
> mfh
I didn't said that i want a pure theoretical paper (where's the fun
without coding? specially Lisp). I just said that i don't want an
project like "make a Lisp program that does bla-bla-bla" (like a lab
project), but something more into research, like Constanza's idea and
your idea with distributed Cells (i have to read about "those Cells").
So thanks for all the ideas, and feel free to add.
On Feb 26, 8:43 am, ·············@gmail.com" <············@gmail.com>
wrote:
> Personally I don't think of PL work as
> interesting unless there is an implementation of something to play
> with, or at least a sketch of an implementation.
I should have written: "I don't think of PL work as interesting
unless there are test cases that justify a new concept" ;P
Whatever it is you decide to do, a good way to sell your thesis is to
gather some "real-life" examples or at least some plausible
applications for which your new construct will be useful. In your
case, "useful" probably means "makes programmers' lives easier." It's
a bit tricky to quantify that sometimes (surveys or other human
studies of programmers are one way!).
mfh
(message (Hello 'Ken)
(you :wrote :on '(Mon, 26 Feb 2007 05:57:42 -0500))
(
KT> Needless to say (because of my Cells project) I think the most
KT> interesting thing going on in language research these days is the
KT> dataflow paradigm, with functional reactive programming being the
KT> single most active academic label hung on this very old idea. Here is
KT> the prior art section of cells-manifesto.txt:
if Cells are already implemented, i think it would be cool to implement
distributed dataflow stuff.
btw, dataflow model is used in w3c's successor of VRML (Virtual Reality
Markup Language) -- X3D. so 3D/VR is also one of fields of dataflow model
application. (i once wanted to implement something in this area, but didn't
:). and in this area _distributed_ dataflow would be especially cool (i
don't know if it's implemented anywhere).
)
(With-best-regards '(Alex Mizrahi) :aka 'killer_storm)
"?? ???? ??????? ?????")
"Adrian DOZSA" <·········@gmail.com> writes:
> I am a student in 5th year (out of 5) and i need a diploma project
> idea.
>
> Topics i am interested in and want to study:
> - LISP
> - macros
> - MOP
> - meta-models
> - Language oriented programming (or derived work)
> - AOP
> - others...
>
> Any ideas (and details) are welcomed.
> Thanks!
Have a look at http://common-lisp.net/project/closer/aspectl.html
and perhaps also http://common-lisp.net/project/closer/contextl.html.
I haven't, so I can't tell for sure, but you almost certainly get
Lisp, macros, MOP and AOP. And others... :-)
Andras
"Adrian DOZSA" <·········@gmail.com> writes:
> I am a student in 5th year (out of 5) and i need a diploma project
> idea.
>
> Topics i am interested in and want to study:
> - LISP
> - macros
> - MOP
> - meta-models
> - Language oriented programming (or derived work)
> - AOP
> - others...
>
> Any ideas (and details) are welcomed.
> Thanks!
Dylan's OO has some features (e.g. sealing, union types) that CLOS lacks (not
surprisingly, since dylan was partly meant to be a better common lisp), maybe
it would be interesting to see what could be gainfully added to CL by MOP
hacking or hacking some particular implementation (SBCL being the most
reasonable candidate).
Or you could try to bring Common Lisp up to speed with eighties technology and
provide reasonable support for generic collection and iteration protocols.
Something else that might be useful (and provide plenty of opportunity to
study macros) would be a high quality pattern matcher.
'as
Alexander Schmolck wrote:
> "Adrian DOZSA" <·········@gmail.com> writes:
>
>> I am a student in 5th year (out of 5) and i need a diploma project
>> idea.
>>
>> Topics i am interested in and want to study:
>> - LISP
>> - macros
>> - MOP
>> - meta-models
>> - Language oriented programming (or derived work)
>> - AOP
>> - others...
>>
>> Any ideas (and details) are welcomed.
>> Thanks!
>
> Dylan's OO has some features (e.g. sealing, union types) that CLOS lacks (not
> surprisingly, since dylan was partly meant to be a better common lisp), maybe
> it would be interesting to see what could be gainfully added to CL by MOP
> hacking or hacking some particular implementation (SBCL being the most
> reasonable candidate).
>
> Or you could try to bring Common Lisp up to speed with eighties technology and
> provide reasonable support for generic collection and iteration protocols.
>
> Something else that might be useful (and provide plenty of opportunity to
> study macros) would be a high quality pattern matcher.
This is all "just" hacking, in the sense that these things have already
been done before in other languages. For a diploma thesis, that's not
very interesting.
One thing that should be reasonable to achieve is to try to design a
protocol for generic function dispatch that allows inlining at call
sites. The current CLOS MOP doesn't allow this. A protocol that allows
programmers at the meta-level to give hints to the runtime optimizer
would be really cool.
A good starting place for exploration would be
http://people.csail.mit.edu/jrb/Projects/partial-dispatch.htm
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
Alexander Schmolck <··········@gmail.com> wrote:
> Or you could try to bring Common Lisp up to speed with eighties technology and
> provide reasonable support for generic collection and iteration protocols.
SBCL >= 1.0.1 supports a generic sequence (rather than collection)
protocol. It's not documented in the SBCL manual yet, but you can
contact Christophe Rhodes for preprints of a paper on the protocol.
--
Juho Snellman
Futamura projection.
Specify a simple language, perhaps a pattern matching one.
Write an interpreter in a subset of CL.
Write a partial evaluator for the subset of CL.
Compile the language into your CL subset by partially
evaluating the source and the interpreter.
Add a dynamic type system to your language.
Watch what happens to the code in your interpreter that
handles runtime type errors
Can you say that a program is statically typed because the
partial evaluation step discarded the type-error code as
unreachable? How strong does the theorem proving in the
partial evaluator have to be to achieve this?
Does this eliminate/undermine the distinction between static
typing and dynamic typing?
Alan Crowe
Edinburgh
Scotland