DIKU-EDU / remarks

A DSL for marking student work
BSD 3-Clause "New" or "Revised" License
3 stars 2 forks source link

Add a properties syntax #6

Closed oleks closed 7 years ago

oleks commented 7 years ago

Some essential properties: student name, id, and grade. It would be nice to extract just these properties into a CSV format.

Perhaps the format should be similar to org-mode:

# Total: 45/100
  :Name: Donald E. Knuth
  :Grade: 00
## Theory: 40/50
  + Excellent.
  - But you need a CS degree to understand what's going on.
## Practice: 5/50
  + There is an implementation.
  - Only proven correct, but not tested.

I think properties should be global.

The CSV export command syntax could then look something like this:

$ remarks export --format "Name;Grade;Total;Theory;Practice" <path>

This is a prerequisite for #3.

oleks commented 7 years ago

@kirkedal Any objections to the format I suggest above?

kirkedal commented 7 years ago

No objections. I will look at it a bit later.

On 17 January 2017 at 21:03, Oleks notifications@github.com wrote:

@kirkedal https://github.com/kirkedal Any objections to the format I suggest above?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/oleks/remarks/issues/6#issuecomment-273282788, or mute the thread https://github.com/notifications/unsubscribe-auth/AB15lmpTaEWZdNiZlPZ8A0AAoKo6lwpuks5rTR6HgaJpZM4Lkgxn .

athas commented 7 years ago

Can the value of a property contain newlines?

oleks commented 7 years ago

On Tue, Jan 17, 2017 at 11:41 PM, Troels Henriksen <notifications@github.com

wrote:

Can the value of a property contain newlines?

I don't think we should allow that. That would encourage complicated properties, and it wouldn't be very collector-friendly.

kirkedal commented 7 years ago

I am thinking of forcing properties to the topmost judgement only. So basically this means that I will change the parser to return an IO [Assignment ([Property], Judgement)] in IO [Judgement].

oleks commented 7 years ago

On Wed, Jan 18, 2017 at 11:22 AM, Michael Kirkedal Thomsen notifications@github.com wrote:

I am thinking of forcing properties to the topmost judgement only. So basically this means that I will change the parser to return an IO [Assignment ([Property], Judgement)] in IO [Judgement].

I think this would make things more complicated. The parser is intentionally less specific than this. This makes it possible to let parseFileInDir and parsePath be mutually recursive.

Checking that only "top-level" judgements have properties can be done in app/Main.hs.

-- Oleks

oleks commented 7 years ago

I also think it could be a useful feature if TA's could fill in certain properties (deep down in their own files).

kirkedal commented 7 years ago

You were right about this. Parser done! New thought!

The proposed export format mixes titles and total points from different levels. That can quickly get out of hand. Should it be a depth or breath first search. Also I would like to use more wordy name for titles. Instead I propose the following. All Assignments (that includes leaf-assignments) have 3 predefines properties: Title, Total and MaxPoints. These comes from the header. When defining a property, we can then refer and read values from to the properties of the leaves. The format here is assuming that they are ordered and thus refers to the numbering in the list. An example could then be:

# Total: 45/100
  :Name: Donald E. Knuth
  :Grade: 00
  :Theory: [1.Total]
  :Practice: [2.Total]
## Theory sharpens the brain: 40/50
  + Excellent.
  - But you need a CS degree to understand what's going on.
## Practice your skills: 5/50
  + There is an implementation.
  - Only proven correct, but not tested.

Then the export command will be uniquely defined. $ remarks export --format "Name;Grade;Total;Theory;Practice" <path>

I don't like the format for referencing to leaves, but I lack something much better.

This can even be extended to a small scripting language, that can calculate grades and similar. We can even move the calculation of Total and MaxPoints to have a predefined summation of the leaves.

oleks commented 7 years ago

On Wed, Jan 18, 2017 at 1:25 PM, Michael Kirkedal Thomsen < notifications@github.com> wrote:

You were right about this. Parser done! New thought!

The proposed export format mixes titles and total points from different levels. That can quickly get out of hand. Should it be a depth or breath first search. Also I would like to use more wordy name for titles. Instead I propose the following. All Assignments (that includes leaf-assignments) have 3 predefines properties: Title, Total and MaxPoints. These comes from the header. When defining a property, we can then refer and read values from to the properties of the leaves. The format here is assuming that they are ordered and thus refers to the numbering in the list. An example could then be:

Total: 45/100

:Name: Donald E. Knuth :Grade: 00 :Theory: [1.Total] :Practice: [2.Total]

Theory sharpens the brain: 40/50

  • Excellent.
  • But you need a CS degree to understand what's going on.

    Practice your skills: 5/50

  • There is an implementation.
  • Only proven correct, but not tested.

I like this! I also like "total" in stead of "points"; perhaps you could refactor this throughout as well? Else it seems that I like refactoring :-)

This can even be extended to a small scripting language, that can calculate grades and similar. We can even move the calculation of Total and MaxPoints to have a predefined summation of the leaves.

Yes, that would be nice too.

-- Oleks

kirkedal commented 7 years ago