WhatsNext |
Edit this page |
I'd like to see Wheat get to a functional release this summer. Something we felt people could download and play around with without one of the core group looking over their shoulder or feeding them a demo...
To that end, we need to develop a set of stories and get on 'em. Since at this moment, my thoughts are just a big jumble, I'm going to get them all down here. Then we can sort them out soon.
See also: LanguageChanges
- Support for relative references (using siblings and aunts in the module by name)
- In-line objects w/methods
- Access to grandself and grandlocals
Small Language Fixes
- Comment syntax (use -- instead of ``) ?
- Get rid of need for single quotes for paths in various contexts
- Improve prototype decl. syntax (no one likes {:/library/foo/bar: ...
- Support ... as a block body (it returns an error)
- Add a primitive declaration syntax and require it in the VM
- Add a local declaration syntax
Newline: get rid of semicolons at end of lines, and add line continuation character(s)
Include syntax: Support multi-file compilations
Error Reporting
Think about Links: it still isn't clear that we've got the assignment/passing/return semantics correct with respect to copy/link/asis.
Object/Array Dualisms:
- new object syntax [ ... ] for both objects and arrays
- arguments object for getting variable args
- return object for multiple returns
- multiple assignment for multiple returns
Package Persistance: Loading should record into a persistent part of /system/config so it can be duplicated on start up.
Tests Separable: Tests should be able to be in a different file - perhaps using the include syntax -- so that they can be edited side by side with the things they test
Position Independent Code: It should be possible to write code so that it is wholly independent of where it is getting compiled and loaded. The new compiler will take care of references in the code to itself. We will still need to be able to reference the resources that go with the code (templates, css, images, etc...) and the tests need to be able to work independent of location.
Gradual Threads: Only spawn a few worker threads, and add to the pool as needed. Probably no reason to ever pare the pool down, though I suppose it would be nice.
Replace mod_file: Complete the file rendering support (mod. times, directories, byte-ranges, etc...) and then just get rid of mod_file.
Replace mod_raw: Create an object that presents a virtual object tree underneath it where all objects are rendered with the default object template.
Raw Object Template: add flags, improve value views, add value type icons, add member editor, add value editors
Template Attributes: Support attribute naming syntax, and then get rid of the attribute instruction (see TinyTemplateAttributes).
Excise old template system: in baselibrary.cpp
Containment: Think about how, as the path is walked, upper objects can get involved in the layout and expansion -- Things like common sidebars, footers, etc... should be easier.
Object New: design and implement the instantiation and cloning protocols
Object Introspection: the member functions in object are a start, but we could use a full set
Links and Paths: there should be a coherent set of functions for managing links and paths
User: a library for managing users and privileges
- Login
- Adding stories
- Editing stories
Wiki
Story/Task Card System
To that end, we need to develop a set of stories and get on 'em. Since at this moment, my thoughts are just a big jumble, I'm going to get them all down here. Then we can sort them out soon.
See also: LanguageChanges
Language
New Compiler- Support for relative references (using siblings and aunts in the module by name)
- In-line objects w/methods
- Access to grandself and grandlocals
Small Language Fixes
- Comment syntax (use -- instead of ``) ?
Decision of 2005-03-04:
-- for to end of line comments
--( and --) for nesting comments, not alternate form ((--)
""( only for long strings, can be indented so long as all lines have exact common indent, nothing else on opener line, closer line must have only common indent in front, perhaps stuff can follow closer
- Fix syntax for paths & links (make 'em work)-- for to end of line comments
--( and --) for nesting comments, not alternate form ((--)
""( only for long strings, can be indented so long as all lines have exact common indent, nothing else on opener line, closer line must have only common indent in front, perhaps stuff can follow closer
- Get rid of need for single quotes for paths in various contexts
- Improve prototype decl. syntax (no one likes {:/library/foo/bar: ...
- Support ... as a block body (it returns an error)
- Add a primitive declaration syntax and require it in the VM
- Add a local declaration syntax
Newline: get rid of semicolons at end of lines, and add line continuation character(s)
done! -- MarkLentczner, 2005-03-17
Include syntax: Support multi-file compilations
Error Reporting
- Compute source location information during compilation
- Report that location information in a structured way (not a text string!)
- Report locations during compilation phase as well (not just lexer and parser)
- Save location information away for VM
- Use location information when reporting errors
done! -- MarkLentczner, 2005-03-07
- Error should have templates (whole page, short part, long part) for standardized reporting of errors. The whole page and long forms should include the relevant sections of source code and links to the full code.
Someone's already written the spec for this: Ping's cgitb for Python. From Ping's Python Things∞ page:
cgitb: a traceback printer for CGI scripts that really shows off the power of inspect! Imagine this CGI script. Now, instead of seeing this∞ or this∞ or this∞, you can get this∞! Just get inspect.py, pydoc.py, and cgitb.py. Wrap your main function in a "try: ... except: cgitb.handler()" block.
Of course, with Wheat you shouldn't have to get anything or wrap your code at all...
Think about Links: it still isn't clear that we've got the assignment/passing/return semantics correct with respect to copy/link/asis.
Object/Array Dualisms:
- new object syntax [ ... ] for both objects and arrays
- arguments object for getting variable args
- return object for multiple returns
- multiple assignment for multiple returns
Farm
Package Loading: Make a package be a collection of files that gets loaded (using symlinks to static files)Package Persistance: Loading should record into a persistent part of /system/config so it can be duplicated on start up.
Tests Separable: Tests should be able to be in a different file - perhaps using the include syntax -- so that they can be edited side by side with the things they test
Position Independent Code: It should be possible to write code so that it is wholly independent of where it is getting compiled and loaded. The new compiler will take care of references in the code to itself. We will still need to be able to reference the resources that go with the code (templates, css, images, etc...) and the tests need to be able to work independent of location.
Server
Compiled Config: Not clear if we can achieve this as the bootstrapping issues are fierce - but it would be nice to have the config file be a Wheat script rather than an XML Wheat object file.Gradual Threads: Only spawn a few worker threads, and add to the pool as needed. Probably no reason to ever pare the pool down, though I suppose it would be nice.
Replace mod_file: Complete the file rendering support (mod. times, directories, byte-ranges, etc...) and then just get rid of mod_file.
Replace mod_raw: Create an object that presents a virtual object tree underneath it where all objects are rendered with the default object template.
Raw Object Template: add flags, improve value views, add value type icons, add member editor, add value editors
Templates
Model/View Separation: Make it possible to test the proper responses during expand and that the template properly asks for those tags, without relying on the static content of the template.A possibly related item is being able to write high-level web tests (in the style of jwebunit∞; for example, "click on the add story link"). This would let us test the user experience with less reliance on the details of the HTML. To make this happen, we'd need to be able to pick apart the HTML (e.g. a quick and dirty interface to expat, or the fancier XmlObjects design).
Template Attributes: Support attribute naming syntax, and then get rid of the attribute instruction (see TinyTemplateAttributes).
Excise old template system: in baselibrary.cpp
done -- JimKingdon 2005-02-21
Containment: Think about how, as the path is walked, upper objects can get involved in the layout and expansion -- Things like common sidebars, footers, etc... should be easier.
Libraries
String Matching: we need a regexp-like thing that is Unicode to the core. (See StringPatterns.)Object New: design and implement the instantiation and cloning protocols
Object Introspection: the member functions in object are a start, but we could use a full set
Links and Paths: there should be a coherent set of functions for managing links and paths
User: a library for managing users and privileges
Applications
Blog:- Login
- Adding stories
- Editing stories
Wiki
Story/Task Card System
There is no comment on this page.
[Display comments/form]
